STM32F2xx & Keil RTX

[kasper]

Posted on December 21, 2010 at 07:30

STM32F2xx & Keil RTX

[kasper]

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

[lowpowermcu]

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

[joseph239955_st]

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]

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

[Tesla DeLorean]

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.

[kasper]

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

[kasper]

Posted on May 17, 2011 at 14:19

Version 4.13A of Compiler and 4.12 of RL ARM

[joseph239955_st]

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

[kasper]

Posted on May 17, 2011 at 14:19

Hello,

I am very happy for your help!!

I have the Ulink2, but sadly i have forgotten to connect the SWO line and used it for CLK to my I2S. 

But i can solder a wire on this pin and use is for some use.

I will come back later with the result, so i hop you could help to analyse.

I will not be home the next couple of days, so it can take a litle time.

Kasper

[joseph239955_st]

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).