RT1176 ROM code does not set stack pointer correctly

[udoeb]

I found out (the hard way) that RT1176 ROM code when starting my firmware image (via reset vector) does not set the stack pointer register (MSP) to the value defined by my vector table. Instead it sets MSP to 0x20241da0.

According to ARM's specification on how an Cortex-M CPU boots, MSP should be initialized with the value VECT[0]. Hence I would consider this to be a bug in the ROM code. I cannot find a related record in the errata sheet.

In the RT1170 sample code one can find this statement at the beginning of ResetISR:

__asm volatile ("MSR MSP, %0" : : "r" (&_vStackTop) : );

which fixes the issue. But there is no comment nor other hint that this is a workaround for a ROM code bug.

My code failed because it was ported over from RT10xx and did not have this workaround in place.

Is this a known issue in RT1170 ROM code? Is this going to be fixed in future revisions?

[kerryzhou]

Hi @udoeb ,

  Happy New Year!

  Thanks to @carstengroen reply, you are totally correct!

  When the MCUXrpesso startup didn't reset the SP, and the IVT entry is the reset handler, the BootROM jump to the APP will still use the BootROM's stack, from the RM system boot chapter, BootROM stack is put in the OCRAM, then, if the app code also put the RW,ZI section into that OCRAM, then when the App run and use the stack, it may cause the App RW, ZI data break issues, then the app may run into the abnormal.

So, normally, we will do :

reset SP
systemInit()
data/bss/ramfunc initialize
Jump to main

In fact, in the old SDK MCUXpresso IDE project, we didn't add this reset SP code, so I also meet one issue when testing the RT10XX dev_cdc_vcom_freertos demo, when using the IVT as the reset handler address, then the code runs abnormal, at last, we find we need to reset the SP to solve this issues, so in the new SDK MCUXPresso IDE project, we add it.

Wish it helps you!

Best Regards,

kerry

[udoeb]

It's interesting to know that you were affected by this issue as well. As I said, ROM code behavior should be better documented. I suggest NXP publishes the sources of the ROM code or at least relevant parts of it. This would be the best documentation you can get.

Udo

[kerryzhou]

Hi @udoeb ,

  ROM code is not published to the customer, to be honest, even I, also don't have that code, so, you can see that code confidential level!

   In fact, to us, we just need to use it, you just need to reset the SP, then everything will go well!

Best Regards,

Kerry

[carstengroen]

Udo,

I don't think you are being totally fair.

As I wrote previously, in section 10.3.5 in the reference manual it is clearly written what the boot ROM does. If you had read that, you would not have been in doubt if you needed to set the MSP or not.

[kerryzhou]

Hi @udoeb 

   In fact, it is not the ROM issue, it is just the feature.

  So, after you jump, you can reset the SP in the MCUXPresso IDE:

    /* 新增SP重设代码 */
    __asm volatile ("MSR msp, %0" : : "r" (&_vStackTop) : );
    __asm volatile ("MSR psp, %0" : : "r" (&_vStackTop) : );

 More details, our AE write it in the chinese formula, not the English, maybe you can translate it and check it:

https://www.cnblogs.com/henjay724/p/13652875.html

Wish it helps you!

Best Regards,

Kerry

[udoeb]

Hi Kerry,

Thanks for your reply. I don't understand Chinese so please post comments in English.

I do not consider this a feature. It's non-compliant behavior. The Arm documentation clearly specifies that on reset the Cortex M7 CPU loads the stack pointer (MSP) from index 0 in the vector table. See also the Cortex M7 user guide, section 2.3.4 Vector table:
https://documentation-service.arm.com/static/5ea95fba9931941038df3bbe?token=

The RT1176 does not behave this way. This should be documented in the reference manual, the errata document, or elsewhere.

Best regards,
Udo

[carstengroen]

Technically, it is the (NXP) ROM that starts your code and "not the CPU as part of its reset sequence". In this case, NXP requires you to set the MSP when the ROM starts your code (which can be placed many different places according to the BOOT configuration etc.)
In the same way the ROM also sets a lot of other things, QSPI, SDRAM etc, these are also not part of the "Cortex M7 user guide".

[udoeb]

Of course it's the ROM code which emulates the reset. But it does it in a way that's different than specified by ARM. This should be documented somewhere. Specifically because behavior seems to be different in RT10xx and RT11xx. When existing code is ported from RT10 to RT11 (as in my case) this behavior is a pitfall and cost me hours of debugging.

Where is the CPU startup implemented by ROM code documented?

Udo

[carstengroen]

It says that it "Loads and jumps to an address derived from the program image" for (as an example) the internal boot mode. It does not say that it load the MSP for you etc...
If stuff crashes during boot, it is always a good idea to check MSP/PSP as well as stack sizes, we have all been bitten by that