CC2640: debug cannot start

Hello Luigi, thank you for reaching out to us with a detailed description. 

The root cause of your issue is an SDK/Device mismatch. The project you imported "project_zero", is from the "simplelink_cc2640r2_sdk_5_30_00_03", but your hardware is a CC2642R1F, which is a completely different device family. Simply changing the target processor or linker file will not rectify your issue. The pre-built BLE stack binaries included in the CC2640R2 SDK are compiled specifically for the CC2640R2 and are binary-incompatible with the CC2642R1. This is why Case 1 fails, as the binary tries to flash to the wrong memory layout. As for Case 2, the linker file conflicts arise because you're mixing a CC2642 linker with a CC2640R2 SDK that has its own embedded linker references in the pre-built stack libraries.

The correct solution to your issue is to migrate to the CC2642R1-compatible SDK. You need to be using the correct SDK for your device:
1) Download and install the SimpleLink CC13xx/CC26xx SDK which supports the CC2642R1
2) Import the "project_zero" example from the new SDK (not the CC2640R2 SDK), in CCS go to:

File → Import → SimpleLink SDK → BLE5 → project_zero → CC2642R1F

In the CCS project properties, set your target device to CC2642R1F. This will now be consistent with the SDK binaries. Please do not mix project files, linker files, or stack libraries between the CC2640R2 SDK and the CC2642R1 SDK. 

Let me know if this solves your issues Luigi. Have a great Monday!

Hi Mopel,

yes what you suggested runs. But another issue arised: upon main() entry, there is no cleared ram at all. So, when code reaches the following function:

void HEAPMGR_INIT(void)
{
heapmgrHdr_t *tmp;

if (heapInitialize == 1)
{
// Initialization already done. Only once initialization allowed.
return;
}

it returns immediately and then the processor enter a state where this diagnostic is issued: "Cortex_M4_0: Error: (Error -1170 @ 0x0) Unable to access the DAP"

The same behavior happens with the original project_zero at the same point. I think there is a linker command missing to clear the entire used ram section, else I don' t know how to proceed

Note I put a BP on AssertHandler () entry, but the processor never halts there: every time I step the ICall_registerApp(&selfEntity, &syncEvent); statement, the behavior is what I depicted above: stepping into, control reaches HEAPMGR_INIT and there I think there is an issue

Really I' m getting crazy to understand why this happens. Please can you help me? Thanks Luigi

Hello Luigi,

Glad the SDK migration resolved the previous issues! The new problem you're experiencing is a RAM initialization issue, specifically; the
.bss section (which holds zero-initialized global/static variables like heapInitialize) is not being cleared to zero before main() is entered. This is a linker/startup configuration problem. I will provide you with some context to your problem, then I will explain some courses of action you can use to potentially solve your issue. 

On Cortex-M devices, the C runtime startup code (typically in startup_*.c or the reset handler) is responsible for zeroing the .bss section (uninitialized globals/statics must be 0 at startup) and copying the .data section from flash to RAM. If this is not happening, variables like heapInitialize retain garbage values from a previous run or power cycle, causing HEAPMGR_INIT() to skip initialization entirely and leave the heap in a broken state, which then crashes the system.

Now that you have some context to the problem, I would like for you to try these potential solutions first:

1) Check your linker command file (.cmd), and make sure your linker file defines the .bss section correctly and that it is properly placed in RAM. In your CC2642R1 project, open the .cmd file and verify you see a section of code like:
 

.bss : {} > SRAM

Also, please confirm SRAM is properly defined in the MEMORY {} block with the correct base address and size for the CC2642R1.

2) Verify your Startup/Reset Handler by checking your startup_cc26x2_ccs.c (or equivalent) file. The reset handler must zero-initialize .bss. Look for a loop like:

// Zero-fill the .bss segment
uint32_t *bs = (uint32_t *)&__bss_start__;
uint32_t *be = (uint32_t *)&__bss_end__;
while (bs < be) {
*bs++ = 0;
}

