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. Regards Matthias
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). Hope this helps.
The Debug Port works fine. In the Tick Interrupt I included an if statement branching to an inline function for the Debug port’s interrupt. I presume the hang up is caused from the RS485 mode serial port. By the way: How can I inspect the heap size during runtime?
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.
Ok I’m a little bit further now. 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?
Ok here is all I found out regarding my hang ups. 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? Now I rework the ISR and the handler.
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)
Just now something got to my mind. the RS485 driver provides an echo which is immediately read. Could this cause any problems?
>But I’m step further, before dabt ist xQueueReceive You must not call xQueueReceive from an ISR. Use xQueueRecevieFromISR() in its place.
Why FromISR? 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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.