Hi, I’have a big problem with… honestly I have no idea with what 😉 Long time ago I wrote quite simple software for Cortex-M0 STM32F030C6 micronotroller. Recently I decided to update FreeRTOS to the newest version and it forced me to update my gcc compiler. And After this two updates the program started to crash in some situations. I did a lot of investigation and finally I decided to write her for some help. I created quite small project which reproduces the problem and Icreated a bibucket repo to give you the whole code. This is what I’m talking about: https://bitbucket.org/upanie/freertos_queuevstasks/src/master/ I described the problem ther in README file. Pleas take a look at this code, it is really simple. It contains everything to build and test it. But to test it STM32F030C6 is needed. I don’t know if wheteher I did something wrong or FreeRTOS is broken or the compiler is broken. IMO the third option is mot likely but I couldn’t find anything interesting about that. It looks like gcc 4.x.x is OK and 5.x.x is broken. Maybe someone nows something about such problems. The code I put in the repo uses FreeRTOS V9.0.0 as gcc 4.8.4 is not able to build V10.0.0 But V10.0.0 compiled iwth the newest compiler fails in the same way. Help!

The code I put in the repo uses FreeRTOS V9.0.0 as gcc 4.8.4 is not able to build V10.0.0 But V10.0.0 compiled iwth the newest compiler fails in the same way.

If I follow the logic of ‘fails in the same way’ then: FreeRTOS V9 with gcc 4.x fails. FreeRTOS V10 with gcc 5.x fails. Which would seem to discount a change in FreeRTOS version or a change in the compiler version being the route cause. I’m afraid ‘started to crash in some situations’ does not provide enough information to start a thread on what might be the solution. Can you say which situations, and how the system crashed (does it raise an exception, does a configASSERT() get hit, etc.).

Forgive me if I’m not clear but there is no place where I wrote that 4.8.4 fails. 4.8.4 just can’t compile V10.0.0 because it contains things that compiler 4.8.4 can’t understand. That’s why I used the older FreeRtos V9.0.0 to be able to build it with the newest and the old (4.8.4) compiler. I just wanted to prevent questions about trying the newest version of FreeRTOS. The newest V10.0.0 crashest the same way as the V9.0.0 does when compiled with 8.x.x Looks like changes between these versions do not introduce any bugs in this area. Because of that I assumed that V9.0.0 would be the best choose as it can be built with 4.8.4 and 5.x.x and 8.x.x compilers. And again the program works fine only when is compiled with 4.8.4. Newer compilers give binaries that crash.

I’m afraid ‘started to crash in some situations’ does not provide enough information to start a thread on what might be the solution. Can you say which situations, and how the system crashed (does it raise an exception, does a configASSERT() get hit, etc.).

I wrote here that I described the problem in the repo https://bitbucket.org/upanie/freertos_queuevstasks/src/master/ and there are a bit more details. But OK, I will write it here too. Let’s say we have two binaries: binA and binB binA is built with gcc 4.8.4 and binA is built with gcc 8.2.1 The simple idea of the test program is: We have two tasks: * task1 waits on queue and if data are present it sends it to the UART * task2 is writing some string and sleeps for 5 seconds And basically that’s it. Here is the code: ~~~ void task1(void *pvData) { (void)pvData; vTaskDelay(100);

