• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 83 subscribers
  • Views 201 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: LPOST and MPOST behavior

Francois Charlot
Mastermind 29922 points

Part Number: F29H859TU-Q1

Hello,

Could you please help clarifying the below points?

Figure 2-1 Device Reset Diagram in the device TRM revision A page 86 seems to imply that internally, PORESETn will keep the HSM and the CPU cores in reset if LPOST fails. Is that so?  The diagrams in section 3.5.1 Device Boot Flow show otherwise. How should LPOST in the way of PORESETn be interpreted in fig. 2-1? Assuming LPOST fails, what is the SoC expected to do? If the HSM or CPU1 are supposed to handle an LPOST failure, how about an LPOST failure that's actually due to an HSM or CPU1 logic failure?

The LPOST status bits do not seem to be documented in the TRM. One has to look for their definition in the SDK (source\bitfields\hwbf_lpost.h). I could not spot the address of this register either: the SDK file source\driverlib\inc\hw_lpost.h lists the LPOST register offsets, but the base address of the LPOST registers block is nowhere to be found—SDK, datasheet or TRM. Are the LPOST registers fully defined in a document, and what are their base address?

TRM section  3.7.11 BootROM Timing lists some timings for the execution of LPOST and MPOST, but without specifying the LPOST coverage nor specifying the PLL setting. Could you please provide the run-time for the different LPOST coverages and tell the PLL setting used in the table? Also, assuming one would want to run LPOST/MPOST using the PLL, why one would select a PLL frequency other than the highest one possible so to shorten the execution time of the tests?

We have similar questions for MPOST: where are the MPOST status registers located and described? And how is one supposed to handle an MPOST failure?

Thank you.


Best regards,
François.

  • 0
    TI__Mastermind 18176 points

    Hi,

    When LPOST run completes it triggers PORESETn and irrespective of the results still boots up, it is upto application to check the LPOST and MPOST results in registers at boot up and take action that suites best to the application safety goal's.

    LPOST and MPOST registers will be included in next revision of the Safety manual. For now refer you can refer to the driverlib offset and definittions from hw_lpost.h and hw_pbist.h(another name for mpost) and base addr below.

    #define LPOST_BASE                  (0x301F8000U)
    #define MPOST_BASE                 (0x301F9000U)

    Francois Charlot said:
    Could you please provide the run-time for the different LPOST coverages and tell the PLL setting used in the table? Also, assuming one would want to run LPOST/MPOST using the PLL, why one would select a PLL frequency other than the highest one possible so to shorten the execution time of the tests?

    We dont have timings for different configs, these timings are for clock running at Max speed - 200Mhz PLLCLK C29 side and HSM at 100 Mhz. Yes users dont need to run at slower clocks/speed these are just options enabled for bootrom for future scalability. 

    Thanks

  • 0 in reply to Prarthan Bhatt
    TI__Mastermind 29922 points

    Hi Prarthan,

    Thank you. At least, could we tell if the LPOST timing in TRM section 3.7.11 corresponding to the highest logic coverage?


    Best regards,
    François.

  • +1 in reply to Francois Charlot
    TI__Mastermind 18176 points

    Yes, the timing numbers are for highest coverage >90% coverage and highest clock frequency 

    Thanks

  • 0 in reply to Prarthan Bhatt
    TI__Mastermind 29922 points

    Thank you, Prarthan. I will close this case but would appreciate that you gather some figures for the lower coverages so that we could communicate them later on to customers.


    Best regards,
    François.