[ARM FastModel][RT-ARMCM4-GENERIC]CPU gets into infinite loop after RESET

[sdiwakar]

I am trying to bring RT-ARMCM4-GENERIC demo on FVP_MPS2_Cortex-M33 Fastmodel from ARM. The code is compiled with "GNU Tools ARM Embedded\6 2017-q1-update"
My idea is to bring-up the OS on the fastmodel but, with the M33 security extensions disabled to start with.(i.e, in v7m mode).

The system model is configured with cpu0.INITNSVTOR=0x10000000. Accordingly i set the CORTEX_VTOR_INIT in os/rt/ports/ARMCMX/chcore_v7m.h

#if !defined(CORTEX_VTOR_INIT) || defined(__DOXYGEN__)
#define CORTEX_VTOR_INIT 0x10000000U
#endif

When the core is released from RESET, it gets into an infinite loop(sample snippet below) starting from 100001c0.
As per disassembly, the code at 100001c0 should have been the "Reset_Handler".

I have attached the files as zip(chibicm4.zip) to this thread.

Would like to get your valuable inputs on this failure.

Simulation is started
0 clk cpu0 E 100001c0 00000001 CoreEvent_RESET
0 clk cpu0 R r13_main 00000000
0 clk cpu0 R cpsr 01000000
0 clk cpu0 R MSP 00000000
0 clk cpu0 R NVIC_ISPR1 00400000
0 clk cpu0 R NVIC_ICPR1 00400000
0 clk cpu0 R ICSR 00400000
0 clk cpu0 R FPDSCR 00000000
1 clk cpu0 IT (1) 100001c0 0000 T thread : MOVS r0,r0
1 clk cpu0 R r0 00000000
1 clk cpu0 R cpsr 41000000
2 clk cpu0 IT (2) 100001c2 0000 T thread : MOVS r0,r0
.....
.....
.....

[sdiwakar]

Hi,

I made further progress by running the OS in Secure world of the CPU. Now the waThread1 is created and starts running.
However, i am seeing stack corruption during __port_switch.
There are 3 instances of __port_switch in the log ( refer tarmac.log in zip) .

However, the last one causes r13_process_s to be set to NULL.

It would be great if anyof you have some pointers for me to debug this further. I do have CH_DBG_* set in chconf.h but, none of them are fired.

I have attached the map, cpu instr execution dump ( tarmac ) and other relevant files from the build.

Line 12689: 5301 clk cpu0 IT (5301) 10000290 e92d4ff0 T thread_s : PUSH {r4-r11,lr}
Line 13236: 5502 clk cpu0 IT (5502) 10000290 e92d4ff0 T thread_s : PUSH {r4-r11,lr}
Line 13777: 5704 clk cpu0 IT (5704) 10000290 e92d4ff0 T thread_s : PUSH {r4-r11,lr}

5704 clk cpu0 MW4 30000794 30000800
5704 clk cpu0 MW4 30000798 ffffffff
5704 clk cpu0 MW4 3000079c 30000d0c
5704 clk cpu0 MW4 300007a0 00000020
5704 clk cpu0 MW4 300007a4 00000002
5704 clk cpu0 MW4 300007a8 00000000
5704 clk cpu0 MW4 300007ac 00000000
5704 clk cpu0 MW4 300007b0 00000000
5704 clk cpu0 MW4 300007b4 1000076b
5704 clk cpu0 R r13_process_s 30000794
5704 clk cpu0 R PSP_S 30000794
5705 clk cpu0 IT (5705) 10000294 f8c1d00c T thread_s : STR sp,[r1,#0xc]
5705 clk cpu0 MW4 30000c4c 30000794
5706 clk cpu0 IT (5706) 10000298 68c3 T thread_s : LDR r3,[r0,#0xc]
5706 clk cpu0 MR4 3000080c 00000000
5706 clk cpu0 R r3 00000000
5707 clk cpu0 IT (5707) 1000029a 469d T thread_s : MOV sp,r3
5707 clk cpu0 R r13_process_s 00000000
5707 clk cpu0 R PSP_S 00000000
5708 clk cpu0 IT (5708) 1000029c e8bd8ff0 T thread_s : POP {r4-r11,pc}
5708 clk cpu0 MR4 00000000 (ABORTED)

[Giovanni]

Hi,

Are you using the startup files provided by ChibiOS?

Giovanni

[sdiwakar]

Hi Giovanni,

Yes, i used the same startup file as used by RT-ARMCM4-GENERIC demo.

demos\various\RT-ARMCM4-GENERIC\Makefile
-> $(CHIBIOS)/os/common/ports/ARMCMx/compilers/GCC/mk/startup_stm32f4xx.mk

1) I did change the linker script to suit the fastmodel target ( changed the org of flash & ram) .

LInker script : LDSCRIPT= $(STARTUPLD)/STM32F407xG.ld

flash : org = 0x10000000, len = 1M
ram0 : org = 0x30000000, len = 288k /* SRAM1 + SRAM2 */

2) changed the VTOR
#if !defined(CORTEX_VTOR_INIT) || defined(__DOXYGEN__)
#define CORTEX_VTOR_INIT 0x10000000U
#endif

3) Enabled the various CH_DBG_* options in demos\various\RT-ARMCM4-GENERIC\chconf.h and
#define CH_CFG_NO_IDLE_THREAD TRUE // Set this to remain in the main loop.

I also tried setting large values to the process and main stack sizes but, i hit the same problem.

[sdiwakar]

Hi Giovanni,

Above issue is still valid ( unhandled_exception if main loop instead of Idle_task).

However, when i enable Idle task instead of main loop ( CH_CFG_NO_IDLE_THREAD is FALSE) , i can now see that we enter Idle task and periodically the Systick kicks in.
I have attached the tarmac log for this. it would be good to know if you think it is now working as expected.

[Giovanni]

I don't know the details of the architecture, you should verify if there are differences in exception handling compared to v7m. Are those stack boundary registers enabled by default?

Giovanni