Tasks using the same resource, Fault?

Kernel
1

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

Tasks:

  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?

2

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.

3

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?

4

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
5

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.

6

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.

7

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.

8

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
OpenOCD: Bug Reporting
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

9

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)

10

Thank you for taking time to report back.