• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 29 subscribers
  • Views 340 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.

Original question:

TMS570LS0432: STC Test and Self-Test configurations

TMS570LS0432: Multiple MCU configuration due to the STC CPU reset

Dmitry Tuykov
Expert 1221 points
Part Number: TMS570LS0432
Other Parts Discussed in Thread: HALCOGEN

Hi TI team,

could you be so kind to support me with the questions regarding CPU reset after STC test run and MCU configuration?

In our project we have several SW packages like Boot Code, Application and Loader. And now we have to decide where to place STC test call and reset-cause-handler.

Initial idea was to keep it as part of the application, on the other hand all PLL, clock domains etc. configurations are done within the Boot Code.

With the mentioned approach Boot Code is going to be executed completely several times due to the STC (CPU reset).

So here is the questions: is it critical to perform PLL, clock domains, Flash etc. configurations two or more times with CPU reset between them? Can we expect some side effects in such a case?

P.S. For system configuration we use the function which is very close to the HALCoGEN systemInit function.

Thanks in advance

  • 0
    TI__Mastermind 49120 points

    Hi,

    A reset caused by execution of STC only resets the CPU, and not the rest of the part. The code executed after an STC reset only needs to re-initialize the CPU. All other settings such as PLL, clock domain mappings, etc. do not need to be repeated.

  • 0 in reply to Sunil Oak
    Expert 1221 points

    Hi,

    thanks for the answer, I understand that formally it is not necessary.

    But the main question is a bit different: if for any reason we have to initialize the system (clocks, PLL, flash, etc.) second time, could we expect some unexpected issues, some problems? Or is it absolutely OK to call systemInit twice or even more times in a row?

  • 0 in reply to Dmitry Tuykov
    TI__Mastermind 49120 points

    Hi,

    It depends on what you are configuring in the systemInit function. For example, this function, as generated by HALCoGen, disables the PLL first, then sets up the PLL configuration, and then enables the PLL. This would affect all clock domains that are sourced by the PLL. It would be necessary to move all clock domains sourced by the PLL to the main oscillator before re-configuring the PLL.

    The correct function to disable the PLL is included in the errata_SSWF021_45.c file generated by HALCoGen. The systemInit() function assumes that the PLL is not already up and running when it is called.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Expert 1221 points

    Hi Sunil,

    thank for the answer.

    We configure all the same like in HALCoGen.

    Just one last question before we close this topic. For the first look, do you see any other functionality which I should pay attention except PLL and clock domains correct reconfiguration? Maybe turning off peripherals...something else...

  • 0 in reply to Dmitry Tuykov
    TI__Mastermind 49120 points

    Hi Dmitry,

    There could be other undesired effects as well. You will have to go through each step in sequence to identify how it will affect your system.

    For example, the periphInit() function first resets each peripheral and then releases this peripheral reset. Every single peripheral will get reset by calling this periphInit() function. This includes all communication interfaces (CAN, LIN, SCI, etc) as well as any control modules (HET, ADC).

  • 0 in reply to Sunil Oak
    Expert 1221 points

    Hi Sunil,

    thanks for the answer, we decided to implement normal 'reset' handler. Easier that make an analysis of side effects.

    Topic could be closed.