Differences between "software reset" and "hardware reset" on MC56F81xxx?

[JPE]

Hi NXP,

as mentioned in another post earlier, we're in the process of migrating some existing code from the MC56F82748 to the new(er) MC56F81748.

Part of the functionality is a bootloader for allowing firmware update in the field.
(We have written our own bootloader and are NOT using the built in bootloader of the MC56F81xxx!)

The device always starts up with the bootloader on power up and the bootloader then jumps to the application area, if it detects a valid application.

For reprogramming the device we have to jump back from the application to the bootloader, which has been implemented as a jump command so far.

On the new MC56F81748 we now see a strange behaviour after jumping back to the bootloader, where the interrupts (PIT and SCI) don't seem to get enabled, since the according interrupt handlers are not executed.

This is both the case when going back to the bootloader with the jump instruction, but also when using the software reset command (bit 4 in the SIM_CTRL register).
The DSC only starts up the bootloader and I can see that the main loop is running, but the interrupts are not triggered.

After power-up or when triggering a hardware reset via the RESET input of the DSC, the bootloader code is working as expected and the interrupts are triggered correctly.

According the the reference manual for the MC56F81xxx there should be no difference between a software reset via the SIM_CTRL register and a hardware register, but we definitely observe a difference here.
How can that difference be explained?

Of course, the application executes another code, enables other interrupts and uses another part of the memory, but if the bootloader shoudl start up in the same way after a software and a hardware reset, the application code should be totally irrelevant.

Thanks in advance for your help on this.

@xiangjun_rong

[JPE · Accepted solution]

Hello again, Sutter Zhou,

your hint about the SIM-registers guided me in the right direction to find the "needle in the haystack".
There were actually some SIM-registers (double clock for PIT and SCI), that were written to by the application code and not properly re-initialized by the bootloader after a SW-reset.

Properly setting these registers by the bootlaoder fixed the issue.

[JPE]

Hi Sutter Zhou,

thanks for the reply and the explanation.

So a hardware reset via the reset pin and a SW reset command should definitely restart the DSC in the same state?
Only a power-on reset differs regarding the SIM-registers?
However, according to the RM, these registers don't seem to be relevant for the operation of the DSC, so they still shouldn't make any difference?

Regarding the development template, we try to keep the code base as close as possible to the existing SW for the MC56F82748, so it will be easier to maintain the SW for both variants in the future.
The existing code for the MC56F82748 is based on the QuickStart template and using GCT and appconfig.h for the configuration.
Therefore, we have "only" adapted the "arch.h"- and "appconfig.h"-files and made the necessary changes to the modified modules (like DMA and XBAR / EVTG).
As the MC56F81xxx-series in unknown to GCT, we have defined the CPU as "MC56F83763" in the "appconfig.h", since we are already using that DSC in another design and most registers are identical.

However, we have identified a major difference between the MC56F83763 and the MC56F81748, where the "XBARA input"-values to be put in the XBAR_SELxx-registers (Table 15-2 in the RM) are different.
And I just noticed, that the SIM_MISC0 looks different as well.

So with our somewhat unorthodox development template in mind, could there be any relevant settings our application code overwrites after leaving the bootloader and which not re-initialized properly by the bootloader, unless the DSC gets a hardware reset or POR?

BR. Joern

[sutter_zhou]

Hi,

Actually your understanding about resets on DSC is not wrong, there's no big differences among various kinds of resets, interrupt modules should be definitely reset by any kind of reset. Here are some differences that I can tell among the resets:

1. Power On reset (POR): it will reset the chip completely because the chip goes from power-off to power-on. Registers SIM_SCR0~SIM_SCR7 are only reset by POR. 

2. Other resets have the same impact. However, fast/normal mode transition takes effect only after a SW reset. 

I'm not sure which development template you are working on, the one with MCUXpresso config tool, or the one without it?  There's a way to bypass ROM during the startup, which can be easily implemented through the tool. 

Regarding PIT, please check an erratum for the this chip, PIT is used in ROM, but not reset after ROM execution.

There should be no big issue migrating a bootloader from 82xxx to 81xxx. I think there are some details that I'm not aware of, please contact me directly so I can provide support.