We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello, I have 2 identical projects. the exact same code, the exact same project settings (except minor changes in the .uv2 file). the working project starts all tasks correctly, while the bad one calls the sixth task "_maybe_terminate_alloc". that task does start, but does not respond to signals. I have verified that changing the order of a file in the file list of uv3 will generate a bad binary. here are excerpts from the bad .map file:
os_sys_manager_ret 0x000291fd Thumb Code 0 rt_hal.o(.emb_text) SWI_Handler 0x00029224 ARM Code 184 rt_hal.o(.emb_text) os_switch_tasks_ret 0x00029261 Thumb Code 0 rt_hal.o(.emb_text) _maybe_terminate_alloc 0x000292e5 Thumb Code 0 maybetermalloc1.o(.emb_text) dummy_task1 0x000292e4 ARM Code 4 main.o(.text)
while the functioning project has this:
os_switch_tasks_ret 0x00029281 Thumb Code 0 rt_hal.o(.emb_text) ADC_IRQHandler 0x00029304 ARM Code 44 isr.o(.text) _maybe_terminate_alloc 0x00029305 Thumb Code 0 maybetermalloc1.o(.emb_text) dummy_task1 0x0002933c ARM Code 8 main.o(.text)
the function 'ADC_IRQHandler' is located in the file whose order of build has been change - no other changes were required to make the binary startup correctly! Any advise would be appreciated (Keil support did not reply, yet...)
this looks like a linker failure - notice the location of '_maybe_terminate_alloc' in the first code excerpt!
I have reported this issue to Keil support along with the projects that cause this behavior. I will report when I know more. If this is indeed a linker failure, you can expect an update...
Keil support response:
Hi Tamir, I don’t think it is a RTX issue. It is more likely a debugger issue, looking up the wrong label. Meanwhile I managed to get a plain RTK_Blinky example to show the same behavior, where taskname is changed to _maybe_terminate_alloc. Here my mapfile section of this:
os_switch_tasks_ret 0x0000037d Thumb Code 0 rt_hal.o(.emb_text) _maybe_terminate_alloc 0x00000401 Thumb Code 0 maybetermalloc1.o(.emb_text) phaseA 0x00000401 Thumb Code 10 blinky.o(.text) phaseB 0x0000040b Thumb Code 10 blinky.o(.text) phaseC 0x00000415 Thumb Code 10 blinky.o(.text) phaseD 0x0000041f Thumb Code 10 blinky.o(.text)
Here it is same address. But the order of the labels as printed in the mapfile seems relevant. The reason why in your case _maybe_terminate_alloc has higher address is probably, that this is “thumb code†and your task is “ARM codeâ€. Both have actually the same address, but thumb code will show up at odd address. I see this as well, when switching my project to ARM mode:
os_switch_tasks_ret 0x00000385 Thumb Code 0 rt_hal.o(.emb_text) _maybe_terminate_alloc 0x00000409 Thumb Code 0 maybetermalloc1.o(.emb_text) phaseA 0x00000408 ARM Code 20 blinky.o(.text) phaseB 0x0000041c ARM Code 20 blinky.o(.text) phaseC 0x00000430 ARM Code 20 blinky.o(.text) phaseD 0x00000444 ARM Code 20 blinky.o(.text)
As I said, I will discuss this internally. If I have more news on that, I will let you know.
Best Regards, Andreas Barth
I colleague of time managed to cause RTX to hang in the function 'os_put_prio' while on a debugger (hence, no task got serviced anymore). We have sent a report (including screen shots) to Keil support. I hope to report soon about the causes. I built a new version of the controller software using the sources of RTX (not the binary; Keil confirm that the sources installed by RL-ARM 3.50 correspond with the library of MDK 3.50) and left the system running for the night. This might allow more debug information.