• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 55 subscribers
  • Views 262 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2340R5: The initialization froze after the restart

?? ?
Prodigy 80 points
Part Number: CC2340R5

Tool/software:

Use 2340 as the node and 2652 as the coordinator. The serial port data is sent through the upper computer, and then the 64-byte serial port data is sent to the other party. Conduct bidirectional data transmission. The upper computer of the serial port on the other side of the node sends data every two seconds, and the coordinator sends data every five seconds.

During the process, I found that the program had crashed. I suspect that the program restarted and then got stuck at initialization. The following is a screenshot of my debug

  • 0
    TI__Guru**** 217867 points

    Hi,

    Unless you have followed the necessary steps to Connect to a Running Target then these debug images may not be reflective of the actual issue.  Can you please state why you believe the firmware restarted on its own (i.e. without user intervention), and are you able to put a breakpoint at this location using the CCS debugger to further determine the root cause?  Are you able to enable logging to determine what errors or messages are being transferred by the Zigbee MAC, OSIF, or application layers?

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 80 points

    Hi Ryan
    我是在程序死机后，按照Running Target步骤操作的，这些截图就是按照Running Target步骤出来的调试图。

    我认为固件重启，因为我挂测了几个小时后，程序才跑死的，我看到死机的地方好像在zb_init()

  • 0 in reply to ?? ?
    Prodigy 80 points

    Hi Ryan
    I operated according to the Running Target step after the program crashed. These screenshots are the call attempts that came out according to the Running Target step.

    I think the firmware has restarted because after I tested it for several hours, the program finally crashed. I noticed that the place where it crashed seems to be zb_init().

  • 0 in reply to ?? ?
    TI__Guru**** 217867 points

    The location of zb_init (zb_osif_random_hw) indicates that the RNG is unavailable to generate a random number, thus a forever while loop is entered.  The RNG resources values from the radio which may not be initializing properly after the soft reset.  Can you use zb_get_reset_source/PMCTLGetResetReason to properly determine the reset reason?  Are replication steps available?

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 80 points

    Hi Ryan
    I add zb_get_reset_source/PMCTLGetResetReason observation after a period of time see reset reason is what

  • 0 in reply to ?? ?
    TI__Guru**** 217867 points

    Please clarify your findings, as I did not understand your last message if it was meant to provide more information.  Also please put breakpoints inside of zb_reset -> PMCTLResetSystem and FATAL_ERR during debugging, then provide the call stack if these functions are ever entered.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 80 points

    Hi Ryan
    I found that PMCTLGetResetReason returns 0x36, which means watchdog reset, and zb_get_reset_source returns 5. It means "/* RSTSRC_WAKEUP_FROM_SHUTDOWN or RSTSRC_WAKEUP_FROM_TCK_NOISE or RSTSRC_WARMRESET */"

  • 0 in reply to ?? ?
    TI__Guru**** 217867 points

    Hi,

    RSTSRC_WARMRESET is commonly a watchdog reset as well, and since RSTSRC_WAKEUP_FROM_SHUTDOWN or RSTSRC_WAKEUP_FROM_TCK_NOISE do not make sense in this context then you must be encountering a watchdog reset.  Can you detect the reset reason/source before zb_init and consider implementing a full system reset instead (PMCTLResetSystem) to determine whether this works around the issue?

    We have not yet determined why the watchdog reset is occurring.  I mentioned before to put breakpoints inside of zb_reset -> PMCTLResetSystem and FATAL_ERR (also Exception_handlerSpin) during debugging to determine whether the application is being held in a forever while loop.  

    Regards,
    Ryan