Hi Richard, AWS team & fellow FreeRTOS enthusiasts,
I have some questions after having journeyed with FreeRTOS for some months. Firstly, I would like to say it is an excellently designed system and one of the best APIs I have ever worked with.
My environment is as follows:
- FreeRTOSv202406.01-LTS (Kernel v11.1.0)
- MCUXpresso IDE v24.9 [Build 25] [2024-09-26]
- NXP Arm Cortex-M7 (MKV58F1M0xxx24)
My requirement is to develop an extremely stable embedded application that needs to run for years unattended. Because of this, I chose static memory allocation for the whole application. In fact, it was instructed by my boss. The application has several comms peripherals:
- SPI → Wiznet W5500 → TCP, UDP
- I2C
- CAN
- CANopen
- UART
Note: Only 1, 3, 4, 5 are coded in FreeRTOS at the moment
It also has the following tasks at the moment:
- UART user interface
- TCP user interface
- Error handling
- Error logging
- Data logging
- Supervisory control (decision making)
- Dynamic control (1 kHz PID control loop of a large servo motor)
Note: Only 1 and 6 are coded in FreeRTOS at the moment
My problems with this setup basically involve:
- Regular hanging of the entire application.
- Sometimes if it runs, all functionality ceases and I’m forced to press “pause” on the IDE. Then a very long stack trace appears, typically ending in a SIGTRAP, with the running pointer pointing to a FreeRTOS file, often tasks.c. Recently it got stuck where the number of idle tasks are being compared to the number of cores. But they should both be 1. I set number of cores to 1 in FreeRTOSConfig.c, as per my MCU.
My observations are that even though MCUXpresso has “views” for FreeRTOS, e.g., a task list, it lists nothing while the application is running. Only after pressing “pause” does the IDE populate the task list, and all tasks are blocked except the idle task. But this scenario cannot be correct because the IDE just halted the whole MCU.
Having a tool like Percepio Tracealyzer would be great but our company is in South Africa, and we cannot afford it.
Is there a way to get this done with MCUXpresso alone? (I must also note that printf sometimes also hangs the system but at least I can print to the MCUXpresso console).
There are 3 things in FreeRTOS objects that I want to share my experiences with and ask your opinion about if you don’t mind:
- Tasks. I have basically tried periodic tasks and event-driven tasks (with a semaphore or queue unblocking it). In my experience, the event-driven tasks are way more stable and predictable. All my periodic tasks hang regularly. What am I doing wrong?
- Inter-task communications. I have had working queues and binary semaphores. But they also recently started hanging the whole application. I have given up on task notifications completely, I know they are great because they bypass the kernel, but I just couldn’t get it working. Am I doing something wrong here?
- Design philosophy. I started with many tasks as I think the FreeRTOS design philosophy is: each task performs only one – well – task. This is evidenced from my list of comms pheripherals and tasks above. However, I am now leaning towards the opposite side of the spectrum: as few tasks as possible. The reason for this is that I simply cannot get the inter-task communications to work. So it seems I am going to have a massive supervisory control task and then a few smaller ones. But this leans in the direction of bare-metal design and is against the FreeRTOS philosophy, right?
Note: I am careful to choose task priorities well and also assign enough stack memory wherever it is required.
I am sorry for the long post, but I am really at my wit’s end. I would really appreciate anyone’s advice. Maybe there is something wrong with my setup causing the application to hang regularly?
Thank you so much for reading this and any replies you might have.