Pendsv hardfault on a cortex-m0 chip

John_shijj · August 13, 2020, 12:04pm

Hi all，

I‘m using a chip which is cortex-m0. My project has a bootloader, and I use the following code in bootloader to do the interrup remap.

void PendSV_Handler(void)
{
    pFun p;

    p = (pFun)(*(__IO uint32_t*)(ApplicationAddress + 0x38));
    (*p)();
}

void SysTick_Handler(void)
{
    pFun p;
    
    p = (pFun)(*(__IO uint32_t*)(ApplicationAddress + 0x3c));
    (*p)();
}

my project problems are

app can run ok if disable the preemption.
app will run to hardfault if enable the preemption.
app with preemption enable can run ok if the programe without a bootloader.

I checked the pendsv and systick IRQ priority, they are both 3, which is the lowset in my chip. If I commet code *(portNVIC_INT_CTRL) = portNVIC_PENDSVSET; the program also run ok. So I think the hardfault is related to pendSV triggered in systick handler. But I don’t know how to deal with this problem.

void xPortSysTickHandler( void )
{
uint32_t ulPreviousMask;

	ulPreviousMask = portSET_INTERRUPT_MASK_FROM_ISR();
	{
		/* Increment the RTOS tick. */
		if( xTaskIncrementTick() != pdFALSE )
		{
			/* Pend a context switch. */
			*(portNVIC_INT_CTRL) = portNVIC_PENDSVSET;
		}
	}
	portCLEAR_INTERRUPT_MASK_FROM_ISR( ulPreviousMask );
}

Thank you!

John_shijj · August 13, 2020, 12:13pm

https://community.arm.com/developer/ip-products/processors/f/cortex-m-forum/44294/the-code-of-app-is-freertos-the-chip-has-a-bootloader-the-chip-run-on-cortex-m0

https://community.arm.com/developer/ip-products/processors/f/cortex-m-forum/44297/tasks-can-t-switch-to-others-always-run-at-osstarthang-but-whitout-boot-code-the-app-can-run-ok-the-core-of-the-chip-is-cortex-m0

I found these two question are similar with my proble.

rtel · August 13, 2020, 1:33pm

It is not clear how the code you posted is meant to work. I cannot see that it remaps the vector table as you claim, and appears to call the application code from handler mode (that is, from inside an interrupt) so the C startup code of the main application (if that is what the pFun pointer is pointing to) will execute in an interrupt context.

There is too little information to be sure - but from just the code you post there seems to be quite a bit that could be wrong with the way you are exiting the bootloader.

John_shijj · August 13, 2020, 1:42pm

Hi, because I’m using a M0 chip with a bootloader, so when PendSV happened, it goes to PendSV_handler in the bootloader first, and I use this code to call the PendSV_handler in the app to make the remap

jefftenney · August 13, 2020, 2:45pm

Is ApplicationAddress the address of the vector table in your application?

Is 0x38 the offset of the PendSV handler address in the vector table?

Assuming the answers are yes – both deserve a double check – then I think I see what you are doing. First, check to see if your M0 happens to have a configurable vector table base address. If so, that’s the best solution. If not, you should probably write your redirect functions in assembly language and use BX for the branch (not BLX). The code written in C messes up the context expected by FreeRTOS’s PendSV handler.

The chip vendor ought to supply this kind of redirect function. I assume they are forcing this bootloader on you? They should know the trouble they are causing anyone who tries to run an OS, and they should provide the solution. What chip is it?

John_shijj · August 13, 2020, 4:10pm

Is ApplicationAddress the address of the vector table in your application?

Yes

Is 0x38 the offset of the PendSV handler address in the vector table?

Yes

I got this boot code from our supplier. This boot worked well in our project without OS before.The chip is HT6037 kind of a soc for metering.
Maybe I should use a assembly redirect function.

jefftenney · August 13, 2020, 8:25pm

Yes, I think so. If it’s more convenient, you can put your assembly function in a C file, like this:

void PendSV_Handler( void ) __attribute__ (( naked ));
void PendSV_Handler( void )
{
    __asm volatile
    (
    "   ldr  r0, =ApplicationAddress \n"
    "   ldr  r0, [r0, #0x38] \n"
    "   bx   r0 \n"
    );
}

Some of this syntax is unique to gcc, so you might need to modify it for a different compiler.

John_shijj · August 14, 2020, 11:17am

Thank you very much ! I‘m working on it now

John_shijj · August 14, 2020, 1:28pm

Hi, Jeff, your suggestion works!! thank you very much!!
I solve the problem, but the method seems not so good. I modify the PendSV_Handler in startup.s file directly, and the app_addr is fixed at 0x4000.

    PUBWEAK PendSV_Handler
    SECTION .text:CODE:REORDER:NOROOT(1)
