Tasks using the same resource, Fault?

I’m using FreeRTOS with STM32CubeIDE and seem to be running into an issue with the firmware hanging? I’m wondering if two tasks accesses a GPIO pin (ex: LED blink) at the same time, or try to access the UART bus at the same time, it could cause it to fault/hang? I have these tasks below all set to Normal Priority


  1. Temperature Sensor: BME680 polling (I2C). Reads temperature then sends data to server (UART)
  2. Simple GPIO On/Off Read
  3. ADC Read: Polls ADC then sends data to server (UART)

ESP8266 Wifi Module: Sends Data to server (UART)

For task #3 above, even if I comment out the line where I send data to a server, it will still hang. However, if I set Task #3 to Idle Priority (never called) the firmware doesnt hang at all.

I tried setting up OCD to debug in STM32CubeIDE, but can’t seem to get it to work properly.

Any tips on how to go about debugging or what I’m doing wrong?

ST-Link GDB/OCD server debugging - See ST AN5361 for details of how to setup the debugger.

This document also explains debugging using OCD if i aint mistaken.

As for the firmware hanging, this can be causes by 2 tasks accessing the same resource (uart in this case), gpios are relatively save i think. If its indeed the uart that causes the problem then u need to use a semaphore around the access of the resource a.k.a uart.

Thanks for the document reference for setting up the OCD debugging!

I tried using a semaphore before, but it didn’t help. I’ll try it again.

There is also a UART interrupt callback function. Does this interfere with any tasks that run on FreeRTOS?

The interrupt callback is run inside the ISR so if u call any freertos function inside of there then yes. If u need to use freertos function inside the callback or inside the ISR then use the function that has the fromISR at the end.

For example if u add the uart data to a queue use the function:

xQueueSendFromISR( xRxQueue, &cIn, &xHigherPriorityTaskWoken );

This is documentented in the freertos API: https://www.freertos.org/a00106.html

1 Like

I’m not calling any freertos tasks from within the interrupt callback function so it should be okay?

Thanks for the example and API link. I’ll check it out as well.

Yes, unless u call other functions in the ISR that cause an interrupt, in that case u need to make sure that the priorities of the interrupts are correctly configured.

It is helpful to define configASSERT during development as it catches incorrectly configured interrupt priorities and other common mistakes.

Here is a common definition of configASSERT to be used during development: https://github.com/FreeRTOS/FreeRTOS/blob/master/FreeRTOS/Demo/CORTEX_MPU_STM32L4_Discovery_GCC_IAR_Keil/Config/FreeRTOSConfig.h#L155


Thanks I will try this as well.

Unfortunately I can’t seem to get the OCD Debugger to work properly. I did reference the AN5361 document that MLens provided as well as the instructions from this site:


This is the log while running the debugger:

Open On-Chip Debugger 0.10.0+dev-00021-g524e8c8 (2019-10-14-11:52)
Licensed under GNU GPL v2
For bug reports, read
none separate
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 4000 kHz
adapter_nsrst_delay: 100
Info : Listening on port 6668 for tcl connections
Info : Listening on port 4446 for telnet connections
Info : clock speed 4000 kHz
Info : STLINK v2 JTAG v34 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.241434
Info : Stlink adapter speed set to 4000 kHz
Info : STM32F030CCTx.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Listening on port 3335 for gdb connections
Info : accepting ‘gdb’ connection on tcp/3335
Info : device id = 0x10006442
Info : flash size = 256kbytes
undefined debug reason 7 - target needs reset
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x1fffdc40 msp: 0x20000a90
Info : Stlink adapter speed set to 4000 kHz
adapter speed: 4000 kHz
Info : Padding image section 0 with 4 bytes
Info : Padding image section 1 with 4 bytes
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0x20000a90
Error: Error reading thread list item object in FreeRTOS thread list
Error: Error reading thread list item object in FreeRTOS thread list

I was able to solve the firmware hanging issue. I had to increase the stack size for each of the tasks, as well as increase the maximum heap size (configTOTAL_HEAP_SIZE) in the FreeRTOSConfig.h file.

(I still wasn’t able to setup OCD Debugging on the STM32CubeIDE)

Thank you for taking time to report back.