LP-EM-CC2340R5: Got updated Launchpad (with PG2.0), unable to upload/debug fw on XDS110

Hi Micael,

Can you please refer to https://e2e.ti.com/f/1/t/1224456 and let me know whether the suggested solution resolves your issue?  Also see https://e2e.ti.com/f/1/t/1226016 

Regards,
Ryan

Hi Ryan,

The first link is actually going to the same thread that I referenced by its name "LP-EM-CC2340R5: Unable to program CC2340 device via XDS110 debugger". And while I don't get any errors following the instruction, it does not help my situation in any clear way - I still get the same "The target failed to see a correctly formatted SWD header" message.

The other thread you point to, has a lot of questions, so here's the answers that fits my situation;

The EVM is Rev A, and the silicon is marked with the 'B', end of third line, so I figure it must be PG2.0. (And it was ordered over the ti shop, once released, so it ought to be the proper part).

SDK is SIMPLELINK-LOWPOWER-F3-SDK v7.10.00.35 and the BLE app is created from it.

Regarding the reset line:

The Lauchpad has nothing connected to it - I wanted to make sure the OAD app worked before doing anything else with it. But there's a lot of "reset" options in the debugger setup, I am sure I have not tried all of them in combinations.

I hooked up a scope, and there's absolutely nothing going on on "LPRST" header - it is high all the time also when I try to load the ble example.

However, if I check the checkbox "Reset the target on a connect" in the Target tab on the debug configurations, the program load fails with a different error messages and then the CCS crashes.

And if I instead enable "Reset the target on a program load or restart", I get the following error (and reset is still high); (CCS is not crashing).

Cortex_M0P: Flash loader: CC23xx_FLASH_LIBRARY_VERSION 3.17.09.20
Cortex_M0P: Updating CRC32 field ccfg.bootCfg.crc32 @ address 0x4E02000C, based on data in the range [04E020000, 0x4E02000B]. Value changes from 0x00000000 to 0xFFFFFFFF
Cortex_M0P: Updating CRC32 field ccfg.crc32 @ address 0x4E02074C, based on data in the range [04E020010, 0x4E02074B]. Value changes from 0x00000000 to 0x4C1584B6
Cortex_M0P: Updating CRC32 field ccfg.userRecord.crc32 @ address 0x4E0207CC, based on data in the range [04E020750, 0x4E0207CB]. Value changes from 0x00000000 to 0x15D70E0C
Cortex_M0P: Updating CRC32 field ccfg.debugCfg.crc32 @ address 0x4E0207FC, based on data in the range [04E0207D0, 0x4E0207FB]. Value changes from 0x00000000 to 0x527294A2
Cortex_M0P: GEL Output: Memory Map Initialization Complete.
Cortex_M0P: Failed Device reset (automatic connect/disconnect): (Error -2063 @ 0x0) Unable to reset device. Power-cycle the board. If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.11.0.00128) 
Cortex_M0P: JTAG Communication Error: (Error -615 @ 0x0) The target failed to see a correctly formatted SWD header. The  connection to the target may be unreliable. Try lowering the  TCLK setting before trying again. (Emulation package 9.11.0.00128) 
Cortex_M0P: AutoRun: Unable to run the target at this time
Cortex_M0P: AutoRun: Target not run as breakpoint could not be set: Cannot enable while the target is disconnected
Cortex_M0P: GEL Output: Memory Map Initialization Complete.

But if I press the button on XDS110, the reset is pulled on LPRST line!

Note; on my PG1.0 setup, none of the 'reset options' in debug configurations are set, so I don't know if this is at all relevant, but seeing that the other thread, the reset line was the issue, I thought I should mention this.

Regards,

 Micael

So, this morning, I figured I should test the SmartRF program, so I started a virtualbox to run it (could not find any linux binary?).

Both my old PG1.0 as well as the PG2.0 where found. The PG1.0 did not seem to be fully operational ("Target" field in the bottom of the Radio Control Window) was empty), but the PG2.0 LP seemed to be all good.

So, why can't I load the fw onto the PG2.0 LP? Could there be something wrong with the build of the app? I don't fully understand the error I get.