PendSV_Handler
    ldr     r0, =0x00004000
    ldr     r0, [r0, #0x38]
    bx      r0
    //B PendSV_Handler

    PUBWEAK SysTick_Handler
    SECTION .text:CODE:REORDER:NOROOT(1)
SysTick_Handler
    B SysTick_Handler

I want to use the same asm code int a C file, but the IAR output an error:
Error[Og006]: Syntax error in inline assembly: “Error[401]: Operand syntax error”
I do not know how do deal with it, do u have some good idea?

__stackless void PendSV_Handler( void )
{
    __asm volatile
    (
    "   ldr r0, =0x00004000             \n"
    "   ldr r0, [r0, #0x38]             \n"
    "   bx  r0                          \n"
    );
}

Thank you!

jefftenney · August 14, 2020, 2:39pm

There’s a section in the IAR C/C++ development guide called “inline assembler” which should help. I noticed it says the shorthand syntax used in the first statement isn’t allowed. Here’s how it looks with the first statement not using shorthand.

__stackless void PendSV_Handler( void )
{
    __asm volatile
    (
    "   ldr r0, appVectors             \n"
    "   ldr r0, [r0, #0x38]            \n"
    "   bx  r0                         \n"
    "appVectors dc32 0x00004000        \n"
    );
}

John_shijj · August 14, 2020, 4:29pm

Refer to IAR C/C++ Development Guide，I found a limitation with inline assembler, “The pseudo-instruction LDR Rd, =expr is not available from inline assembler” . I think that is why the error occured before. So I replace LDR with ADD instruction, and it also works. ApplicationAddress is a macro defined as 0x4000.

__stackless void PendSV_Handler( void )
{
    uint32_t appVectors = ApplicationAddress;
    uint32_t offset = 0x38;

    __asm volatile
    (
    "   add r0,%0,%1                \n" 
    "   ldr r0, [r0]                \n"
    "   bx  r0                      \n"
    :   "+r"(appVectors), "+r"(offset)
    );
}

jefftenney · August 14, 2020, 5:09pm

Letting the C compiler do anything outside of your __asm() statement is a little risky. In this special function, we need the C compiler to use only R0 through R3 so we maintain the state of the interrupted task. The compiler is likely to do that, but probably not guaranteed. May be best just to stick with native assembly.

John_shijj · August 14, 2020, 8:13pm

I think you are right, my program run to hardfault again after runing for about 2 hours. You mean I should not use local variables to store vector and offset, right? I don’t know how to fill R0 with a 32bit value (0x00004000 + 0x38) in IAR inline assembler environment.

jefftenney · August 14, 2020, 8:26pm

Can you post the disassembly of the C function that worked for 2 hours?
What are your concerns about using native assembly? Why do you want to use C?

John_shijj · August 14, 2020, 9:11pm

I modified all handlers like code below.

__stackless void PendSV_Handler( void )
{
    uint32_t appVectors = ApplicationAddress;
    uint32_t offset = 0x38;
    __asm volatile
    (
    "   add r0, %0, %1              \n" 
    "   ldr r0, [r0]                \n"
    "   bx  r0                      \n"
    :   "+r"(appVectors), "+r"(offset)
    );
}

Using native way is to modify the startup.s file like the code below? If so, I can do a test using native assembly.

PUBWEAK PendSV_Handler
SECTION .text:CODE:REORDER:NOROOT(1)
PendSV_Handler
    ldr     r0, =0x00004000
    ldr     r0, [r0, #0x38]
    bx      r0

jefftenney · August 14, 2020, 9:31pm

Yes, #2 is the native assembly way. I would use that.

If you get a hardfault while using the native assembly way, I suspect you have another issue.

John_shijj · August 15, 2020, 3:54pm

I found that hardfault is caused by optimization level. Before optimization level is medium, and program run ok with preemption disable. When I enable preemption, program can only run ok in none optimization level. Anyway I will use the native assembly way to do redirect.

richard-damon · August 15, 2020, 4:49pm

Hard faults cause by optimization are often bugs in the code that get revealed by the optimization. (Proper optimization changes no promised observable behavior).

It can sometimes also cause issues with things like FPU usage, but that shouldn’t be the case here with an M0.

rtel · August 15, 2020, 5:10pm

John_shijj:

__stackless void PendSV_Handler( void )
{
    uint32_t appVectors = ApplicationAddress;
    uint32_t offset = 0x38;
    __asm volatile
    (
    "   add r0, %0, %1              \n" 
    "   ldr r0, [r0]                \n"
    "   bx  r0                      \n"
    :   "+r"(appVectors), "+r"(offset)
    );
}

This is the sort of code that may behave differently depending on the optimisation level. The code appears (not sure) to say the function does not have a stack frame, but then allocates two variables on the (non existent) stack. Some optimisation levels will just use register values rather than a stack and others won’t.

John_shijj · August 17, 2020, 2:40pm

I finally found the bug, it’s related to task priority and Concurrency. My app disabled the preemption before, so such bug will not happen. Once I enable preemption in app, this bug will happen soon or later.
Thank you all!!