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.

AM623: MCU_ERRORn during boot

Part Number: AM623


Champs,

Figure 6-1259. Power-up/Boot Timing Chart in the TRM shows that the MCU_ERRORn is supposed to transition from low to high upon successful boot but there is no explanation how it is supposed to happen and who takes care of it. My customer would like to use the signal as an indicator of successful or failed boot and would like to better understand the handling of this pin during boot process. few questions here:

1. MCU_ERRORn is always driven low coming out of reset, correct?

2. Does ROM boot loader do anything on this pin (SMS0/M4 ROM)?

3. Referring to TRM's Figure 5-3. Boot Process: assuming successful boot the MCU_ERRORn is driven high at some point after Image Integrity verification. Where exactly does it happen?

4. Assuming the boot failed and the M4 WD timed out after 3 min: the MCU_ERRORn should stay low waiting for R5 reset. Can it be used as a reliable indication of the failure, i.e. will it always end up there regardless of the boot scenario, correct?

Thanks

Michael

  • Hi Michael, the MCU_ERROR signal is an output of the ESM module and is not used by the ROM code.  During active reset (ie, when PORz signal is active), the IO has an internal pull down to keep the signal low.  Once reset is deasserted (to the SoC, and subsequently to the ESM module), the ESM module will drive the signal high indicating no error (MCU_ERRORn defaults active low), but at this point the ESM module would need to be configured by the application before begin used.  The ROM does not do this, but the bootloader could (I'm not sure if the current u-boot in the SDK uses the ESM, but this certainly could be configured to be used.)

    I don't think the MCU_ERRORn signal was intended to be used so early in the boot process as you describe.  It was more for application level errors, and a prerequisite is that you have to configure the ESM module for things like interrupts, signal type, etc.

    Regards,

    James

  • James,

    If I understand correctly the ESM will drive the signal high as a result of the propagation to the reset de-assert from the pin throughout the SOC. in other words there is no any SW involvement along the way, meaning the boot may, in fact. fail for some reason (e.g. boot memory or i/f malfunction)  but the MCU_ERROR will still go high following reset being de-asserted. Is this correct understanding? 

    thanks

    Michael

  • Hi Michael, 

    yes, the ESM module will by default drive MCU_ERRORn signal high after reset.  This is its default state.  There is no software involvement for this functionality.  If the ROM fails for some reason, the MCU_ERRORn signal will remain unchanged, since the ESM module has not been initialized yet.  The ESM module has to be setup with appropriate event inputs as triggers for the errors.  So a bootloader could set this up, and then trigger an interrupt that would be sent to the ESM as an error event, for example

    Regards,

    James

  • Hi James,

    In principle, customer needs some sort of indication of ROM failure, doesn't have to be MCU_ERRORn. Referring back to TRM's Figure 5-3, is there any way to know that the M4 WD timer has expired when it goes to Retry? 

    thank you,

    Michael

  • Michael, when that watchdog timer expires, it should trigger a warm reset which should be evident on the RESETSTATz output signal.

    Regards,

    James