Hi,
I have problems with system hang ups with a AT91SAM7S Controller.
It only hangs up after a certain amount of communication packages sent over an UART port in RS485 mode. The debug port can be "bombed" with characters for hours without problems.
In some cases the controller is then in dabt or the scheduler seems to be still running (HeartBeat Task still handles LED).
When it is in dabt the system hang up seems to be caused by xQueueSendFromISR which presumably is called from the RS485 UART’s ISR. This ISR has 2 queues; 1 for storing a complete communication package the other one for signaling the handler task. To exclude too less stack I already use a 2kB stack for the handling task.
In the other case the UART peripheral task (RS485 and Debug Port) are not responding only the debug port ISR seems to work cause it toggles its asserted LED if a character is received but it does not respond to it.
How can I find out what caused the Queue function to fail? (From degugger it seems like wrong queue handle)
How can I find out (in the 2nd case) what is the task’s state by just looking into memory.
How are you using the debug port interrupt? Have you changed the kernel to achieve this as the debug port and the utilized timer use the same system interrupt. COuld this be a clue?
You can inspect the current task by viewing the pxCurrentTCB variable in the debugger. Take a look at the function that lists the tasks along with their states in tasks.c to see how to get information on the other tasks. (look for sprintf() in the tasks.c file to find this).
The heap size will only change when a queue semaphore or task is created. How you find out how much is left is dependent on the implementation you are using. heap_1 and heap_2 are quite simple, take a look in the files and you will see there is a variable that you can inspect (actually, is this true for heap_2? You might have to traverse the chain). Heap_3 is harder as you have to get information from the build map file.
the hang ups occur after a sertain amount of bytes sent to the UART (~2550 bytes).
Some time before that happens one of my global variables for addressing the µC is changed somehow (couldn’t find why yet) causing it not to react to valide packages.
When the dabt happened in the xQueueSendFromISR even the queue handle is changed somehow to 0x1
Is there a way to watch these variables with arm-elf-gdb?
The hang ups only occur, if I use interrupts for receiving bytes. (Polling worked quite ok with some missing bytes though )
To my shame I have to admit that the ISR also does my package recognition using a counter variable and a conditional clause.
Could this lead to interrupt calls while ISR hasn’t finished yet and therefore could be the problem, that first one of my globals is going to be overwritten after a certain number of bytes received and after some other bytes cause a dabt?
Rework doesn’t work either.
But I’m step further, before dabt ist xQueueReceive
But still my global variable was changed (earlier debugs brought me to a list function where things go wrong) und the queue handle is 0x1 (what’s definitely wrong)
it’s the xQueueReceive from the task waiting on the queue.
As I understand it xQueueReceiveFromISR() has to be used if (why ever) if an ISR is waiting on a queue.