When MCU enter APP from bootloader for the second time , initialization of clock is abnormal

[LuoSi]

There is a requirement is that keep an IO high level when APP jump to the bootloader, so it is not feasibile to enter Bootloader by software reset.

It is normal for the first time to enter APP from Bootloader.I deinitialize all peripheral such as PIT, SPI before entering bootloader and bootloader will enter APP again. When MCU enter APP from bootloader for the second time, it will stuck at initialzing. I used the library functions offered by IDE. These pictures shows how I find the problem.

1.I find it stuck at here.

2.Then stuck at here in picture 1 function

3.Then stuck at here in picture 2 function

4.Then stuck at here in picture 3 function

5.And finally I found here. It seems that the cycle is waiting a register status until timeout.

6.Then I checked the address of this register, and found out what is the cycle wating for.

But I dont know why this bit stuck at "Mode transition is on going ". Besides, I tried to reduced the TIMEOUT value in picture 5, then the project will stuck at initializing PIT, or SPI, or the others peripheral.

[davidaccess]

When dealing with a requirement to keep an IO high level while transitioning from an application (APP) to a bootloader, it is crucial to manage the peripheral states and initialization sequences carefully. Here are some steps and considerations to address the issue where the MCU gets stuck during the second entry into the APP from the bootloader:

1. Peripheral Deinitialization:

   • Ensure that all peripherals are properly deinitialized before jumping to the bootloader. This includes disabling interrupts and resetting peripheral registers to their default states.

2. Memory and Stack Management:

   • Verify that the stack and heap are correctly managed during the transition. Any stack corruption or improper memory allocation can cause the MCU to get stuck.

3. Bootloader and Application Separation:

   • Make sure that the bootloader and application code are well separated in memory and that the vector table is correctly set up when transitioning between them.

4. Hardware Initialization:

   • During the second entry into the APP, ensure that all hardware components are re-initialized correctly. Sometimes peripherals may require a complete reset to work properly after being used by the bootloader.

5. Debugging:

   • Use debugging tools to step through the code and identify where the initialization process gets stuck. Implement a functional Hard Fault Handler to catch any faults and provide more information about the failure.

6. Library Functions:

   • If you are using library functions provided by the IDE, ensure they are compatible with your bootloader and application setup. Sometimes, custom initialization routines may be necessary.

For more detailed troubleshooting, you can refer to community discussions on similar issues. For example, a user on the NXP community faced a similar problem where the MCU got stuck during initialization when entering the APP from the bootloader for the second time (source).

By carefully managing peripheral states, memory, and initialization sequences, you can ensure a smooth transition between the bootloader and application, even with the requirement to keep an IO high level.

[petervlna]

Hello,

You mode transition is stuck because you have active some periphery which is supplied by PLL.

Try to do mode transition to IRC clock and then to your application settings.

Make sure all peripherals are not clocked by you application clock when you request mode transition.

Best regards,

Peter

[LuoSi]

Hi

I've tried as you said.I reset MC_RUN_PC_n, MC_LP_PC_n and ME_PCTL_n before requesting mode transition but  mode transition is still stuck.

A register called MC_ME_DMTS as the picture below can see what state is currently. The value is the picture below when the stuck happen. But it is not clear to me that how to find the cause of stuck. Could you help me analyze it?

[petervlna · Accepted solution]

Hello,

OK, so I expect you still have some peripheral active which is sourcing the clock like CAN or PWM.

Gate clocks to those, usually the peripherals have in control register freeze bit so similar.

Best regards,

Peter