If this loop is missing or the symbols are not correctly defined, .bss will not be cleared. Make sure you are using the startup file that came with the CC2642R1 SDK (not one carried over from the CC2640R2 project). <- I actually think this may be the cause of your issue.

3) Confirm you're using the correct Startup file in CCS. In CCS, go to: Project Properties → Build → Linker → File Search Path Ensure the startup file linked is: startup_cc26x2_ccs.c, from the CC13xx/CC26xx SimpleLink SDK (not a CC2640R2 variant).

After trying these potential solutions, please update me on the state of your project. I hope the information above helped. Please reach out again if you have more questions Luigi. 

Hi Mopel,

I took some screenshots of what' s happening and to me there is something very strange. Note the same behavior is common to both application: original project_zero and what I migrated from it, called move: you can see it on every pic
As you can see, I did the same operations for both application:

• pic#1:
• put BP just at the entry of _c_int00
• run code up to __TI_auto_init();
• check the value in heapInitialize (it should be a random value)
• step once to reach the following statement _args_main()
• pic#2:
• heapInitialize is preloaded with value 1: I THINK THIS IS AN ERROR DUE TO LINKER MAPPING
• pic#3:
• run code till ICallHeapInit ()
• check the value of heapInitialize: it should be 0 as per declaration of :static hmU8_t heapInitialize = 0;
• instead it is 1 and from here on, the code probably hangs somewhere arising the "Cortex_M4_0: Error: (Error -1170 @ 0x0) Unable to access the DAP" and the debugger lose completely control
• the same behavior is verified for project_zero application: in fact, to derive the Move application, I simply imported project_zero and changed its name: so there are no changes between the two and the behavior is the same as expected

Now I' m asking why heapInitialize is preloaded with 1: it seems this variable is loaded from a wrong section but this is linker job: the linker command file is  the original imported, so why this behavior? How can I fix it? Have I to redefine some linker command?

Waiting for your help

Luigi

Hi Mopel,

let me add some more infos.
Please check the following with the aid of the attached pic:

• I'm dealing with original project_zero only
• put a BP on 1st entry in _c_int00 () to trace the flow from board reset
• put a BP on 1st entry of HEAPMGR_INIT ()
• free run (F8)
• it stops at HEAPMGR_INIT () and this is surprising: I expected this function would have been called from main () where there is an explicit ICall_init ();
• you can trace the stack calls as: 
• _c_int00 ()
• __TI_auto_init_nobinit_nopinit ()
• __TI_auto_init_template ()
• ti_sysbios_runtime_Startup_exec ()
• BIOS_init ()
• ti_sysbios_heaps_HeapCallback_init ()
• osalHeapInitFxn ()
• ICall_heapInit ()
• so this function is called prior to ICall_init () in main () and this is why in the subsequent call heapInitialize is 1
• further stepping, let' s arrive at ProjectZero_init () which is called inside the project_zero task: something happened at this point so the next statement (ICall_registerApp (&selfEntity, &syncEvent)) fails
• stepping once to enter ICall_registerApp, the debugger is lost at the 1st statement ICall_TaskEntry *taskentry = ICall_newTask(Task_self());
• once stopped at ICall_registerApp (&selfEntity, &syncEvent), using assembly stepping the debugger seems to execute correctly, buy it stops working at the execution of the statement ICall_enterCSImpl();

It is my opinion something happens before reaching this instruction. Any idea?

Sincerely Luigi

Hello Luigi, 

You are using a custom board yes? With this in mind, there are a few things I want you to do so that I can become more acquainted with the delta that is between our system, and yours. First, I would like for you to go to your .syscfg file, and click the two arrows that are facing away from each other. Then, click on the blue logo saying "Use Custom Board".

The next thing I would like for you to do is, on the .syscfg configuration panel, select the Device Configuration tab under the TI Devices category. In the row titled: Low Frequency Clock Source, please select the parameter that best matches the setup you have on your board. 

