Jump to content

[FIXED!] JTAG interferes with SensorTag external flash access

Recommended Posts

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.

Link to post
Share on other sites
  • 9 months later...

Good news! This issue is fixed in the TI Emulators package, which contains the version firmware for XDS110.


TI have added support for 2-wire cJTAG debugging, which only uses the TMS and TCK lines. In the firmware they also stopped the emulator from driving TDO, which was blocking access to the SPI. It looks like 2-wire cJTAG is the default mode now too, so debugging SPI flash code should just work like you'd expect.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...