This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Tool/software:
Hi all, we are dealing with an application porting from CC1352P1 to CC1352P7: with CC1352P1 OAD is running perfectly. When we try the same with CC1352P7 some issue arises:
- once a reset is issued to give control to the BIM, the application is no longer valid and control should be passed to the "persistent" application through a phsysical reset of the processor. Persistent application is exactly what we downloaded from the resource explorer, changing only the I/O used to drive the antenna switch and relative CB, exactly the same we did on the CC1352P1. It is very easy to detect the persistent is running by what is printed on the serial comm: "TI Sensor (Persistent App)" . Then the following message is printed on the OAD status line "Transferring Block 0 of 1041" and the process stalls there. That is, the persistent is completely not responding and no action can be done through the comm itself. Note this status message indicates:
- the persistent has been invoked after the reset
- the OAD process in persistent app has been correctly started
Beyond this message, all is crashed.
On the CC1352P1 with the same procedure, all is correctly running: is there any further difference? Or a different setup to get OAD functioning independently of the underlaying processor?
Thanks
Luigi
Hello Luigi,
Thanks for reaching out. Could you please help me with the following questions to better understand the issue?
BR,
David.
Hi David,
here are my replies:
What I can say to help you is the following flow I traced with the ICE:
We do not use BLE in our application,
Hope this can help
Sincerely, Luigi
Hi David,
from the following pic, I can argue
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:
Now let me reply to your questions:
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:
Cheers,
Marie H