I have some resources that further explain how to use a custom board with our software, please refer to the following links to learn more on how to integrate your custom hardware with our software:

https://dev.ti.com/tirex/explore/node?isTheia=false&node=A__AORV2P9xKyaQCr.Dunw8Rg__com.ti.SIMPLELINK_CC13XX_CC26XX_SDK__BSEc4rl__LATEST    

https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_8_33_00_16/docs/ble5stack/ble_user_guide/html/sysconfig/sysconfig-board.html#migrating-board-variant  

https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_8_33_00_16/docs/ble5stack/ble_user_guide/html/cc13xx_cc26xx/custom-hardware-cc13xx_cc26xx.html#custom-hardware 

Lastly, feel free to submit your custom board design to this link: https://www.ti.com/tool/SIMPLELINK-2-4GHZ-DESIGN-REVIEWS Engineers on our team will look at your design and help you troubleshoot any faults that could be due to hardware design. 

Hi Mopel,

Really my custom design is a basic copy of the original Launchpad cc2642/2652 schematic with unsignificant changes. Anyway, to avoid any problem, I' m dealing with Project_Zero on my custom board (populated with CC2642). I tried the following:

• with the debugger, in main(), I skipped the execution of ICall_createRemoteTasks(), so no more tasks will be created.
• at this point, the only task running in the system is ProjectZero with its ProjectZero_taskFxn task function.
• obviously there are no performances available, but the system is stable: that is, there are no longer problem with the debugger, say DAP error, I can pause the processor, resume it, all debugger functionalities are available, no problem
• this leads to me to think there is something in the system which is not running correctly: really what the ICall_createRemoteTasks() will provide is to create and run system process which are really hidden to the user (me) and I think these are to be running with no problem at all: this is not, so I fear there is something I don' t know and cannot inspect which will prevent all to run
• consequently, my questions is: why the DAP is no longer available? Could it be the processor JTAG peripheral becomes unpowered? Who is unpowering the JTAG? the 1st statement in main() does not allow power manager to remove power to all so I think the JTAG should always be powered
• i attached the scope to JTAG signals: TCK and TMSC: when all is running with no problem, the signals are like in pic #1, where the communication with the debugger is lost, these same signals are as in pic #2
• to me, both are driven from the Launchpad TM4Cxxx USB hub/debugger controller, but I don' t understand why the TMSC line seems to be hi-z in that case
• in ProjectZero_init () there is the following comment:
• // ******************************************************************
  // NO STACK API CALLS CAN OCCUR BEFORE THIS CALL TO ICall_registerApp
  // ******************************************************************
  // Register the current thread as an ICall dispatcher application
  // so that the application can send and receive messages.
   ICall_registerApp(&selfEntity, &syncEvent);
• since this last function will cause (or manifest) the problem, I fear here there could be some stack API calls can be made as a consequence of having created run time remote tasks as previously mentioned
• this is enforced by the fact this call is the 1st call when ProjectZero_taskFxn is run
• but this task has the lowest priority, so very probably some other tasks with higher priority can be run and the question is: are these tasks providing stack API calls and this can become the source of the problem?
• unfortunately, there is no documentation at all provided for these functions and I am completely blind to detect the source of the problem
• I' ll tried to move the ICall_registerApp(&selfEntity, &syncEvent) in ProjectZero_createTask(), that is before the ProjectZero_taskFxn 1st run: it completes with no issues but now the same problem ("Cortex_M4_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.12.0.00150)") is moved to the 1st statement of ProjectZero_init() which now has become
• Queue_construct(&appMsgQueue, NULL);
• this is convincing me there is something somewhere which is shutting down the JTAG peripheral
  
  

I' m completely stuck and with no idea, so please help me

Waiting for some support, sincerely, Luigi

Hi Luigi,

I've merged your E2E post with the original E2E thread, my thoughts are that whatever roadblocks you were experiencing at the time you tried to reply were temporary flukes that have now been resolved.

