Adding a printf call causes Demo to crash

slrz1eqr wrote on Wednesday, September 22, 2010:

Hi forum,

I am currently toying with the ARM7_LPC2129_Keil_RVDS demo on the Keil uVision3 simulator. The problem I’ve encountered is that when I insert a printf() call anywhere in main(), the application crashes at startup before even reaching main(). The simulator says:

Data Abort: ARM Instruction at 0000155CH, Memory Access at E3A02066H

The processor is in Supervisor mode before the call to vTaskStartScheduler(), as required.

Any ideas?

slrz1eqr wrote on Wednesday, September 22, 2010:

Sorry, forgot to mention that I’m using FreeRTOS V6.0.5.

rtel wrote on Wednesday, September 22, 2010:

emo on the Keil uVision3 simulator

Thank you for stating that up front.  The simulator is not the environment on which the port was developed or intended to run.  Normally when people report problems in a simulated environment the problem does not exist in the real environment.

nsert a printf() call anywhere in main()

the application crashes at startup before even reaching main()

If the print is in main(), and it is crashing in the startup code, then your problem is not (yet at least) related to FreeRTOS anyway.  The kernel does not start and the stack pointer is not manipulated until the kernel vTaskStartScheduler() is called.  Up to that point, you just have a standard single threaded C program.

I don’t know where printf() is supposed to print to in the Keil tools.  Have you configured it to actually do something (print to COM port, debug terminal, or the like?).  Is it attempting to use memory that has not been allocated?  Etc. Etc.

Regards.

I think you are asking the question in the wrong place.  Keil tech support should be able to answer questions about using printf() and about using their simulator.

Regards.

slrz1eqr wrote on Thursday, September 30, 2010:

Just in case anyone is interested. When you add printf() or some other I/O or memory management C functions to your code, Keil C links in some library modules which make SWI calls at startup. This results in vPortYieldProcessor() being called before vTaskStartScheduler(). To avoid this, you should add to your code:

#pragma import(__use_no_semihosting_swi)

You will also have to retarget some of the library functions like fputc(), fgetc(), etc. In my case, the addition of \Keil\ARM\Startup\retarget.c to my project was enough. For more info, see Building an application for a nonsemihosted environment.

All the best.