IMXRT1052 : PortStartFirstTask() crashes when application starts in internal RAM after being copied from external FLASH

clemz wrote on Wednesday, July 18, 2018:

Hello,
I am using :
MIMXRT1050-EVK (IMXRT1052 - ARM7)
FreeRtosv10.0.1
My application run successfully under FreeRtos on QSPIFlash in XIP(execute in place) mode.
When my application run on internal RAM after being copied from QSPIFlash, the RTOS scheduler crashes when attempting to start the first task.
I can read on FAQHelp.html :"If you are using an ARM7 target then the processor must be in Supervisor mode when the RTOS scheduler is started. "
How can I set the processor in Supervisor Mode?
Can someone help me to find a solution to this problem?
regards

rtel wrote on Wednesday, July 18, 2018:

The CPU mode when main() is called is set by the start up code. If your
code works when executed from Flash then it must have been in Supervisor
mode when main() was called - and if you have not changed the start up
code then you are probably also in Supervisor mode when you run from
RAM. You can check this by viewing the register details in the debugger.

If the above is the case then the issue is much more likely to be caused
by how you are copying to RAM. For example, if when running from Flash
the vector table is in Flash, when you copy to RAM I assume you also
copy the vector table to RAM, and if so, you will have to update the
vector base address so it is pointing to wherever you copied the vector
table.

clemz wrote on Wednesday, July 18, 2018:

Hi Richard,
tks for the reply,
The app works fine in Debug mode(it runs in internal RAM(0x2000-without problems). What i really do is compiling my application, download it in QSPIFlash with MFGTool. When IMXRT boot start executing(not my app) it finds that image in QSPIFlash is not ‘XIP style’ so it copies it in RAM and start execution in RAM. So I can’t check if the processor is in Supervisor mode ;(.
In this case(not Debug), the application run without problems(PRINTF works fine) until I start FreeRtos…

rtel wrote on Wednesday, July 18, 2018:

If this is an ARM7 which I think your original post said it was (as
opposed to a Cortex-M) then normally the most likely is the vector table
is in the wrong place, not populated, or you were in the wrong CPU mode.

If debug works but release doesn’t it would seem unlikely that it was a
vector table location or population issue, assuming nothing changes
other than the compiler optimisation level (actually, that might not be
true, thinking as I’m timing, turning the optimisation level up could
cause functions the compiler thinks are not called to be removed, can
the compiler see the interrupts that are installed or does the
bootloader install them?).

To see the CPU mode you would have to look at the start up code.
Somewhere there will be a sequence that switches to a mode, sets up the
stack for the mode, switches to the next mode, sets up the stack for
that, etc. In that sequence, you want the mode you end up in to be
Supervisor mode. Have a look and see if there are any differences in
that sequence that are dependent on the optimisation level, or a
pre-processor macro such as ‘DEBUG’ or ‘RELEASE’.

richard_damon wrote on Wednesday, July 18, 2018:

One question, is your printf using semi-hosting? Semi-hosting only works through the debugger, so doesn’t work in release mode if you don’t run the release mode through the debugger,

rtel wrote on Wednesday, July 18, 2018:

Ah - good call.

clemz wrote on Thursday, July 19, 2018:

Hello Richard,
I could’nt respond ealrier sorry.
I will define what I call ‘debug’ and ‘release’ mode :
debug : use of jlink under IAR IDE 8.22.2
release : download myapp.sb file (via myapp.out file) with use of MFGTool
Important : no changements of configuration(e.g. same .icf file,no preprocessor symboles are
changed,…) are made between two modes, in other words this is the same project.
In debug mode everything works fine : printf(), xTaskCreate(), vTaskStartScheduler(),…
In release mode printf(), GETCHAR() or PUTCHAR() work fine : it help me to find that my app works until vPortStartFirstTask()( for example, xTaskCreate() return ‘pdPASS’). This means that vector table location or population is good, don’t you think?
The startup file is the same between two modes as i explained earlier and i didn’t make any change on it (same as default one see startup_MIMXRT1052.s in attachement).

clemz wrote on Thursday, July 19, 2018:

So you know, IMXRT1052 is a Cortex-M7

rtel wrote on Thursday, July 19, 2018:

In release mode printf(), GETCHAR() or PUTCHAR() work fine : it help me
to find that my app works until vPortStartFirstTask()( for example,
xTaskCreate() return ‘pdPASS’). This means that vector table location or

The vector table is probably not used until you try and start the scheduler.

clemz wrote on Thursday, July 19, 2018:

GETCHAR() or PUTCHAR() for example use vector table :

__vector_table_0x1c
....
LPUART1_IRQHandler 
...

and they are called before the start of scheduler ;(