LPC54016 setuping FreeRTOS, Stuck at SVC 0

[TomaszTheSnail]

Hello everyone,

I’m having trouble setting up FreeRTOS on the LPC54016. I copied the LPC540S18 SDK example freertos_hello, then changed the MCU and memory layout to match the LPC54016. The project works without FreeRTOS. After enabling FreeRTOS, it gets stuck in xPortStartScheduler() at SVC 0 and never reaches SVC_Handler. Sometimes it ends up in HardFault_Handler.

Here’s what I’ve checked and tried so far:

• Disassembled SVC_Handler — it resolves to vPortSVCHandler.

• The address in the interrupt vector table matches the address of SVC_Handler.

• I can’t access VTOR from GDB.

MCUXpresso IDE project:
https://github.com/kacpereqo/LPC54016-RTOS

[Harry_Zhang]

Hi @TomaszTheSnail 

If you want to use the LPC54016, you can download the LPC54016 SDK directly.

And then create a lpc54016 freertos demo.

 

BR

Harry

[TomaszTheSnail]

Hi  ,

Thanks for the response. I have the SDK downloaded manually, every setting is default and I am using the FreeRTOS kernel files from it, but I am running into a specific runtime issue during the scheduler startup.

(gdb) x/i $pc
=> 0xa3a <prvPortStartFirstTask+30>: svc 0
(gdb) bt
#0 0x00000a3a in prvPortStartFirstTask ()
at ../freertos/freertos-kernel/portable/GCC/ARM_CM4F/port.c:285
#1 0x00000be0 in xPortStartScheduler ()
at ../freertos/freertos-kernel/portable/GCC/ARM_CM4F/port.c:452
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

As shown in the GDB trace above, the application halts at prvPortStartFirstTask on the svc 0 instruction

[Harry_Zhang]

Hi @TomaszTheSnail 

Can you share your project so that i can try it?

BR

Harry

[TomaszTheSnail]

Hi @Harry_Zhang, 

There is compressed MCUXEspresso project

[Harry_Zhang]

Hi @TomaszTheSnail 

I just tested it on my end.

It can work.

I added some code to output content in my serial port.

 

BR

Harry

[TomaszTheSnail]

HI @Harry_Zhang,

If you said that the same configuration works for you but not for me, the only thing we might be doing differently is the debugging interface. I’m debugging via LinkServer and GDB hardware debugging—could the issue be there?

[Harry_Zhang]

Hi @TomaszTheSnail 

Yes, I think there may be an issue with your debugger.

You can create a bare metal project and see if it can be debugged properly.

If debugging is also not possible, it proves that there is a problem with the debugger.

BR

Harry

[TomaszTheSnail]

Hi @Harry_Zhang,

I tried it locally, and it resulted in a successful run of FreeRTOS. However, another weird issue occurred — the handler below crashed and went to HardFault_Handler. I resolved it by commenting out CTIMER0_DriverIRQHandler():

WEAK void CTIMER0_IRQHandler(void) { 
CTIMER0_DriverIRQHandler();
}

But I have one question: why does debugging locally with the same setup not work the same way as LinkServer?

My setup:

Probe: MCU-LINK (r0FB) CMSIS-DAP V3.165

Linkserver Launch commands : LinkServer gdbserver LPC54016 --allow-remote --keep-alive

MCU: LPC54016JBD100

[Harry_Zhang]

Hi @TomaszTheSnail 

I think although you are using the same probe (MCU-LINK CMSIS-DAP), the initialization script for the GDB server is different. The CPU startup status may be completely different.

BR

Harry

[TomaszTheSnail]

Hi @Harry_Zhang,

I couldn’t find any differences in the configuration between C/C++ (NXP Semiconductors) MCU Application > LinkServer Debug and LinkServer + GDB.

I would appreciate it if you could try this setup on your side to help determine whether the issue is specific to my environment.

[TomaszTheSnail · Accepted solution]

Hi,

I've resolved the stuck SVC 0 error and hard faults. I also found out why local debugging via USB in MCUXpresso works, while the same setup through LinkServer does not.

The local configuration performs a hard reset every time the firmware is uploaded. I couldn’t find a way to do the same with LinkServer, so before each flash, I power-cycle the PSU via LXI.

I also found and fixed another strange issue. This project is also ported to CLion, where I use a .gdbinit file for flashing the firmware. Initially, I used the load command, but it didn’t work as expected — the firmware was flashed, but execution would get stuck in unusual places.

When using LinkServer, I had to manually stop execution, run load, and then continue from the GDB console for it to work properly. So I tried OpenOCD instead, and it worked as expected — the load command in .gdbinit worked correctly without any extra steps.