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.

AM2634-Q1: am2634

Part Number: AM2634-Q1

Tool/software:

Hi,

Have a query related to external Watchdog when we use TPS653860A-Q1 with AMS2634-Q1.

1. Can we keep refreshing the external WD over SPI from cluster 0 (core 0 and 1 in lockstep) and cluster 1 (core 2 and core 3 in lockstep ) in windowed WD?

2. If yes, In case cluster 1 is stuck and not able to refresh external WD, cluster2 can continue refreshing the WD and allow the micro to run 

Regards

Sunil

  • Hello,

    I will look into this at the beginning of next week.

    Thank you,

    Susan

  • Hello,

    Apologies for the delay in looking into this. 

    To be clear, you are trying to keep the external watchdog on the PMIC from triggering by using two different SPI signals (one for each lockstep core). Is that correct?

    Thank you,

    Susan

  • Hi Susan,

    We are thinking like this:

    1. Cluster1 would have primary responsibility be refreshing the WD via SPI 

    2. Whenever it does, Cluster1 would communicate to cluster2 via IPC that this refreshing has been done.

    3. In case cluster1 fails to update WD, IPC will be missed and cluster2 can takes over the responsibility of refreshing the WD.

    It is possible that in step1 or step3, . SPI communication might have failed and PMIC would decide to reset the micro.

    Not sure, we can really differentiate which cluster missed to refresh WD in such case.

    Do the above steps technically possible? or how you suggest the PMIC WD comms from a multi-core point of view as a guide?

    Regards

    Sunil

  • Hello,

    So your use case makes sense, and should be possible. You will need to pay attention to the timing of the IPC so that you don't miss the WDT Window while communicating between cores.
    As for failure analysis, you could use a MUX or external flip-flop circuit, but that would consume additional pins on the device.

    It might also be possible to use registers/memory on the PMIC to do a readback on the SPI communication to see which cluster triggered a fail, but I would recommend reaching out on that matter separately.

    Thank you,

    Susan