• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 84 subscribers
  • Views 327 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.

F29H859TU-Q1: TRM: confirmation about CPU1 Boot Error Status stored in M0 RAM

Francois Charlot
Mastermind 30012 points

Part Number: F29H859TU-Q1

Hello,

Could you please confirm that the CPU1 Boot Error Status stored in M0 RAM (table 3-38 in the TRM revA) is only updated in case of a High Priority Watchdog timeout triggered by ESM CPU1 as described in TRM section 6.5, and by no other event?


Best regards,
François.

  • 0
    TI__Mastermind 19026 points

    Hi,

    Table 3-38. CPU1 Boot Error Status Address, BootROM Error Status Information is stored when the application code doesn't have NMI ISR vector programmed in which case the CPU execution jumps to default NMI ISR in bootrom and clears and saves the corresponding info to M0 ram which can be accessed by application later.

    Thanks

  • 0 in reply to Prarthan Bhatt
    TI__Mastermind 30012 points

    Hi Prarthan,

    Thank you. Could you please confirm that this is the only scenario in which the CPU1 Boot Error Status stored in M0 RAM?


    Best regards,
    François.

  • 0 in reply to Prarthan Bhatt
    TI__Mastermind 30012 points

    Thank you, Prarthan.

  • 0
    Prodigy 210 points

    Hello Mr Bhatt,

    I am Ronan Danioux, BSW developer for Valeo. We are currently evaluating the F29.

    Mr Charlot told me that I can directly send my question here.

    My goal is to know when the area "CPU1 Boot Error Status Address" is written by the firmware.
    If found this in the Technical Reference Manual, chapter 6.5:
    "When the application is not able to clear the error before a NMIWD (High Priority Watchdog) timeout, then a
    reset is triggered from ESMCPU1 instance (refer to Figure 7-4). In this case, BootROM clears errors to avoid a
    back-to-back NMIWD rest loop and stores the error information and status to M0 RAM (refer to Table 3-38) for
    further debug."
    This means that the area is updated if CPU 1 NMI WD timeout occurs

    And you answer was: "When the application code doesn't have NMI ISR vector programmed".
    1/ I suppose this is applicable only to CPU 1
    2/ But I did not find this information in the documentation. Where can I find it ?

    Do you confirm that this area is written only in these 2 cases ?

    Thank you.

    Ronan Danioux

  • +1 in reply to Ronan DANIOUX
    TI__Mastermind 19026 points

    Hi,

    Let me clarify the statement from TRM further more, thanks for reaching out directly.

    Point1 - The ESM and Error Aggregator flags clearing algorithm is located in NMI ISR located in Boot ROM.

    This is the default ISR in case the customer doesn't configure or develop its own NMI ISR, CPU jumps to the default NMI ISR and executes the clearing algorithm so as to avoid the said issues.

    When lets say the application has its own NMI ISR configured but the clearing of the said flags and errors is not done in which case the NMIWD or high priority watchdog counter timeout occurs and triggers XRSn, device resets and boots up again and runs the boot ROM. Since the error flag was not cleared it will cause another NMI at boot up and cause CPU to enter default NMI ISR which is where it will clear the errors and store it in M0 Ram for user to debug and not cause device reset again.

    I hope both cases are understood. Main point to take away is that if application is not able to take care of incoming error event that caused NMI then BootROM default NMI ISR will take care of clearing flags and store it at M0 RAM, that could be because of two cases described above.

    Thanks.

  • 0 in reply to Prarthan Bhatt
    Prodigy 210 points

    Hello,

    That's perfectly clear.

    Thank you

    Ronan Danioux