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