cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F2xx & Keil RTX

kasper
Associate II
Posted on December 21, 2010 at 07:30

STM32F2xx & Keil RTX

17 REPLIES 17
lowpowermcu
Associate II
Posted on May 17, 2011 at 14:19

Hi jepsen,

Just a propoal; I didn't use an STM32F2 device.

Try to run it at lower frequency (like 24 MHz) and check if you get the same behavior.

Herzlich

MCU Lüfter

kasper
Associate II
Posted on May 17, 2011 at 14:19

Hello,

Thank you for the proposal, but seems no change at all :(

I have played a litle arround and came if i in a task have a debug print out, it seems to work much better, almost without errors, but do i delete this print out so the task actually is empty i get hard fault error. It is properly not this there is the error, but maybe it can give a hint.

for(;;)

{

result = os_evt_wait_or (0x0001,250);

if (result == OS_R_TMO)

{

printf(''BT Timed Out\n\r'');

}

}

It is the printf line i comment out to not have it working :(

Kasper

Posted on May 17, 2011 at 14:19

Instrument the Hard Fault handler to examine the cortex-m3 registers and stack frame to *show* you where the error is.

Joseph Yiu has published some routines that can achieve this, should be able to find examples on the forum here, or on the interwebs in general.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
kasper
Associate II
Posted on May 17, 2011 at 14:19

Hello,

http://rapzak.mine.nu/rtx.pdf

There is shown the fault window of keil, and the call stack is shown...

Maybe not as detailed as the other version for the stack.

I can see what the error flags are, but then i am still clueless, i am maybe not to experienced in this area :(

Kasper
joseph239955_st
Associate II
Posted on May 17, 2011 at 14:19

Some hints about extracting fault information like stacked PC is here : http://tinyurl.com/2eewo9o

 

 

Beside from checking for errors in your applications, please also check the stack size for the tasks in your RTX configuration file.  Which version of the RTX you are using?

kasper
Associate II
Posted on May 17, 2011 at 14:19

Version 4.13A of Compiler and 4.12 of RL ARM

kasper
Associate II
Posted on May 17, 2011 at 14:19

Hello,

I got this output:

1:33:46.922> [Hard fault handler]

1:33:46.922> R0 = 200025e0

1:33:46.922> R1 = 1f4

1:33:46.922> R2 = 20000184

1:33:46.922> R3 = 1

1:33:46.922> R12 = 8004bd1

1:33:46.922> LR = 8004ab7

1:33:46.922> PC = 8004c36

1:33:46.922> PSR = 4100000b

1:33:46.922> BFAR = e000ed38

1:33:46.922> CFSR = 400

1:33:46.922> HFSR = 40000000

1:33:46.922> DFSR = 0

AFSR = 0

My linker file in that regions is:

   i.rt_block                               0x08004a90   Section        0  rt_task.o(i.rt_block)

    i.rt_chk_robin                           0x08004ac8   Section        0  rtx_conf_cm.o(i.rt_chk_robin)

    i.rt_dec_dly                             0x08004acc   Section        0  rt_list.o(i.rt_dec_dly)

    i.rt_dispatch                            0x08004b40   Section        0  rt_task.o(i.rt_dispatch)

    i.rt_evt_psh                             0x08004b84   Section        0  rt_event.o(i.rt_evt_psh)

    i.rt_evt_wait                            0x08004bd0   Section        0  rt_event.o(i.rt_evt_wait)

    i.rt_free_box                            0x08004c10   Section        0  rt_membox.o(i.rt_free_box)

    i.rt_get_first                           0x08004c36   Section        0  rt_list.o(i.rt_get_first)

    i.rt_init_context                        0x08004c60   Section        0  rt_task.o(i.rt_init_context)

    rt_init_context                          0x08004c61   Thumb Code    64  rt_task.o(i.rt_init_context)

    i.rt_init_robin                          0x08004ca4   Section        0  rtx_conf_cm.o(i.rt_init_robin)

    i.rt_init_stack                          0x08004ca8   Section        0  hal_cm3.o(i.rt_init_stack)

    i.rt_mbx_psh                             0x08004cf8   Section        0  rt_mailbox.o(i.rt_mbx_psh)

    i.rt_mut_init                            0x08004db8   Section        0  rt_mutex.o(i.rt_mut_init)

    i.rt_pop_req                             0x08004dc8   Section        0  rt_system.o(i.rt_pop_req)

    i.rt_psh_req                             0x08004e4c   Section        0  rt_system.o(i.rt_psh_req)

    i.rt_psq_enq                             0x08004e6c   Section        0  rt_list.o(i.rt_psq_enq)

    i.rt_put_dly                             0x08004ec0   Section        0  rt_list.o(i.rt_put_dly)

    i.rt_put_prio                            0x08004f08   Section        0  rt_list.o(i.rt_put_prio)

    i.rt_put_rdy_first                       0x08004f40   Section        0  rt_list.o(i.rt_put_rdy_first)

    i.rt_rmv_dly                             0x08004f54   Section        0  rt_list.o(i.rt_rmv_dly)

    i.rt_rmv_list                            0x08004f7c   Section        0  rt_list.o(i.rt_rmv_list)

Can you give me any clue, for me it looks inside the RTX kernel??

Kasper

joseph239955_st
Associate II
Posted on May 17, 2011 at 14:19

Thanks. At least we can rule out outdated toolchain.

I just remember Keil has got an application note about debugging hardfault on Cortex-M3/M4 devices:

http://www.keil.com/appnotes/files/apnt209.pdf

It might also be useful to try finding out if the problem is caused by an interrupt service routine. If you have ULINK2 or ULINKPro, you can enable the interrupt trace.

http://www.keil.com/appnotes/docs/apnt_197.asp

joseph239955_st
Associate II
Posted on May 17, 2011 at 14:19

Thanks for the update. the stacked IPSR is 0xB (

PSR = 4100000b). So the problem happen inside SVC which is inside the OS.

This also match the stacked PC value (

i.rt_get_first) which is 

i.rt_get_first.

From CFSR it seems to indicate the fault is caused by a imprecise bus fault (BFAR is no use in this case).

It might be possible that somehow an IRQ handler could have corrupt the kernel stack, so an exception trace might be useful. (to see which exception/interrupt take place before the fault).