If so, is there any prebuilt binary somewhere that I can test with, using uniflash?

 - Micael

I apologize for not noticing that you had already referred to the prior E2E thread, thank you for clarifying.  Do you receive any errors or encounter unexpected behavior while completing the instructions provided?  What version of CCS are you using and have you considered deleting and reinstalling both the IDE and SDK?  Attached is a default basic_ble build from my work station but I do not suspect that the output file is the issue.  Are you able to detect the device advertising with a BLE scanner after resetting the board, even though the programmer shows failure?

basic_ble_LP_EM_CC2340R5_freertos_ticlang.hex

Regards,
Ryan

No worries! So now I again did the instruction again, and this is the console output, which to me looks good;

After doing this, I started uniflash, and selected the 2340 + xds110, Run actions "Run Target after Program Load/Flash Operation", using your hexfile. (binary checkbox left empty)

This gave the following console result

[2023-05-24 14:12:34] [INFO] Cortex_M0P: Flash loader: CC23xx_FLASH_LIBRARY_VERSION 3.17.09.20
[2023-05-24 14:12:39] [INFO] Cortex_M0P: Updating CRC32 field ccfg.bootCfg.crc32 @ address 0x4E02000C, based on data in the range [04E020000, 0x4E02000B]. Value changes from 0x00000000 to 0xFFFFFFFF
[2023-05-24 14:12:39] [INFO] Cortex_M0P: Updating CRC32 field ccfg.crc32 @ address 0x4E02074C, based on data in the range [04E020010, 0x4E02074B]. Value changes from 0x00000000 to 0x4C1584B6
[2023-05-24 14:12:39] [INFO] Cortex_M0P: Updating CRC32 field ccfg.userRecord.crc32 @ address 0x4E0207CC, based on data in the range [04E020750, 0x4E0207CB]. Value changes from 0x00000000 to 0x15D70E0C
[2023-05-24 14:12:39] [INFO] Cortex_M0P: Updating CRC32 field ccfg.debugCfg.crc32 @ address 0x4E0207FC, based on data in the range [04E0207D0, 0x4E0207FB]. Value changes from 0x00000000 to 0x527294A2
[2023-05-24 14:12:40] [INFO] Cortex_M0P: GEL Output: Memory Map Initialization Complete.
[2023-05-24 14:12:41] [SUCCESS] Program Load completed successfully.

Which also looks good to me. However, on the XDS110 both the yellow and red LED are lit continiously, and nothing else (none of the 2340LP LEDs are lit/flashing). I can't see anything on my BLE scanner app that I think is related. (Mind you, there's a lot of stuff in that list).

If I then pull the USB cable and plug it back, the XDS LED goes Green. (single LED). If I restart uniflash, and select verify image, do get a failure;

2023-05-24 14:33:39] [INFO] Cortex_M0P: Flash loader: CC23xx_FLASH_LIBRARY_VERSION 3.17.09.20
[2023-05-24 14:33:40] [INFO] Cortex_M0P: GEL Output: Memory Map Initialization Complete.
[2023-05-24 14:33:42] [ERROR] Cortex_M0P: File Loader: Verification failed: Values at address 0x4E02000C do not match Please verify target memory and memory map.

I could re-install, but I am quite reluctant to do so, since I still have the PG1.0 LP working, and at least this means that I can continue coding/debugging on that device.

But if we are nearing the end of ideas(?), I will give it a try.

Thanks,

 Micael

Forgot;

I have CCS build info as follows;

Code Composer Studio
 Version: 12.3.0.00005

OS: Linux, v.6.1.2-gentoo, x86_64 / gtk 3.24.37
Java vendor: Eclipse Adoptium
Java runtime version: 11.0.13+8
Java version: 11.0.13

 - Micael

That is unexpected XDS110 LED behavior, I will check with the Tools Team about this.  Also, do you see any behavior from the UART terminal?  Refer to the BLE5-Stack Quick Start Guide for further assistance.  And what is your Uniflash version?  I'd like to move you away from any pre-production silicon and am concerned that remaining resources could be affecting your environment.

Regards,
Ryan

