Hi all ! I’ve ported FreeRTOS v10 to the ADUCM3029 using Keil v5. I can flash a LED and run a clock task and have now moved to the project I’m targeting which is uploading data to the cloud with an ESP8266 wifi chip. I have 3 tasks. Task 1 = Uart GateKeeper task which just sends UART data out to the esp8266 Task 2 = ReadLine Task which waits for a response from the esp8266 to parse the incoming message Task 3 = Finite State Machine task which tells Task 1 what to Tx, and tells Task 2 what message is deemed successful. It then pends on Task3 sending a successful comparison, else it times out and tries again If successful the FSM can move forward to the next message and transmit that. An interrupt handler puts the Rx data into a circular buffer. When a ”n’ character is received the handler flags a semaphore to Task2 to parse the received line of data off the circular buffer. Task 3 uses a queue of 150bytes (most I’ll send in one go to the esp8266) to send to Task1. Task 3 also uses a queue of 10bytes to send the expected response to Task 2 for comparison ( really only need 10 bytes at most, 2 usually as OK is returned ). Task 2 uses a queue to send a single pass or fail back to Task3 My issue is that I always get a busFault_Handler getting thrown, usually after incrementing up a few of the messages. The system seems to work fine up to that point. I have no other interrupts enabled other than the UART on the system and have no idea why it happens. Can anyone point me in a direction as to how to debug this ? If possible I could do a screen share with someone who knows ?… thanks Mike

If you are using FreeRTOS V10 then there are very comprehensive configASSERT() checks on configuration issues – which is harder on a Cortex-M that really it ought to be. Do you have configASSERT() defined? Also, have you tried debugging the bus fault using the info here: https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html

Hi Richard, Thanks for the tips. After backtracking through and looking at the tasks TCBs I could see the stack was getting corrupted. The culprit was a UART circular buffer not bounds checked, thus causing Rx bytes to overwrite the stack when the WiFi device was sending boot data to my micro. Overall I like the RTOS, but I really have to try and understand the debugging better as I think there was a better and faster way to find this. I note your comment on the configASSERT() but what and where does this output debug data ? I enabled it but there was no sign of it catching an error, but maybe that was normal as there was no error with FreeRTOS itself. If there was some debugging videos on YouTube it would be great, whereas a lot of them are just get up and running. thanks Mike

As you mention in your post, by default configASSERT() is checking internal FreeRTOS operation, although you can use the same macro in your application code. Its semantics are exactly as per the standard C library assert(), and it can be defined to do whatever you want. Some examples found here: https://www.freertos.org/a00110.html#configASSERT