LP-CC1352P7: OAD crash with CC1352P7

Hello Luigi,

Thanks for reaching out. Could you please help me with the following questions to better understand the issue?

1. What steps are you following to migrate from CC1352P1 to CC1352P7? Running Software Examples on the CC13x2x7 or CC26x2x7.
2. What device are you using as central? Is it a phone running the SimpleLink Connect mobile Application?
3. What SDK version are you using?
4. How are you flashing the bim, persistent and application binaries? If you are using UNIFLASH, would you mind attaching a screenshot that shows the addresses you are using for the binaries?
5. Could you please try running the OAD process using BTool?

BR,

David.

Hi David,

here are my replies:

1. created a new workspace named P7 (to have a clean workspace)
2. imported the "sensor" example
3. added all custom files linking them from the P1 related workspace: particularly, the sensor.c has some features added which are specific to our job, but nothing has been changed of the basic architecture. In any case, these features are all under a compilation flag useful to avoid them in the final code
4. changed the sysconfig file to get the antenna switching compatible with our HW and adjusted the rfDriverCallbackAntennaSwitching procedure according to the same
5. we are using the Linux consolle to send OAD commands: please note all these steps are perfectly working with P1 processor
6. either BIM and Persistent were added from the resource explorer and for Persistent we changed the same as previous point 4
7. sdk = simplelink_cc13xx_cc26xx_sdk_7_41_00_17
8. all three binaries are originally loaded with Uniflash: check the attached pics: please disregard what encircled in red (the ICE board) because we are using only the debugger of that board and the owned processor is completely isolated: we have a custom flat to connect this ICE to our board

What I can say to help you is the following flow I traced with the ICE:

1. when the command "w" is reached from Linux shell, the application saves some connection data to NVRAM which are used as a shared memory to the persistent and invalidates its code
2. then a reset is generated to give control to BIM
3. BIM verifies the application is no longer consistent so cease control to the persistent
4. persistent then reads connection data and starts to join
5. after join the OAD process can start but after printing the first OAD status ("Transferring Block 0 of 1041") it hangs
6. it is very difficult to check where the hang happens
7. obviously, if you restart the board, the BIM repeatedly cease control to persistent, but the process stalls again

We do not use BLE in our application,

Hope this can help

Sincerely, Luigi

Hi David,

from the following pic, I can argue

1. a reset is correctly issued by the application
2. persistent correctly takes control from BIM
3. persistent re-joins the network, so data saved from te application is consistent
4. OAD process is started, but

persistent hangs.

Hope this can help

Sincerely Luigi

Hi Luigi,

Let me try to summarize:

1. You are using the TI 15.4-Stack sensor_oad_onchip_secure, sensor_oad_onchip_persistent_secure and bim_onchip examples.

2. You have a CC1352P7 device mounted on a custom board

3. You are using the LP_CC1352P7_1 version of the examples and the only code change you made was reassigning the antenna switch pin.

a) Can you post a sniffer log of the sensor (running the persistent app) rejoining the network and up until it hangs? This should tell us whether it's the sensor or the OAD distributor that stops the OAD process.

b) Can you perform this test with a debugger attached and pause the debug session when the device hangs? This will tell us if it's actually hanging. Please post a screen shot of the call stack.

Cheers,

Marie H

Hi Marie,

prior to reply to your questions, please let me tell the original TI project does not work itself. Let me explain:

1. I took out of the box a new CC1352P7-1 dev board: check attached pic
2. with Uniflash, I flashed the BIM, the sensor and persistent apps after loaded from the resource explorer and compiled
3. I set the correct PANID to get the board joined and this is
4. I try to run an OAD session with our Linux consolle
5. the dev board replies correctly to a sw version request (command "v")
6. the board replies correctly to a hw version request (command "b")
7. when we try to launch the command "w" (OAD process) the same error we are encountering in our board appears: the dev board stalls
8. then I loaded the user sensor app through the CCS debugger and launched it
9. the corresponding COM port displays all UI possibile actions
10. as previously, I set the PANID to recognize the board on our network and it joins correctly
11. from the same Linux consolle, I launched an OAD session and the bug arises: from Putty nothing is longer working
12. so I decided to try to detect where the problem hides in the persistent app reloading it in the debugger
13. after the dev board has been joined, I put a BP on the entry of OADClient_processEvent to trace what happens
14. I stepped every statement till line 392 where there is a call to Ssf_setPollClock
15. stepping over (F6) once again the stall arises
16. suspending the run, I found the code is stalled in Main_assertHandler procedure, with a assertReason = MAIN_ASSERT_HWI_TIRTOS (4)
17. now I will retry this process with the dev board to check more deeply what happens from Ssf_setPollClock and I will let you know

