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.

DM814x: question on reset

Hi,

We checked the Reset Management section of DM814x TRM and have some questions. Would you pls help?

1. What does the blockable mean in blockable reset, such as SW global cold reset, Pin Warm Reset(RESETz) and reset resource blockable in below table? Does it mean the reset will wait for some HW module finishes own operation or some HW module will not be reset?

2. What does the number after Y or N mean in below table, such as N3, Y1, Y5, etc?

 

  • hi Chris,

    About 1. I am currently investigating it, and I will come back to you when I have the answer.

    About 2. All these numbers after Y and N should be superscript, for example N3, Y1, Config pins latched4, etc. And we have the corresponding table notes missing:

    1 Some special IOs like test and emulation related will not be reset.

    2 Some special IOs like test and emulation related muxing will not be reset.

    3 Only true if GMAC switch reset isolation is enabled in Control Module MMR, otherwise will be reset.

    4 Config pin latching uses a three latch 2 out of 3 voting mechanism for each config pin (for increased robustness). For each config pin there will 3 separate transparent latches, all latching upon deassertion of PORz or RESETz reset (no clocks required), best 2 out of 3 decides the value to finally capture in the boot configuration register (CONTROL_STATUS) for each corresponding pin.

    5 This happens indirectly, the isolation enable for GMAC switch can never be set since all cores are held in reset and so Cortex-A8 ARM can never alter the bit. Thus full GMAC should get reset in this case.

    6 RSTOUTn pin asserted only in case BOOT11 = 0 (latched from gpmc_ad11 pin). For pin reset conditions (PORz and RESETz), the pin is asserted only after the bootstrap value is latched (therefore asserts during internal stretched version of the reset, but not during assertion of the external pin).

    Best regards,

    Pavel

     

  • Replied from Greg:

    I checked with design team..

    The additional qualifier on watchdog resets of “only emulation” is a bit misleading because the same exact qualifier applies to all the other resets which are marked “blockable”.

    These resets can be blocked through debugger tools only.  there is no functional configuration which can possibly block any of these resets.   so for debug purpose only, via debugger, one can block the resets  (all the ones indicated as blockable in the table).

    the only exception is the SECURE watchdog which is NOT blockable at all.  SECURE watchdog though I’m assuming is not even documented for a gen purpose device.

    thanks
    Greg