Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


System hang ups

Posted by saiberion on March 14, 2007
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.


RE: System hang ups

Posted by Nobody/Anonymous on March 14, 2007
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.

RE: System hang ups

Posted by saiberion on March 15, 2007
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?

RE: System hang ups

Posted by Nobody/Anonymous on March 15, 2007
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.

RE: System hang ups

Posted by saiberion on March 19, 2007
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?

RE: System hang ups

Posted by saiberion on March 23, 2007
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.

RE: System hang ups

Posted by saiberion on March 23, 2007
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)

RE: System hang ups

Posted by saiberion on March 23, 2007
Just now something got to my mind.

the RS485 driver provides an echo which is immediately read. Could this cause any problems?

RE: System hang ups

Posted by Nobody/Anonymous on March 25, 2007
>But I'm step further, before dabt ist xQueueReceive

You must not call xQueueReceive from an ISR. Use xQueueRecevieFromISR() in its place.

RE: System hang ups

Posted by saiberion on March 25, 2007
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.

[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS v10.2.0 is available for immediate download. MIT licensed, and including RISC-V and ARMv8-M (Cortex-M33) demos.

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Cadence Tensilica Cortes

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers





STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner