FreeRTOS osKernelStart returns osErrorISR when debugged with ST-Link

[rengl]

We created the project for the M4 with CubeMX. We use FreeRTOS with CMSIS_V2 and OpenAMP as Middleware.

We assigned TIM1, TIM2 and TIM3 to the M4 and use TIM1 as SYS Timebase Source.

The program runs fine if started with fw_cortex_m4.sh or with the SW4STM32 menu "Run As".

But if we try to debug with "Debug As", osKernelStart returns osErrorISR in both Engineering and Production mode.

But osKernelStart is in the main function. Also if we create a Mutex it returns NULL. Both functions "fail" on IS_IRQ.

This is a very similar question. From there i used the code to read the IPSR, it is already 41 at the beginning of the main function.

If i don't initialize TIM1 so that no interrupts from TIM1 can occur IPSR is 14 at the start of main.

If i apply the "patch" from this question IPSR is 0 but the creation of RPMsg channels with VIRT_UART_Init fails with:

[ 3044.562749] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty-channel addr 0x0
[ 3044.568797] virtio_rpmsg_bus virtio0: channel rpmsg-tty-channel:ffffffff:0 already exist
[ 3044.576934] virtio_rpmsg_bus virtio0: rpmsg_create_channel failed

Is there a problem with the ISR handling while debugging, so that IPSR is not cleared in main?

Does the "patch" in the second link goes in the right direction or do we have a other problem here?

[OlivierK · Accepted solution]

​Hello rengl,

Indeed the problem you are refering to is linked to This post. Please try to apply the patches and reload the image a second time,

The ISR issues should be fixed using the patches. This should works as a workaround. The root cause of this issue is currently investigated.

Best Regards,

Olivier

[EDOwl]

Hi @OlivierK​ 

Is there any update on this?

Best regards

Eoin

[OlivierK]

Hello EDOwl,

Yes, the issue has been solved and verified in CubeIDE v1.2.0

Best Regards,

Olivier

[LHabe.1]

Has this issue been resolved? I started having this issue for the first time in my project. I logged out one day, logged back in (no code changes), and now both the bootloader and application code sections show an ipsr of 32 at the beginning of main when running ST-Link debugger. This could not be program code related as the code has been stable. Is there a debugger patch update? I am running STM 1.7 with the latest ST-Link version via GDB server. Thank you

[Javier1]

@OlivierK​ i also am having this issue right now with a

cubeMX 6.6.1

STM32Cube FW_F1 V1.8.4

cubeIDE 1.8.0

FReeRTOS v2 10.0.1

CMSIS-RTOS 2.00

running the debugger in a stm32f105RBt6

• If i run the code without startng the debugg sesion there is no problem (same debug configuration)
• once i try to start the debugg session and i place my breakpoints i get 0x0 in the handlers of every task/queue/semaphore and then osKernelStart() exits with a osErrorISR

 

osKernelInitialize() runs okay, returns status osOK because

__STATIC_FORCEINLINE uint32_t __get_IPSR(void)
{
  uint32_t result;
 
  __ASM volatile ("MRS %0, ipsr" : "=r" (result) );
  return(result);
}

__get_IPSR returns 0;

[Javier1]

BUT when __get_IPSR is called after oskernelInitialice() it returns a number 32.

Indicating the system is inside an interruption

Edit: after 14 times launching the debugger and changing breakpoints from place to place it suddenly works.. (no code was changed)

[LHabe.1]

I tried several things and eventually something worked but I'm not sure what the combination​ was. Try putting __enable_irq() right after

SystemClock_Config();

The reason I did this was my bootloader disables interrupts before it jumps and so main seemed to act like it thought it was an ISR. ​__enable_irq seemed to fix it. Not sure why this issue sprang up randomly but I haven't seen it come up since.

Let me know if that doesn't help and I'll see what else I did. ​