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: Reset reson 0x66(Analog FSM timeout)

Part Number: CC2340R5

My customer is running the remote controller demo smart_remote_control_digital_LP_EM_CC2340R5_840 on their custom board. They are having a reset problem, the device resets shortly after powered up. The read-out reset reason is 0x66(

PMCTL_RESET_ANALOG_FSM_TIMEOUT).
There are several findings from debugging:
1. The board does not have a 32kHz crystal, and the LF clock source is set to RCOSC.
2. If debugging the device in CCS, the device does not reset.
3. After switching the power policy to doWFI, the device does not reset anymore.
Based on above behavior, it looks the issue is related to the LF clock, but the project is already using RCOSC.
I have not seen the 0x66 reset reason before, what could cause this reset reason? I am hoping the reset reason can provide a clue for the next step.
Best regards,
Shuyang
  • Hi !

    That the issue is that the HFXT Amplitude Compensation process is timing out. When the device first boot and when it enters standby, it will use a Timed Finite State Machine (FSM) to compensate the HFXT amplitude. The reason why this FSM is timed is because it is possible that it gets stuck in the RAMP0 state. If the timeout is reached and the FSM is indeed stuck, the HFXT is not usable and the device will reset.

    The reason why you do not see this bug while debugging in CCS is because the device never enters standby when a debugger is connected. You also do not see this issue while selecting the doWFI policy, because it prevents the device to go in standby.

    Using a HFXT is mandatory for using the radio, which is a core feature of the remote controller demo. Could you please tell me if your custom board contains a high frequency crystal oscillator (48MHz) ?

    Kind regards,
    Lea 

  • Hi Lea,

    The customer has found the reason, which turned out to be the power supply configuration. Their custom board is using LDO mode, but did not use the corresponding software configuration. Somehow it impacted the clock and lead to this issue.

    The issue is solved now. Thanks for the support!

    Best regards,

    Shuyang