2010-12-20 10:30 PM
STM32F2xx & Keil RTX
2011-05-17 05:19 AM
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.HerzlichMCU Lüfter2011-05-17 05:19 AM
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
2011-05-17 05:19 AM
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.2011-05-17 05:19 AM
Hello,
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 :( Kasper2011-05-17 05:19 AM
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?
2011-05-17 05:19 AM
Version 4.13A of Compiler and 4.12 of RL ARM
2011-05-17 05:19 AM
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
2011-05-17 05:19 AM
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.asp2011-05-17 05:19 AM
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).