I am unfamiliar with the Launchpad TM4Cxxx debugger and am concerned that it is not fully supported by SimpleLink F2 CC13XX / CC26XX devices.  Previously you had mentioned XDS110 usage, are these one in the same? It is evident that you were able to program the device, but there are additional issues when running the device during a debug session.  There could be a flaw in the JTAG lines that is causing communication issues, I would ask that you confirm the lines are as short in length as possible.

Just for your awareness, project_zero is intended to be run with a BIM application for OAD operations, and expects a connection to external flash memory.  This is explained further in the README I linked as well as the BLE OAD SLA.  What this means is that you may be able to start the application through the CCS debugger, but subsequent restarts or power cycle will cause failure of the firmware to start.  Given the issues you are currently experiencing, I recommend starting with basic_ble or even a BLE-less TI Driver example (like empty or pwmled2) just to confirm that your hardware is capable of running CC26X2R firmware.  It would still be good to select "Use Custom Board" such that APIs are not incorporated into the startup process which control the previously mentioned external flash memory, in case you have not chosen to include this in your custom PCB.

Regards,
Ryan

Hi Ryan,

thanks for your support.
open questions:
1) I can confirm you that the JTAG lines are not only as short as possible but, on the probe I use to connect Launchpad to my target, they are also compensated for "relative propagation delay" with a trace length difference < 20 mils and a phase shift < 0.088 ns (this is because I designed that probe specifically to be non-intrusive). The pics of the signals I sent to you are taken directly from the pins of the target processor and it seems to me there is no problem.
2) the JTAG failure happens in a particular state of the code: when it tries to register the app through ICall_registerApp(), which is a function provided in the TI development tool SimpleLink. It seems to me that, "stepping over" a function with debugger command F6, there is something running below that creates some problem and the JTAG is finally unpowered (I suppose this, but I cannot prove it since after this all becomes unfunctional). So, to try to detect the failure point an cause, I tried different test:
a) put a key = ICall_enterCSImpl(); statement at the entry of ICall_registerApp(), putting a BP just after its execution: in this way, I created an atomic behavior of what is is the ICall_registerApp() procedure to check what it does: in this way the debugger is normally alive, no problem at all, all this procedure does is initializing some structures. This greatly enforce me in thinking there is some code run during the execution of the "step over" debugger' s command that causes the hang up. But which code? I don' t know, I think stack or library code but this experiment is clear enough. So I put a ICall_leaveCSImpl(key); call which ends the atomic behavior just depicted. And what happens? The same problem already signaled arises trying to "step over" the next instruction (which is a Queue_construct(&appMsgQueue, NULL);: the debugger error "Cortex_M4_0: Error: (Error -1170 @ 0x0) Unable to access the DAP" is issued again and the debugger is dead. Really I don' t know what to think and my last thought is: could it be the CC2642 library has some difference with CC2652 which is installed on the dev board and this difference is causing this issue? Really I do not know what to think next.
Please note I already delivered the full HW design to be checked to the address (connectivity-24ghz-hw-review@list.ti.com) Mopel signaled me and I' m waiting for the reply. In any case, I' m sure there will be no issues reported because all is running well, when it runs, but I really mind the cause of this hang. I' m completely stuck with no more ideas how to do. Further, documentation does not help me, but I will read it again once more. I will try your suggestions
Thanks, help me

Here is the BLE-Stack Debugging Guide for what it's worth.

luigi Desiderato said:

all is running well, when it runs, but I really mind the cause of this hang

Is your application functional during run-time?  So you are focusing solely on JTAG disconnections during debug when you step through code?  Confirm that you are using the correct Dependencies for your SDK.  You can modify JTAG frequency from your CC2652R1F.ccxml file, in case it helps.  Stepping through ICall tasks is not typical or recommended.  Have you tried simply running to the BLE application task?

Regards,
Ryan