Hard Real Time contraints on STM32

[slimbahri]

Posted on April 03, 2010 at 12:48

Hard Real Time contraints on STM32

[picguy2]

Posted on May 17, 2011 at 13:45

The NVIC is for interrupts.  I suppose you could write tasks as interrupts.

Best idea: serious realtime response is ISR.  All else is interruptible. 

Tell us what you are trying to accomplish and perhaps someone will be kind enough to suggest a workable design.  Do you need a realtime OS?  Post contact info & I will describe a simple non-preemptive multitasking scheduler.  (FWIW I live in Santa Clara, CA)

[slimbahri]

Posted on May 17, 2011 at 13:45

in compiling, i have found the following message in infinite loop ''Usage fault: attempt to use a coprocessor instruction''.

wheras, ''coprocessor instructions are not supported on the Cortex-M3.'' and I've not used any coprpocessor instruction'' definitive guide of cortex-M3. (that's just a migration from an old firmware v0.2 to the newest one v3.2)

 here,  the code causing compiler message:

/* stm32f10x_it.c */

/***********extern functions declaration****************/

extern void vPortSVCHandler ( void );

/*------------------------------------------------------------*/

void SVC_Handler(void)

{

 vPortSVCHandler (); 

}  

/* portasm.s */

vPortSVCHandler;

ldr r3, =pxCurrentTCB

ldr r1, [r3]

ldr r0, [r1]

ldmia r0!, {r4-r11}

msr psp, r0

mov r0, #0

msr basepri, r0

orr r14, r14, #13

bx r14  

--> after the instruction ( bx r14 ), debugger go to SVC_Handler, the massage ''Usage fault: attempt to use a coprocessor instruction'' appear  and it makes a HardFault, accessing to the following function:

/* stm32f10x_it.c */ 

void HardFault_Handler(void)

{

  /* Go to infinite loop when Hard Fault exception occurs */

  while (1)

  {}

}

how can I proceed?

regards

Slim

[mrost9]

Posted on May 17, 2011 at 13:45

I'm using FreeRTOS v5.3.1 on an STM32F103RCT6.

I don't have problems using the standard values.

[Tesla DeLorean]

Posted on May 17, 2011 at 13:45

You can't call down like this. SVC_Handler(void) -> vPortSVCHandler ();

The function vPortSVCHandle must be called directly from the Cortex-M3 vectors.

R14 contains a ''magic'' number at that point, not a regular return address. By calling the subroutine, the return address in (LR or R14) points to the instruction after the call, and by modifying you end up executing bad code upon return, and not changing the processor mode.

-Clive

[slimbahri]

Posted on May 17, 2011 at 13:45

Thanks Anis,

it's all right with stm32f103b.

Slim

[picguy2]

Posted on May 17, 2011 at 13:45

From my scheduler:

goTask

        ldr     r1,=curTask

        str     r0,[r1]         ;save TT adrs of task we fire up

        ldr     r0,[r0,#TTSP]

        ldmia   r0!,{r4-r11}

        msr     PSP,r0

        mov     r2,#0xFFFFFFFD ;magic int rtn flag

        bx      r2

Hopefully my spaces remain intact.  Calls to my scheduler are via SVC.  (Which I had to make the lowest priority but that’s another story.)  The above is how I leave the scheduler and fire up a task.  Hope this helps.

[Tesla DeLorean]

Posted on May 17, 2011 at 13:45

I don't see why vPortSVCHandler shouldn't be called in SVC_Handler. For me it's working fine this way. (see my project attached in  my previous post).

 

It works due to luck and a failure to understand what is being done with R14/LR, and what compilers do with the code. You should see the problem if you look at the code generated.

The IAR compiler creates (Your working system, from your compiled ELF object)

08004390 <SVC_Handler>:

 8004390:    f000 b8fa     b.w    8004588 <vPortSVCHandler>

08004588 <vPortSVCHandler>:

 8004588:    4b09          ldr    r3, [pc, #36]    (80045b0 <_?0>)

 800458a:    6819          ldr    r1, [r3, #0]

 800458c:    6808          ldr    r0, [r1, #0]

 800458e:    e8b0 0ff0     ldmia.w    r0!, {r4, r5, r6, r7, r8, r9, sl, fp}

 8004592:    f380 8809     msr    PSP, r0

 8004596:    f04f 0000     mov.w    r0, #0    ; 0x0

 800459a:    f380 8811     msr    BASEPRI, r0

 800459e:    f04e 0e0d     orr.w    lr, lr, #13    ; 0xd

 80045a2:    4770          bx    lr

Where as Keil uVision3 creates this

08000c4a <SVCHandler>:

 8000c4a:    b510          push    {r4, lr}

 8000c4c:    f7ff fa58     bl    8000100 <vPortSVCHandler>

 8000c50:    bd10          pop    {r4, pc}

08000100 <vPortSVCHandler>:

 8000100:    4ba2          ldr    r3, [pc, #648]    (800038c <Test_Alert+0x3c>)

 8000102:    6819          ldr    r1, [r3, #0]

 8000104:    6808          ldr    r0, [r1, #0]

 8000106:    e8b0 0ff0     ldmia.w    r0!, {r4, r5, r6, r7, r8, r9, sl, fp}

 800010a:    f380 8809     msr    PSP, r0

 800010e:    f04f 0000     mov.w    r0, #0    ; 0x0

 8000112:    f380 8811     msr    BASEPRI, r0

 8000116:    f04e 0e0d     orr.w    lr, lr, #13    ; 0xd

 800011a:    4770          bx    lr

In Keil an extra level of abstraction, as defined by your code, will cause an issue. The vPortSVCHandler code needs to be called directly. Even in IAR which has optimized this to a branch you could save time by calling it directly. Try turning off optimization in IAR, things will probably break there too.

-Clive