Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by tripwire

  1. >>>> can I use the 432 ARM Launchpad to power / program / energytrace / backchannel async standalone MSP430F/G chips <<<<<   ?????


    The MSP432 launchpad can't program MSP430 chips, it's only set up to program ARM Cortex MCUs. Power/EnergyTrace and backchannel UART work just fine, though.


    By the way, the MSP432 launchpad has a 3.3V supply voltage rather than 3.6V as used on the MSP-EXP430FR5969. That doesn't cause problems as the MSP430F/G chips run happily at either voltage, but it's sometimes important for other components if you're using a custom board.

  2. Another question: any word on the microphone and accessing it? 


    I haven't written any code for it yet, but I did some digging into the documentation and it's an interesting bit of kit :)


    Some useful documents are here:

    http://www.knowles.com/eng/content/download/5990/105795/version/1/file/SPH0641LU4H-1.pdf (datasheet)

    http://media.digikey.com/Resources/Knowles/knowles-sisonic-design-guide.pdf (see section 2.2.4: PDM Digital SiSonic)

    http://curiouser.cheshireeng.com/2014/10/21/introduction-to-mems-microphones/ (general overview)

    https://e2e.ti.com/blogs_/b/precisionhub/archive/2015/01/21/delta-sigma-adc-basics-understanding-the-delta-sigma-modulator (overview of delta-sigma modulution)


    To summarise, instead of providing an analog output which can be read with an ADC, it includes an internal delta-sigma modulator and outputs a PDM bitstream. To use it you need to feed it a clock and read the resulting bitstream, which I think can be done using the SSI peripheral (or maybe it's the I2S one). Then you'll probably want to convert the PDM bitstream into PCM at a sampling resolution and frequency of your choice, which can be done with a digital low-pass filter.

  3. Dear all,


    I'm using CCS on Win7 and Launchpad 430g2 with a 2452 chip.

    I cannot get the ISR to execute when I externally drive comparator input voltage up and down. Minimal code is here. I think it should toggle LED whenever I go up. (Other code examples are reading P1.1 comparator correctly in same setup and also LED is connected correctly as tested with other code.)


    Any idea? Any obvious fault in code? Thanks!


    You haven't set the GIE bit anywhere, so all (maskable) interrupts are disabled. That includes your comparator interrupt.


    Add a "__bis_SR_register(GIE);" before the infinite loop, that should make the ISR work.

  4. About the SensorTag DevPack---can the XDS-110ET included on the MSP432 LaunchPad possibly be used as a debugger for the CC2650STK, connectors notwithstanding?  If so, I'd rather add an MSP432 LaunchPad to my collection.


    Yes, but the necessary modification is difficult at present.


    The emulator firmware doesn't support cJTAG (only SWD and JTAG), while the CC26xx doesn't support SWD (only JTAG and cJTAG). That means that full four-wire JTAG is the only option that will work right now. The problem is that the launchpad only exposes pins for SWD and cJTAG rather than the full JTAG pinout used with the on-board target.


    To add a JTAG cable you need to tap into one of the traces on the PCB by scraping off the soldermask and tacking a wire to the trace. The other connections are exposed at J103 and one is on a terminal of S101. See these posts on TI's forum for more details:


    XDS110 from MSP432P401R Launchpad for CC26xx/CC13xx

    MSP432P401R LaunchPad External Target Mod (See the detailed instructions in the PDF)


    I have a sneaking suspicion that TI might add cJTAG support to the XDS110 on the Debug DevPack to fix the issue with debugging while using the serial flash. If they do there's a slim chance that the same might be added to XDS110-ET. That would make it far easier to use the MSP432 launchpad with the SensorTag, because only connections to J103 would be required. None of this is confirmed, and it'll be at least a few months before the next major XDS110 firmware update. I heard predictions of October from TI, but their toolchain updates are prone to slippage.

  5. The SensorTag shipped with a plastic film over the battery, so it shouldn't have run down already, unless that original firmware was *really* power hungry.

    You're right, the power won't have started to run down until the plastic strip was removed. Unfortunately I wasn't exaggerating when I called the power consumption atrocious. People have reported draining the battery enough to affect the IMU within a couple of days.


    Was the power consumption fixed in the 1.12 firmware?

    I think you might need a newer firmware than that. Are you updating over-the-air from a phone or with a Debug DevPack?


    I use the DevPack, and the SensorTag sample in the BLE Stack 2.1 has been updated with the power consumption fixes. It's also available as a prebuilt hex file for programming with SmartRF Flash Programmer V2 from here: https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/912/CC2650SensorTag_5F00_BLE_5F00_App_5F00_v1_5F00_20.hex


    If you need to update over-the-air then I'm not sure what version is available.


    I tried a replacement battery, and I did see a few updates in the Motion Data section, with accelerometer, gyro, and magnetometer all showing some non-zero values, but then they all froze.  After disconnecting and reconnecting, it's back to showing all zeros under Motion Data.  Removing the battery and putting it back in again, I get the same behavior.  It looks like 9 updates of Motion Data come through with a 1000ms period, and then the Motion Data freezes.

    That rings a bell, I think older firmware had problems with the wake-on-motion feature. The IMU would give output for a while, but then stop and never restart.

  6. My CC2650STK just arrived, and I'm checking it out with the TI demo Android app.  The humidity, noncontact temperature, barometric pressure, and lux sensors all behave like they should, but the app doesn't show sensible data for acceleration, rotation, or magnetic fields.  All those fields show zero.  I've updated the CC2650STK firmware to revision 1.12 (Jun 23 2015) using the Android app.  The Android app is revision 2.3.  I'm running it on a 1st-gen Moto X with Android 4.4.4.  


    Is this a known software issue, or do I have bad SensorTag hardware?  


    One thing I've heard is that the IMU doesn't work properly when the supply voltage has dropped below 3V. I know you only just got the SensorTag and would expect the coin cell to fresh, but the original firmware had atrocious power consumption...

  7. Here's a list of things to check for if you're getting excessive power consumption on the CC2650 SensorTag - particularly when using TI-RTOS:

    • [3.0mA constant] If you're not using the MPU, has it been powered off? By default the Board_MPU_POWER pin is set to output high during startup (TI-RTOS 2.1).
    • [2.9mA when idle] Do you have a power policy set up in the TI-RTOS .cfg file, and is it correctly configured to run when tasks are idle?
    • [0.5mA when SPI inactive] Are the SPI bus pins set to pulldown when the SPI driver is inactive? If they're left floating the serial flash inputs can draw excessive current.
    • [0.27mA constant (?)] Has the TMP007 been placed in shutdown? By default it powers up in 4x oversampling mode with a typical current of 270uA.
    • [0.20mA when alert active (?)] If you're using the TMP007 alert pin function, have you disabled pullup on Board_TMP_RDY? There's an external pullup on the board already...
    • [0.01mA constant] Has the external serial flash been powered down? It takes a typical current of 10uA in standby, which drops to 1uA in power-down.

    The ones marked (?) are unconfirmed, and are just based on specifications/schematics.
    Further to the two TMP007 items on the list: is your TMP007 working at all? If you can't get it to respond to I2C traffic it's possible that it has been damaged. Mine was, and it resulted in additional wasted current of 4mA until I removed the chip. Being a bare die makes it quite vulnerable to damage.
    If you're not using SPI then the following code fragment will resolve points 1 and 3:

        static const PIN_Config unusedPinTable[] =
            Board_SPI0_MOSI | PIN_INPUT_DIS | PIN_PULLDOWN, // disable input, enable pulldown to give a defined level on the bus
            Board_SPI0_CLK  | PIN_INPUT_DIS | PIN_PULLDOWN, // disable input, enable pulldown to give a defined level on the bus
        // Open unused pins to set correct default state
        // Define unusedPinHandle and unusedPinState somewhere, either static or global
        unusedPinHandle = PIN_open(&unusedPinState, unusedPinTable);

    If you are using SPI you'll need to set up a pin table/handle/state for just the SPI pins, then use PIN_open after SPI_close and PIN_close before the next SPI_open. Alternatively you can just keep the SPI open... but that seems to take an extra ~100uA. I think that's because the uDMA forced to stay powered up.
    For point 2, the easiest way to be certain that the power policy is correctly set up is by calling it from a user-defined idle function. That way you can breakpoint the function and be sure that it is called when all tasks are idle.
    First you'll need to turn off the option that automatically runs the power policy when tasks are idle:
    Now add the following code to your project:

    #include <ti/sysbios/family/arm/cc26xx/Power.h>
    void idleFxn()
        Power_standbyPolicy(); // Breakpoint this line to check that the policy is getting called on idle

    Finally set up the idle function:
    Now run the program in the debugger and check that a breakpoint placed in idleFxn is hit during runtime. You can also step in to the Power_standbyPolicy code and see which low power mode it is able to use; sometimes it's prevented from going into full standby due to constraints set by active peripheral drivers.
    Removing the user-defined idle function and rechecking the "Invoke power policy when all threads are blocked" should give the same result, but it's harder to confirm that it's working correctly.
    The tiny saving from putting the flash into power-down for step 5 is barely worth the effort. You need code to initialise the SPI driver, get the flash into a known state from a potentially unknown one and then put it to sleep. The MCU can be reset without the external flash being power cycled, and JTAG blocks SPI traffic making the code untestable in the debugger. I only did this because I'm using the flash in my project already.

  8. It's time for an update. Remember when I said this:


    I have no idea what the battery life will be at present...


    When I was writing the firmware I took care to minimise power consumption where possible. The RTOS tasks sleep between measurements and there's no busy-waiting. Writes to the flash are batched up and sent a page at a time, with the flash put in shutdown until the next page is ready. The LEDs and buzzer are not used during logging. I was pretty confident that the power consumption would be acceptable.


    Well, I finally got around to taking some current measurements two weeks ago and the results were woeful. The average current was somewhere around 12mA (!), so the SensorTag would be draining a fresh CR2032 every 18 hours or so. This was confirmed when the altitude logger cut out after a further 90 minutes of use.


    Checking the sample projects showed equally bad results, so there had to be something odd going on.


    I got a tip-off that the latest samples in BLE Stack 2.1 and TI-RTOS 2.14 had better power consumption, which they did to an extent. The SensorTag sample was still drawing 4mA when powered off, however, and that had to be wrong. By now I was getting pretty suspicious of the TMP007 sensor, which had never worked and appeared to have some damage just visible on the (bare) die. Desoldering it fixed the problem, and brought the SensorTag sample's average current down to a few microamps when powered off.


    Now I had a good sample, but the SensorTag sample is heavily event-based which makes it hard to trace through. It took days (literally!) to work out what the sample was doing differently to my code. Mainly it was down to IO configuration and power profile setup. Most of the components on the SensorTag are configured for low power at startup, but the others take a lot of current. Here's a post giving more detail on that: http://forum.43oh.com/topic/8864-cc2650-sensortag-low-power-checklist/


    Now I've got the measurement current down to 0.33mA, giving an estimated battery life of 28 days. I expect it can be improved, but for now it's more than good enough!

  9. (BTW how to upload an image to this board ?)


    You have to use the full editor (click the "More Reply Options" button). Below the edit textbox is an "Attach Files" area. After choosing an image file to attach it will be listed in the attachments area with an "Add to Post" link, which pastes some markup that inlines the image in your post. You can preview the post to check that the image upload/insert worked correctly.



  10. Hi everyone,

    How I can config to controls the direction of the receive and transmit shift register (LSB|MSB first), in msp430 is UCMSB, how about in TivaC?

    Thanks in advanced!


    I don't think the SSI on Tiva supports that. You'd need to reverse the bit order yourself before passing the data over to the SSI.

  11. I've confirmed that the problem was specific to my SensorTag.


    As well as ignoring I2C the chip appeared to have some physical damage to the corners (just visible under magnification). I also had an unexplained current draw of about 4mA that was making the coin cell go flat in a day or two. That seemed likely to be caused by the TMP007, and since it since it didn't work anyway I decided to desolder it.


    Sure enough the 4mA mystery load vanished. I guess it was either shorting out internally or the missing corners had ended up bridging the contacts under the chip.

  12. Spam . :(

    Removed them


    Thanks! I noticed you'd already been busy deleting similar ones while searching for the original source of the text. The "Beyonce" one had about four hits on 43oh at the top of google's list, but they'd already been cleared off the blog :)

  13. I just noticed some interesting comments in the sidebar on the 43oh blog.
    On the Launchpad Screw Terminal Power Connector article someone has posted:
    "Well if you look at it from a flag planting point of view the Soviets got a few rotbos up there, and the Americans a few rotbos and some people, so they may have a claim. I guess if we get some settlers up there then they can stake out there own claims. I suspect though that some international body such as the International Astronomical Union, might need to be involved in divvying up things.But certainly the people selling the rights to land on the moon have no legal basis for doing so."
    ...and on http://43oh.com/2010/08/poll-results-have-you-received-your-launchpad'>Poll Results

  14. The space in the path was the culprit. 


    Nice little trap that is....

    The space wasn't even mine, it was created by Windows....


    Yeah, CCS doesn't handle such things well.


    The other classic trap is with characters other than the standard a-z|A-Z|0-9 and common punctuation. I seem to remember it chokes on accented characters, which isn't great if you happen to have any in your name...

  15. Was it working with the earlier BLE stack? I have mine at work with the old firmware. Will let you know tomorrow.


    I just checked it on BLE stack 2.0, and I've also previously tried the TI-RTOS i2ctmp006_cc26xx* sample. Both gave the same result: no acknowledgement from the sensor.


    * Although that sample was written for the TMP006 the code should work equally well on TMP007

  16. I'm running the BLE stack 2.1 SensorTag and SensorTagStack sample projects, but the TMP007 temperature sensor doesn't work. It fails to acknowledge the I2C address. I'm running the sensortag from a 3.3V supply, so it's not the battery voltage dropping out.


    Is anyone else getting the same problem, or is it only my SensorTag that's misbehaving?


    EDIT: Rewrote the post and title because it's only the TMP007 that's not working. The HDC1000 fails the sensorHdc1000Test on startup, but after that it seems fine.

  17. "C:/ti/xdctools_3_31_01_33_core/packages/xdc/cfg/global.h", line 39: fatal error #1965: cannot open source file "C:/Users/Roland Manser/Tiva_connected/pwmled_EK_TM4C1294XL_TI_TivaTM4C1294NCPDT/Debug/configPkg/package/cfg/pwmled_pem4f.h"


    Does the file pwmled_pem4f.h exist at the path listed above?


    If it does exist then maybe try setting up a new CCS workspace at a path with no spaces in the name. I've had trouble with that in TI's software before...

  18. At work we use the 10mm and 50mm. I usually go for the 10mm one.


    If there is a large price difference, go for the 10mm. That tape is going to last a long time.


    I'm expecting the 50mm roll to be better value for money (ie less than 5x the cost of a 10mm roll).


    That said, you do make a good point about how long it will take to use up. I've still got about 24.3 metres of a 50mm x 25m double-sided tape roll that I'll struggle to get through in an average lifetime :)

  19. Here's a heads-up for anyone that wants to use the external SPI flash memory on the SensorTag: it's not accessible while a debugger session is active.
    Unfortunately the pin on the SensorTag's CC2650 which outputs the SPI clock to the flash memory is also used as the JTAG TDI pin:
    While you're debugging using the Debug DevPack the CC2650 is unable to clock data out to the flash chip. That means the flash will just sit there doing nothing and the CC2650 will end up reading zeroes from the SPI bus.
    To use the flash you need to be certain that no JTAG communication is occurring during execution of your firmware.
    The easiest way to do this is just to disconnect the Debug DevPack and power the SensorTag from a coin cell or external power supply.
    Alternatively you can use the Debug DevPack to power the SensorTag, but then you have to follow this procedure:

    • Load your updated firmware onto the SensorTag using the Debug DevPack (I just run it in the CCS debugger)
    • Terminate the debug session once you reach the start of main()
    • Disconnect the Debug DevPack from USB
    • Detach the SensorTag from the DevPack
    • Connect the Debug DevPack to USB
    • Reattach the SensorTag to the Debug DevPack

    Be careful not to miss step 2, or the DevPack will resume JTAG communication when everything is connected up again. I found that out the hard way...
    Also, the order of the last two steps is to avoid an issue with powering up the Debug DevPack while it's connected to a SensorTag with no coin cell. The advantage of that is that you don't need a coin cell (I've drained two already...)
    This makes testing code that uses the flash really difficult, as there's no way to use the debugger. I've been using a combination of UART logging, LED flashes and beep codes from the onboard buzzer to keep track of where the code is up to.
    The other thing I'm doing is detecting whether the flash is available during startup and skipping the flash accesses if it's not there. That lets the rest of the code run in the debugger without problems.
    The command sequence I'm using to detect the flash is:

    • Repeatedly send a Read Status Register command (0x05, 0x00) until the received BUSY flag is clear
    • Send a Read Mode Reset command (0xFF, 0xFF)
    • Send a Release From Power Down command sequence (0xAB, 0x00, 0x00, 0x00, 0x00)
    • Flash is available if the device ID value 0x12 is received in the last byte of the Release From Power Down sequence

    This sequence is arranged to work irrespective of the state of the flash chip. If JTAG is active the code will immediately fall through step 1 (BUSY flag is zero), but the received device ID at step 4 will be zero too. Step 2 covers against any remote chance that the device has ended up in dual-SPI mode. Step 3 wakes the chip if it has been put in suspend, and returns the device ID regardless.

  20. Any call to attempt to open a connection to the flash is unsuccesful for me (`extFlashOpen()`), so I of course can make no read/writes.


    Aha, I think I have just the thing... Here's some information about a similar problem I had when getting the external flash to work in my program:




    EDIT: I just took a look at the extFlashOpen and it calls extFlashVerifyPart to get the manufacturer/device ID. That will get zeroes when the JTAG is active, so extFlashOpen will return false in that case


    I also spotted this interesting comment, which might help me cut the power consumption of the flash between write operations :)


    #ifdef IO_PARKING

    // Table of pins to be "parked" in when no device is selected. Leaving the pin

    // floating causes increased power consumption in WinBond W25XC10.

  21. Are you using TI-RTOS to write the firmware for the SensorTag?


    There's currently a bug in the board.c file in tirtos_simplelink_2_13_01_09\packages\ti\boards\SensorTag\CC26XXST_0120. The UART pins are mistakenly configured for a different CC26xx evaluation board (SRF06EB). The corrected version of the offending section is posted below, with the original version shown in the comments:

    const UARTCC26XX_HWAttrs uartCC26XXHWAttrs[CC2650_UARTCOUNT] = {
        {    /* CC2650_UART0 */
            .baseAddr = UART0_BASE,
            .intNum = INT_UART0,
            .powerMngrId = PERIPH_UART0,
            .txPin = Board_DP5_UARTTX, // <-- originally "Board_EB_UART_TX,"
            .rxPin = Board_DP4_UARTRX, // <-- originally "Board_EB_UART_RX,"
            .ctsPin = PIN_UNASSIGNED,
            .rtsPin = PIN_UNASSIGNED

    EDIT: Wait a second... are you connecting the UART from the MSP430G2553 to those pins? They're already used by the Debug DevPack for the application UART backchannel. With the MSP430G2553 disconnected you can try using a terminal program on your PC to send/receive data between the PC and SensorTag. You can use PuTTY, or CCS has a terminal window under Window->Show View->Other...

  22. @@tripwire This project is neat! I'm just getting started with the CC2650 myself and would really love to see your source code if you're willing to share (in turn I'd of course be developing my project in the open). If not, would you be willing to share some knowledge on how you were able to continuously log to the external 4MB SPI flash? That specifically is where I have been stuck for about a week (I am fairly new to this area); I'd like to just get started continously logging the on-board sensors and see what I can hack together from a longer data set once I can get that going.


    Any feedback would be super helpful, thanks!




    Hi Nick,


    I'm not ready to release the source just yet, but I am planning to write more about this project as it develops. The majority of that will cover the logging system: how the code is structured, the data flow, log data format and the thought process behind it. Hopefully that will be of interest!


    Regarding your own project, what particular aspect of writing to the flash are you having trouble with? Is it the practical details of communicating with the flash and performing commands, or is it more on the program design side of things? I'd like to hear a bit more as it will help me decide what areas to focus on when I write this up.



  • Create New...