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.

LP-CC1352P7: OAD crash with CC1352P7

Part Number: LP-CC1352P7
Other Parts Discussed in Thread: CC1352P7, UNIFLASH, SYSCONFIG

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?

    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