Uniflash is 8.3.0. There's nothing on the serialport when powering the board.

Uniflash is outputting this on the console;

[5850:5850:0525/091309.778996:ERROR:sandbox_linux.cc(380)] InitializeSandbox() called with multiple threads in process gpu-process.
[5818:5925:0525/091316.790569:ERROR:chrome_browser_main_extra_parts_metrics.cc(227)] START: ReportBluetoothAvailability(). If you don't see the END: message, this is crbug.com/1216328.
[5818:5925:0525/091316.790626:ERROR:chrome_browser_main_extra_parts_metrics.cc(230)] END: ReportBluetoothAvailability()
[5854:5859:0525/091409.801697:ERROR:cert_verify_proc_builtin.cc(600)] No net_fetcher for performing AIA chasing.
[5854:5993:0525/091409.803324:ERROR:cert_verify_proc_builtin.cc(600)] No net_fetcher for performing AIA chasing.

The XDS110 is the same that I use for the PG1.0 LP.

I will download everything again, and install to a new directory.

 - Micael

OK, so I did download everything again.

Installed SDK, CCS, Uniflash & FreeRTOS into a newly created directory.

Then I followed the quick start guide, used the OAD (internal flash) project, built it (was fine after setting x flag on imgtool at the end).

(by the way, the links in quick guide to freertos guide is broken)

Started to debug, and got a well known ;

Cortex_M0P: Flash loader: CC23xx_FLASH_LIBRARY_VERSION 3.17.09.20
Cortex_M0P: Updating CRC32 field ccfg.bootCfg.crc32 @ address 0x4E02000C, based on data in the range [04E020000, 0x4E02000B]. Value changes from 0x00000000 to 0xFFFFFFFF
Cortex_M0P: Updating CRC32 field ccfg.crc32 @ address 0x4E02074C, based on data in the range [04E020010, 0x4E02074B]. Value changes from 0x00000000 to 0x4C1584B6
Cortex_M0P: Updating CRC32 field ccfg.userRecord.crc32 @ address 0x4E0207CC, based on data in the range [04E020750, 0x4E0207CB]. Value changes from 0x00000000 to 0x15D70E0C
Cortex_M0P: Updating CRC32 field ccfg.debugCfg.crc32 @ address 0x4E0207FC, based on data in the range [04E0207D0, 0x4E0207FB]. Value changes from 0x00000000 to 0x527294A2
Cortex_M0P: GEL Output: Memory Map Initialization Complete.
Cortex_M0P: JTAG Communication Error: (Error -615 @ 0x0) The target failed to see a correctly formatted SWD header. The  connection to the target may be unreliable. Try lowering the  TCLK setting before trying again. (Emulation package 9.11.0.00128) 
Cortex_M0P: Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint op-codes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

So, I figured I should once again follow the directions on activating debug access again.

So I created a NewTargetConfiguration.ccxml with a checkbox in front of the  CC2340R5.

Selected debug->NewTargetConfiguration.ccxml from the little bug icon-dropdown symbol.

But this time I get this error. (This I have never seen before)

Cortex_M0P: GEL Output: Error: Unknown debugger.
Cortex_M0P: Error initializing flash programming: Cannot switch cores while configuring

I ignore the error, and continue following the list step 2 through to 4a. And when I do step 5, I get;

CS_DAP_0: GEL Output: This GEL script should only be used when an invalid CCFF was programmed into a Loki Low Plus PG2.0.
Error code of @-614 or @-615 is expected to be thrown by the CCS before using this workaround!
UnblockLokiLowPlusPG2() cannot be evaluated.
The reset Board Reset does not exist
     at GEL_AdvancedReset("Board Reset") [unblock_loki_low_plus_pg2.gel:20]
     at UnblockLokiLowPlusPG2()

Did I miss anything in the steps?

 - Micael

Thanks for the update. Can you please try a examples\rtos\LP_EM_CC2340R5\drivers project, like gpiostandby?  Please stand by as I consult with technical experts to further review your issue.

Regards,
Ryan

That worked without any problem! No errors and debugging is also working as it should.

I used the ticlang version.

 - Micael