while (1) {
    while (xQueueReceive(usart_incoming_queue, &data, portMAX_DELAY) == pdTRUE) {
        xprintf("Task 1 RCV: %cn", data);
    }
}

} void task2(void *pvData) { (void)pvData; int it = 0;

while (1) {
    vTaskDelay(5000);
    xprintf("Task 2: %dn", it++);

// xQueueSendToBack(usartincomingqueue, &data, portMAX_DELAY); } } xTaskHandle th1, th2; void createtasks(void) { xTaskCreate(task1, (const char *) “TSK1”, 64, NULL, tskIDLEPRIORITY+1, &th1); xTaskCreate(task2, (const char *) “TSK2”, 64, NULL, tskIDLEPRIORITY+1, &th2); } ~~~ The full code can be found i the repo. And here it goes: binA works absolutely fine with no problems whatsoever. binB works fine until a byte goes into the queue. Then portYIELDWITHIN_API() (in xQueueGenericReceive) exits and in this moment stack is corrupted. pxQueue points to some random memory which contains some garbage, which is weird as the pointer is held in R0 register if I understand it correctly.. Then some part of xQueueGenericReceive tries to work with the data and simply crashes. Then hard fault handler is called. I can’t tel anything more detailed. It is hard to debug this problem. Now, when I compile the same code with gcc 5.3.1 it crashes even if the queue is empty. But I don’t know where becuse I didn’t investigated it with this version of the compiler. As far as I understand FreeRTOS itself works fine. It really does the job correctly when compiled with 4.8.4. I did a lot of reading and debuging the code of FreeRTOS and it looks really fine. So I’m not sure if this is the correct place to ask for help. Maybe I should look for help on some gcc forum. But maybe I’m not the only one who experienced such problem with FreeRTOS, new GCC and STM32F030C6. If not then this place is probably the best one. I can add that gcc 8.2.1 produce text section about 5% larger than gcc 4.8.4 Maybe some part of context switch is wrongly compiled or maybe I’m doing something totally wrong. I don’t knwo and that’s why I ask other people for help.

Hi, I did not look into detail. But what is the smaller stack size your port is reommending? I assume larger that 64 words. Second, probably the printf exceeds the stack. Depends on the clib being used. Just give it a try with eg. 512 words stack size regards spachner

I already did that. No matter how big stack is the problem is the same. And 512 words is half of the whole RAM of the microntroller 😉 It is STM32F030C6 which has 4kB of RAM. As for printf, it is xprintf actually, a small footprint printf-ish code.

But what is the smaller stack size your port is reommending?

What do you mean by that? Where is such recomendation? When the stacks (for the tasks) are declared to small, FreeRTOS detects it in runtime and I get proper information on a serial console – I checked it. But of course FreeRTOS might not detect stack corruption in every case and that’s why I checked how it works manually. I used watches and observed stack memory gazing it it for hours. And again it works as expected when compiled with gcc 4.8.4 and goes crazy when compiled with newer compilers. Maybe there is some change in some version of compiler that I haven’t heard of. I can’t find such information. Maybe I have to handle it somehow. I don’t know but I hope some of you might know it. And maybe I’m totally wrong and I sticked to the idea that the compiler is guilty that I can’t see something obvious.

How is xprintc() implemented? Specifically, is it using the C library that comes with GCC, or is it a light weight implementation specific to your hardware. The print familiy of functions are often a cause of issues, especially if they [unexpectedly to most] call malloc() somewhere in their implementation – especially if you are using heap_4 and not providing memory to the C library’s malloc() implementation. Also print functions can pull in a lot of code, sometimes all the floating point handling code, which might count for the code size difference. print function are also rarely thread safe. Did you try the code with the print statements removed?

xprintf is lightweight implementation of printf functions. It does not handle floating point numbers. But I’ve just eliminated it from the code (pushed to the repo) to make sure that this is not the source of my problem. Unfortunately notig has changed. But I didn’t believe that that might be a problem since compiled with GCC 4.8.4 works fine.

Hi, usually a FreeRTOS port has a define named: configMINIMALSTACKSIZE spachner

Am 23.01.2019 um 06:53 schrieb Adam Malinowski upanie@users.sourceforge.net: I already did that. No matter how big stack is the problem is the same. And 512 words is half of the whole RAM of the microntroller 😉 It is STM32F030C6 which has 4kB of RAM. As for printf, it is xprintf actually, a small footprint printf-ish code. But what is the smaller stack size your port is reommending? What do you mean by that? Where is such recomendation? When the stacks (for the tasks) are declared to small, FreeRTOS detects it in runtime and I get proper information on a serial console – I checked it. But of course FreeRTOS might not detect stack corruption in every case and that’s why I checked how it works manually. I used watches and observed stack memory gazing it it for hours. And again it works as expected when compiled with gcc 4.8.4 and goes crazy when compiled with newer compilers. Maybe there is some change in some version of compiler that I haven’t heard of. I can’t find such information. Maybe I have to handle it somehow. I don’t know but I hope some of you might know it. And maybe I’m totally wrong and I sticked to the idea that the compiler is guilty that I can’t see something obvious. Corrupted stack – FreeRTOS or compiler? https://sourceforge.net/p/freertos/discussion/382005/thread/707618f02e/?limit=25#210d Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/freertos/discussion/382005/ https://sourceforge.net/p/freertos/discussion/382005/ To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/ https://sourceforge.net/auth/subscriptions/

Hi, usually a FreeRTOS port has a define named: configMINIMALSTACKSIZE spachner

configMINIMALSTACKSIZE is only for IDLE task. It is 60 words in CORTEXM0STM32F0518_IAR. I gave 64 words.