Now let me reply to your questions:

1. yes
2. yes
3. yes

To me it is unuseful to attach the sniffer since it appears quite clear the problem arises inside the persistent app. Please note this does not happen with the same procedure repeated on a CC1352P1 board nor with our custom HW

Hope this could be useful

Sincerely, Luigi

Hi Mari,

a very strange thing happens repeatedly: the user app sometimes hangs just after re-joined: could it be a stack misdimensioning and a consequent RAM corruption? I' ll investigate and let you know

Cheers Luigi

Hi Luigi,

Apologies for the delayed response.

Since you're getting a hw exception I would recommend you the following section in the Debugging guide: Deciphering CPU Exceptions:

https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_7_41_00_17/docs/ti154stack/html/ti154stack-guide/debugging-index.html#deciphering-cpu-exceptions

Cheers,

Marie H

Hi all,

some months ago I raised a question (actually closed: e2e.ti.com/.../5428478 about OAD not functioning on CC1352P7 processor, while the same was perfectly working on CC1352P1/P2. At that moment we do not had to download any new version of our application, but in the last month this was urgent. I tried to trace why this happens and here is the result:
I' m dealing with the persistent application (sensor_oad_onchip_persistent_secure_LP_CC1352P7_1_tirtos7_ticlang) out of C:\ti\simplelink_cc13xx_cc26xx_sdk_7_41_00_17 library, and what I verified is the source for either processors (P1/P2/P7) is the same: anyway, when downloaded on the P1/P2 processor there is no issue arising, when used for the P7 there is a crash immediately after the remote sensor reset request. The only difference between P1/P2 and P7 processor is the memory size and map but there is no possibility the same code can behave differently just because a different memory map (FLASH_SIZE from 0x00058000 (P1/2) to 0x000B0000 (P7), RAM_SIZE from 0x00014000 (P1/2) to 0x00024000 (P7).
Skipping what is the OAD functioning model, this is the sequence on the sensor:
- join with a collector: communication data and key are locally stored to sensor NVRAM to be used later by persistent
- a reset is issued
- after this, BIM launches persistent app which will use the same data to re-join the collector then the OAD will start
Tracing persistent, a crash is generated just after the reset response is sent back to the collector when a polling timer is addressed: BUT THAT POLLING TIMER (please refer to pollClkHandle in ssf.c source) was never created before, so its handle is NULL and this is the cause of the RTOS crash. So where is that timer created? Fortunately only in Jdllc_init procedure, where it is enclosed in a compile option as follows:
/* Initialize poll clock */
if(!CONFIG_RX_ON_IDLE)
{
  Ssf_initializePollClock();
}
Where is or who sets CONFIG_RX_ON_IDLE? It' s Sysconfig, where there is a checkbox to be unchecked for Sleepy device (ours sensors are non-sleepy devices, so this flag must be checked for the application either): if you check this flag, the above code will be never compiled and the timer never created, so the crash arises as soon as that timer is referenced with a NULL handle during OAD process. If you uncheck that flag (that is you assume your sensor IS A SLEEPY device), the poll timer is created and hence all the OAD process comes to a positive end with non errors.
Now, 2 questions:
1) why in the P1/P2 project version this flag is checked, really its behavior seems to be coherent and there is no issues on the OAD process while on the P7 it behaves as if it is inverted? If you analyze both the .syscfg files (P1/P2 vs. P7 project) with a text editor, depending on the check status of the sleepy device flag, you can / cannot find the following statement
ti154stack.rxOnIdle = true;
in the P7 .syscfg but no any in the P1/P2 .syscfg and this probably is the cause for the compiler to behave differently (that is skipping the compilation which leads to the issue I' m describing)
2) since in the sources there is a lot of statements under conditional compilation of CONFIG_RX_ON_IDLE clause, what is the global behavior if this flag is inverted? What I can say is, for the OAD process, the P7 persistent app is correctly performing with that flag unchecked (leaving it checked for the application), the P1/P2 persistent app is correctly performing with that flag checked (and it is checked on the application too).
It seems to me there is plenty of changes in Sysconfig moving from one processor version to another or from one library version to another and most of compilation variables are not documented enough or undocumented at all, hence a lot of time to understand what' s happening has been lost.
Hoping this will help,

sincerely Luigi