What about non-OAD BLE applications such as basic_ble?  OAD will require additional MCUBoot and ble_persistent flash instructions.

Regards,
Ryan

Yep, basic_ble works as well!

I did not think to test them. However OAD is what I need in my application. But I think now you are narrowing it down!

 - Micael

OAD offchip also does not work..

And I should also mention (now that I understand it is project related), that I don't remember if I tried OAD on PG1.0 or not, since I started off the SPI demo for my own work. (I did try a few different project back then, but I don't remember if I tested the OAD (or if it was even available)).

 - Micael

Hi Micael,

As Ryan mentioned, for OAD to function you will need to to flash the persistent app, the mcuboot app along with your OAD application. Have you tried this yet?

Best Regards,

Jan

Hi Jan,

No, I had not (forgot about that) but even if I do, same issue. However, if I use uniflash to load all three of them, the target will start with oad.

Maybe it is not possible to debug oad_onchip app through ccs?

Regards,

  - Micael

Hi Micael,

Let's take a step back on this thread, now you're able to run basic_ble_oad_onchip but only on Uniflash?

You can definitively debug the basic_ble_oad_onchip example on CCS but you need to flash MCU boot before.

However if uniflash works for you, it's possible to flash with uniflash and run the target configuration with CCS, it will load the symbols and allow you to do some debug. Follow the user's guide steps in the Debugging chapter Connect the debugger to a running target section. Find below a link to the debugging guide:

https://dev.ti.com/tirex/explore/node?node=A__AORV2P9xKyaQCr.Dunw8Rg__com.ti.SIMPLELINK_LOWPOWER_F3_SDK__58mgN04__LATEST

Tell me if it works for you

regards,

Hi Guillaume,

Well, yes everything seems to work, after I followed the notes from RogerMonk in this thread https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1224834/cc2340r5-oad-detailed-description/4625225#4625225

And while I understand that I can debug using uniflash and so on, but that is really awkward way of coding and debugging, so I decided to give up OAD for now, and instead use basic_ble for development. But this is so-so, since I don't really know how much RAM/FLASH I have to play with, so a working OAD project would be better already from start.

Here's what I did;

I used uniflash to flash persistent+mcu_boot, then I tried to compile+debug the oad onchip, but I guess the ccs is clearing the flash before downloading oad app, and this is the whole issue I have had all along (just that, now I know much more than in the beginning of this thread) ;-)

It should be said though, that the "The target failed to see a correctly formatted SWD header..." error is a bit annoying. Even if everything isn't good, why can't I be able to load the firmware and then continue to use the debugger? Why is the swd stuff not working?

So anyway;

If there's a way to either load the mcu_boot and persistent (if needed?), during oad onchip app debug download,

OR

Load mcu_boot+persistant with uniflash, and not having it erased whenever I push debug in oad app developement, it would be super nice.

But I struggle with this, since I cannot really find much documentation on how it is supposed to work? Everything is spread out in different threads and instructions here and there.

Regards,

 Micael

Hi Micael,

I understand your point of view and take your feedback in consideration, OAD needs to be more documented.

For the basic_ble example you can estimate the size of different memory in the .map file located in your <DEBUG_CONFIGURATION> folder (Release or Debug), it's always good to know.

Concerning the OAD set up part, I will ask the right expert to help on this, cause I don't think it's a normal behaviour or we just miss a step here.

Finally, did you manage to connect the debugger to the running target flashed with Uniflash?

Regards,

Hi Guillaume,

Yes, I have been using the map file, its summary is rather good, and I am estimating (for now) that I have almost 300KB of flash to play with for my application, and the rest is needed for mcu_boot and the persistant image. I hope mcu_boot and persistent is not "stealing" much ram.

I guess, it would be good for me to know how you intend it to work; should the mcu_boot and persistent app be programmed once, and left alone while debugging oad app, or is the intention that the oad app should also program the mcu_boot and persistent app every time?

TBH I never tried connecting the debugger to the running oad, because I felt that I had spent too much time trying to get the oad app to work, and I figured that I would anyway struggle to work like that, so my interest spending time with that did not appeal to me.

Looking forward to learn what my mistakes are,

 - Micael