We are facing issue often in our application and getting below exception:
Abort handler
Tmr Svc
Return register: 0x1007daa1
We are using Renesas R9A07G084M04GBGBC0 MCU. The issue occurs always during application startup where the application creates queues and start sending / reciving data from same
I don’t have much more data to share - please let me know what info you need and helps up to provide the root cause of the issue and how to resolve the same?
Please let me know on what scenarios xQueueGenericSend exception is thrown?
Unfortunately, the most likely cause is also one of the hardest to find, somewhere you program is corrupting memory and corrupting the structure of the queue being referenced.
Thanks but when can this issue be triggered - is it when creating the queue or writing / reading from the queue. Note we see the issue not everytime - once in every 20-25 times
Please provide any other additional information if possible
we need to see your code. If you say this happens during startup but intermittendly, that somewhat reads like a contradicition in terms hecause intermittent errors normally occur only after the scheduler has started. Except of course if you enable interrupts before starting the scheduler wich (as is common knowledge) is a no no.
If you are corrupting memory, as I suspect, it can cause the error at any time the corrupted memory is used. This sort of problem needs either going over you code with a fine tooth code to verify all memory usage (which is hard, but not a bad practice to get into) or using a debugger to check the status of things, seeing what memory gets corrupted (because it doesn’t have reasonable values when used) and then re-running to see when that corruption occured.
As I said, it isn’t an easy problem to find, it is best to start with good memory practices so you don’t cause the problem in the first place.
When a TimerTask throws an unhandled exception, it terminates the Timer thread, preventing future scheduled tasks from running. To fix this, Wrap all code inside your TimerTask.run() method in a try-catch block to handle exceptions locally, or switch to ScheduledExecutorService.
This looks like an AI generated stock answer. Perfectly useless, though, as it fails to answer the question what should be in the catch expression - a timer task is crucial to the system as a whole, and without knowing where the fault comes from and how to gracefully recover from it, SEH won’t help a bit. Also, frequently the root cause for a crash also affects system data structures, making it impossible to recover from a fault at all.
The only ways out here are a watchdog reset to bring the system back to a defined state, or (of course preferrable) find and eliminate the root cause.
Post as much as you wish to and whatever you want, I am no forum authority, what I think and reply is exactly as relevant as what anyone else thinks or replies.
It is just obvious that whoever came up with this answer doesn’t have significant first hand experience in RTOS development and debugging but claims a good deal of authority and competence at the same time. In connection with the fact that this is a first post, it sounded exactly like the semi annual attempts to enter bots into this community.