Microcontroller: Atmel SAM4L Compiler: IAR C/C++ Compiler for ARM FreeRTOS Version: 8.0.1 Language: C Code: ~~~~~~ void QueueWriterTask(void* pvParameters) { uint32_t number = 0; char buf[50]; memset(buf, 0, 50); while(1) //lint !e716 { //xQueueSend(TestQueue, &number, portMAX_DELAY); printf(“Sent: %drn”, number); number++; } } main(){ … returntype=xTaskCreate(QueueWriterTask,”QueueWriterTask”,configMINIMALSTACKSIZE,NULL,2,&QueueWriterTaskId); if(returntype!=pdTRUE) { switch(returntype) { case errCOULDNOTALLOCATEREQUIREDMEMORY: printf(“Error: errCOULDNOTALLOCATEREQUIREDMEMORYrn”); break; default: printf(“Error: Unhandledrn”); } REQUIRE(0); } configASSERT(QueueWriterTaskId); …} ~~~~~~ Output: Sent: 4704 Sent: 4705 Sent: 4706 Sent: 4707 Sent: 4708 Sent: 4709 Sent: 4710 Sent: 4711 Sent: 4712 Sent: 4713 Sent: Usage Fault Exception!!!! Register 0: Hard Fault Exception!!!! Register 0: I have a small project that just reads and writes to the uart using USART0. However, I have been having issues with the printf function causing a bus fault at random intervals. It can produce the bus fault after as few as 4000 iterations to as many as 120000 iterations. This was a demo project originally, but has since been stripped down to a task continuously printing out an incrementing number in order to identify the source of the problem. I did have it routing the number information through a queue, but once the queue successfully sent and received 4.7 million items without using any printf statements, I stopped testing it and moved to testing the printf by itself. The only parts not included in the code snippet above is the board initialization code, the bsp include files for the SAM4L, and the task scheduler, while(1), and return statements after the task creation. I’ve enabled the application malloc and stack overflow hooks to verify if the stack and memory allocation were a problem, but neither of them triggered. I’ve increased the stack size to allow for more space for the printf, as well as used different printf implementations, but printf continues to cause a bus fault. I’ve also traced the memory going into and out of the printf by analyzing the memory locations used for the argument passed to printf and the arguments passed to the USART0 after printf processing has finished, and nothing indicates that something is wrong or suspicious other than printf passing a single character at a time to the USART0. Is there anything in the FreeRTOS task scheduler that could cause printf to produce bus faults?

Thank you for providing such detailed information. From your post it sounds like you are using a printf() implementation that is provided by a library (and I note you have tried more than one) and that the output of printf() is being sent to a UART. Some questions: 1) Which printf() are you currently using? (the one provided by IAR, or some other?). 2) What happens if you stub out the output function – so printf() is still called, but the function that writes the output to the UART just returns without sending the output anywhere? I know you won’t see any output being produced, but if the application keeps running it will give us a clue as to where to look next. Regards.

Also note that if it’s a library printf, then it’s probably using the standard malloc and not the freeRTOS one, which means a different stack/heap unless using ‘scheme 3’ in FreeRTOS (which is standard malloc)… check the allocation for it….

1) I am using the printf provided by IAR. To clarify, IAR has several different implementations of printf that they provide implement varying degrees of format options. These different versions are the ones that I have tried. 2) When the output function is stubbed, the application crashes after about 5 minutes. I checked writing to the uart directly to verify it is operating correctly; that test ran for 30 minutes without crashing and had not crashed when I ended the test. We are using heap_2. Our IAR linker file is setup as follows: define symbol ICFEDITsizeheap = 2000 ; define block HEAP with alignment = 8, size = ICFEDITsizeheap {} ; IAR “Linker->Extra Options” set as follows: –redirect malloc=pvPortMalloc –redirect free=vPortFree As such we believe we have a 2000 byte heap allocated for malloc, however, I believe we are redirecting malloc/free to pvPortMalloc/vPortFree. In FreeRTOS we have the following set: ~~~~~

define configTOTALHEAPSIZE ( ( size_t ) ( 20000 ) ) //bytes?

~~~~~ As such, it seems like we should have plenty of space for printf. However, maybe we are doing something wrong here? Also, thank you for your help.

If the malloc and free functions are truly mapped to pvPortMalloc() and vPortFree() then you can set the heap size to 0 as all allocations will come from the FreeRTOS heap – which is dimensioned by configTOTALHEAPSIZE. Do you have a malloc failed hook defined? If not I would recommend defining one to trap heap exhaustion. I would also recommend switching to heap_4.c. Regards.

I didn’t know that the heap size could be set to 0 when using FreeRTOS. I’ve changed it to 0 and rerun the test. It still crashes after running for a few minutes. Yep. It has not been triggered yet during the printf testing. Ok. I switched to the heap_4.c. The printf test still results in a crash, although now the crash produces a memfault instead of a busfault.

Search the FreeRTOS/Demo directory for a file called printf-stdarg.c – you will find lots of copies. It contains a tiny printf() formatter. At the top of the file you can define an out function – which in your case you can define to send the characters to your UART. For now just leave the out function empty though (which it is by default). Include the file in your build to see if it makes a difference. You can place a break point in the printf() implementation the file contains to double check it is actually being called. Regards.

Found it. I tested using that printf, break-pointing to verify that it is actually being used, and found that it produced a mem fault 80000 iterations in. I think that testing a spare board and testing other, unmodified demo applications for comparison might be the next step in order to eliminate any possible configuration or board failures.

I tested another board, but it produces the same problem. I also tested an Atmel asf demo application that only uses the bsp, and it did not trigger a memfault at all. I tested it multiple times with each time running through more than 2 million iterations. For testing a basic FreeRTOS demo, I was unable to find one that uses IAR for the SAM4L. Does anyone know if there is a FreeRTOS demo application for the SAM4L that is compiled with IAR?