CC2642R: Device does not start when not connected to XDS110 debugger

Hello Jack,

Please review these similar E2E threads:

https://e2e.ti.com/f/1/t/1126882 
https://e2e.ti.com/f/1/t/1127628 

Also note that OAD projects require the BIM image to be loaded consecutively, as also noted in the BLE5-Stack User's Guide and BLE Enhanced OAD SLAs.

Regards,
Ryan

Hi Ryan,

The crash of CCS v12 was a by-product of the tests you (or Brian, rather) asked me to run. I will verify if I can load the "simple_peripheral_CC26X2R1_LAUNCHXL_tirtos7_ticlang" example with the suggestions in the E2E threads above. Let's do that right now... Ah, no, alas. The "symbol_loader=1" did not work. I must enter that via "Window→Show View→Other..." (the "Expressions" are not in the menu by default, apparantly). type "Expressions" in the next dialog and add the expression "symbol_loader=1", correct?

The actual problem is that the board (or chip) does not start when it runs stand-alone, i.e. without the XDS110 attached.

• BIM is loaded (SDK v6.20 "bim_onchip_CC26X2R1_LAUNCHXL_nortos_ticlang" - which didn't crash CCS, now I think of it... ah well :-)
• The 3V power supply to the CC2642R device is present. Or, at least, I'm 99.9% sure of that. I will have someone verify it. I work at home, but the devices are at the office because we had to make the modifications for decoupling and the chrystal and I am prohibited to handle a soldering iron - that would be a bad idea anyway.

Best regards, 
Jack

Typically I can find the Expressions directly under the View tab, but you seem to have the correct location regardless.  You can also refer to swra640 or submit a SIMPLELINK-2-4GHZ-DESIGN-REVIEWS to further determine whether there are possibly any hardware issues.

Regards,
Ryan

Hi Ryan,

I managed to load the load the "simple_peripheral_CC26X2R1_LAUNCHXL_tirtos7_ticlang" example from SDK v6.20, using https://e2e.ti.com/f/1/t/1126882 and the reply from Michel Blom where to find everything. But it doesn't run. In the first attempt, with the BIM still there, it started at a very strange location (I didn't write down the address, but in the disassembly, it was at a location with invalid instructions, apparently).

After that, I did a full chip erase to get rid of the BIM. The program runs, but I don't see the device in my BLE explorer. The code loops in the "PRCMDeepSleep" function (or rather, "CPUwfi" in the driverlib). This is all quite normal, but as I don't see the device in the BLE explorer, I can't test that it also runs stand-alone...

I passed the links to SWRA640 etc to our hardware engineers, so they can take a look. 

The BIM should not exist for a non-OAD example, so it was correct to erase it for this test.  Have you tried testing your custom board RF output with SmartRF Studio?  If the device does not indicate any RF activity with this software or the simple_peripheral firmware in accordance to the the README description then there could be a hardware issue which needs to be resolved.

Regards,
Ryan

I'm not sure what to do with the SmartRF Studio. I have installed it and (once disconnected in CCS) I could connect to my board. I'm not sure what to look at. The "Continous TX" shows a radiating antenna, the "Continous RX" plots an RSSI graph (around -90 dBm). The "Packet TX" and "Packet RX" don't do much, but they need a second board to work.

It doesn't help that I can't find the README you mention. I found a tutorial, which tells me basically that I need two boards (and two XDS110s). But, despite the fact that I don't really know where to look, the RF bit appears to be working. Note that the device showed up in BLE Explorer (Windows App) so I already kinda knew it was working...

Mind you, that SmartRT Studio needs the device to be connected via an XDS110 and my issue is that the device does not start when _not_ connected to an XDS110.

---

Hm. I downloaded the v5.20 "oad_onchip" simple peripheral and that ran without a hitch... But didn't I just erase the BIM? The CCFG registers showed "0xFFFFFFFF" (they had a "proper" value when I programmed the BIM a couple of days ago) . I'm a bit confused why the "oad_onchip" now runs, where it didn't run without a BIM a few days ago...

It would be beneficial to have two boards, both for Smart RF Studio testing, using a sniffer, and communicating between host and peripheral devices.  https://dev.ti.com/tirex/explore/node?node=ANCbuKBgysbYPonYTk3GHA__BSEc4rl__LATEST 

Jack Weeland said:

SmartRT Studio needs the device to be connected via an XDS110 and my issue is that the device does not start when _not_ connected to an XDS110.

This could indicate an issue with the power supply or external 48 MHz crystal so I recommend you continue to monitor the hardware.

Jack Weeland said:

Hm. I downloaded the v5.20 "oad_onchip" simple peripheral and that ran without a hitch... But didn't I just erase the BIM? The CCFG registers showed "0xFFFFFFFF" (they had a "proper" value when I programmed the BIM a couple of days ago) . I'm a bit confused why the "oad_onchip" now runs, where it didn't run without a BIM a few days ago...

The SDK versioning should not make a difference.  I'm confused as to how the CCFG has been erased/modified.  The BIM must be programmed for the on-chip OAD BLE project to be operational.  Please continue to investigate this and let me know what else you discover.

Regards,
Ryan

Hi Ryan,

Sorry for the somewhat late reply. I still work from home and the boards are at the office, so I couldn't do much hands-on work on it.

Yesterday, a more hardware savvy colleague and I have been testing/debugging/trying various things.

• The power supplies are okay.
  • 3V measures 3V.
  • VDDR measures 1.675V (1.68V expected).
  • VDDR dropped a little (from 1.675V to 1.637V) when we disconnected the XDS110 emulator and also on an external reset (some bullits below)
• As already indicated, the example code runs when programmed from CCS (SDK v5.20 based "simple_peripheral_oad_onchip_CC26X2R1_LAUNCHXL_tirtos_ccs", but with LEDs to see what's happening), using the SDK v6.20 BIM.
• My colleague came across SmartRF Flash Programmer 2 (o, he showed the link on screen - I can't repeat where he found it). So we though, let's give it a try.
  • I selected the two files (v5.20 OAD example with LEDs and v6.20 BIM, in that order)
  • An erase, program and verify of those two files succeeded.
  • A verify immediately after failed! (one item at address 0x00000011, another time at address 0x00000024). This sounds very familiar; see below.
  • An erase, program and verify followed by another verify of only the OAD example: same result.
• After that, we tested what happened if we gave the device an external reset (by bridging a capacitor to Gnd on the RESET_N line). It took some time to have the XDS110 debugger connect to a running target by this recipe helps (mostly for other readers :-) https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/5.40.00.40/exports/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/debugging-index.html#connect-the-debugger-to-a-running-target (minding that it only works if you click the "Debug" button from "Debug Configurations..." screen).
  • When the debugger connects to the running target, the code (PC register) is always at address 0x1000060a. This is a ROM address with no link to source code, so I don't have any idea what's so special about that address...
  • The instruction at that address does a "bx r14" (return from function call).
  • Control returns to another ROM function at address 0x100036c5.
  • A few instructions thereafter it does a "pop {r4,pc}".
  • After that the behaviour is quite random. Well, I suppose the stack is corrupted.
  • (I was hoping that I could find out more what was going wrong, but alas)
  • A "Run→Load→Verify Program" again indicates that the flash memory has changed (verify fails at address 0x00000011, but the address changes between runs)

The problem with verify errors is (about) the same as I had last week. In an e-mail, your colleague Brian Zoro asked me if I had programmed the BIM (which I hadn't) and programming the BIM solved the problem BUT (as appeared later) only when the debugger is connected and/or, as we found out yesterday, as long as you don't reset the device with the RESET_N pin.

• The CCFG registers are set (not 0xFFFFFFFF) so I think the BIM is still present.
• The XOSC_HF_AMPGOOD, XOSC_HF_FREQGOOD and XOSC_HF_RFFREQGOOD in the AUX_DDIO_OSC.STAT2 register are '0', but they are too when the program runs in CCS (the device is in fact up and running; the BLE Explorer app "sees" the device, even when those bits are '0'). One post in your forum suggests they should be '1' (I think this one: https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/548183/createtask-issue-task-not-created-cc2640 - not the same device, I know...)

So, I think we still have a problem with either the clocks or the (internal?) power supplies, so if you have pointers where to look... And is the BIM still doing it's job? (and is there a way that it possible doesn't do its job? )

The VDDR drop is only thing we actually see, but it is only a 40 mV drop. Could that perhaps point to something?

Best regards,
Jack

Hi Ryan,

Sorry for the somewhat late reply. I still work from home and the boards are at the office, so I couldn't do much hands-on work on it.

Yesterday, a more hardware savvy colleague and I have been testing/debugging/trying various things.

• The power supplies are okay.
  • 3V measures 3V.
  • VDDR measures 1.675V (1.68V expected).
  • VDDR dropped a little (from 1.675V to 1.637V) when we disconnected the XDS110 emulator and also on an external reset (some bullits below)
• As already indicated, the example code runs when programmed from CCS (SDK v5.20 based "simple_peripheral_oad_onchip_CC26X2R1_LAUNCHXL_tirtos_ccs", but with LEDs to see what's happening), using the SDK v6.20 BIM.
• My colleague came across SmartRF Flash Programmer 2 (o, he showed the link on screen - I can't repeat where he found it). So we though, let's give it a try.
  • I selected the two files (v5.20 OAD example with LEDs and v6.20 BIM, in that order)
  • An erase, program and verify of those two files succeeded.
  • A verify immediately after failed! (one item at address 0x00000011, another time at address 0x00000024). This sounds very familiar; see below.
  • An erase, program and verify followed by another verify of only the OAD example: same result.
• After that, we tested what happened if we gave the device an external reset (by bridging a capacitor to Gnd on the RESET_N line). It took some time to have the XDS110 debugger connect to a running target by this recipe helps (mostly for other readers :-) https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/5.40.00.40/exports/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/debugging-index.html#connect-the-debugger-to-a-running-target (minding that it only works if you click the "Debug" button from "Debug Configurations..." screen).
  • When the debugger connects to the running target, the code (PC register) is always at address 0x1000060a. This is a ROM address with no link to source code, so I don't have any idea what's so special about that address...
  • The instruction at that address does a "bx r14" (return from function call).
  • Control returns to another ROM function at address 0x100036c5.
  • A few instructions thereafter it does a "pop {r4,pc}".
  • After that the behaviour is quite random. Well, I suppose the stack is corrupted.
  • (I was hoping that I could find out more what was going wrong, but alas)
  • A "Run→Load→Verify Program" again indicates that the flash memory has changed (verify fails at address 0x00000011, but the address changes between runs)

The problem with verify errors is (about) the same as I had last week. In an e-mail, your colleague Brian Zoro asked me if I had programmed the BIM (which I hadn't) and programming the BIM solved the problem BUT (as appeared later) only when the debugger is connected and/or, as we found out yesterday, as long as you don't reset the device with the RESET_N pin.

• The CCFG registers are set (not 0xFFFFFFFF) so I think the BIM is still present.
• The XOSC_HF_AMPGOOD, XOSC_HF_FREQGOOD and XOSC_HF_RFFREQGOOD in the AUX_DDIO_OSC.STAT2 register are '0', but they are too when the program runs in CCS (the device is in fact up and running; the BLE Explorer app "sees" the device, even when those bits are '0'). One post in your forum suggests they should be '1' (I think this one: https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/548183/createtask-issue-task-not-created-cc2640 - not the same device, I know...)

So, I think we still have a problem with either the clocks or the (internal?) power supplies, so if you have pointers where to look... And is the BIM still doing it's job? (and is there a way that it possible doesn't do its job? )

The VDDR drop is only thing we actually observed, but it is only a 40 mV drop. Could that perhaps point to something?

Best regards,
Jack

Why are you mismatching the Simple Peripheral and BIM SDK versions, i.e. using the SIMPLELINK-CC13X2-26X2-SDK v5.20 Simple Peripheral OAD and SIMPLELINK-CC13X-CC26XX-SDK v6.20 BIM?  I recommend using one or the other for testing purposes.  Please make sure you are loading the on-chip BIM hex image and Simple Peripheral's output *_oad.bin image consecutively, preferably using UNIFLASH.  If you can run the project as expected until a reset occurs, and if there are no issues with using a non-OAD project, then the issue should not be related to hardware and most likely involves the relationship between the BIM and on-chip application being used.

Regards,
Ryan

The "why" is that that was a working configuration (and I added LED control so it was immediately visible that the board had started or not).

I have now added the "simple_peripheral_oad_onchip_CC26X2R1_LAUNCHXL_tirtos7_ticlang" SDK v6.20 example to my workspace. It compiles and runs from CCS (as verified with the BLE Explorer, by lack of other means due me not being in the office and the device is).

With Uniflash 8.0:

• I selected the two images (both SDK v6.20)
  • bim_onchip_CC26X2R1_LAUNCHXL_nortos_ticlang.hex
  • simple_peripheral_oad_onchip_CC26X2R1_LAUNCHXL_tirtos7_ticlang_oad.bin
• Under "Reset Action", I selected "Board Reset (free run)"
• I checked "Execute selected reset after program load"
• Under "Run Actions", I selected "Run target after program load/flash operation"
• The device runs after "Load Images"!
• HOWEVER, a "Verify Images" after that gives an error at address 0x00000011. The device is still up and running, though.... (it re-appears in the BLE Explorer after a few seconds)
•  At it still runs after a power cycle with the XDS110 disconnected!

The device still doesn't run stand-alone (i.e. unplug the XDS110 from the board and power cycle the board) when programmed from CCS, Independent of which application I load first (the BIM or the OAD application). For the OAD application, under the "Flash Settings" for the debug configuration, I selected to erase the "Necessary Sectors Only" under the erase settings during program load and I checked "keep CCFG data" under the CCFG section.

I'm not sure why I still get an error during a "verify" in Uniflash. The program (the OAD simple peripheral) seems to be okay as it runs normally after the verification.

Best regards,
Jack

CCS programs the default project output file but not the *_oad.bin file which is created post-build by the OAD Image Tool to pad the image and embed the CRC.  Without this content the BIM will fail to start the application, hence the failure you are seeing inside CCS.  This is why Uniflash must be used to load the OAD and BIM images consecutively.

I am not familiar with the operation of the Uniflash verify command but it likely fails due to a change in the shared BIM image header (stored at the beginning of flash memory) after the program was first run, for example the image copy status and/or CRC status bytes could have changed from what was programmed.  The same could occur for NV memory of the BLE application.

Regards,
Ryan