What could be the problem if a code doesn't start the main function at the beginning? My code does start the function after the main function (if I take a look into the map-file) - the usart in the line 19.
0x100002dc 0x000000e0 Code RO 12 .text main.o 0x100003bc 0x000000d8 Code RO 46 .text usart.o
A part of the memory map of the external flash.
Which part of the whole code could overwrite the flash memory - the variables are not initialize at this moment are they? Could that be a pointer which is not correct initialized in a lib function?
Paul
You haven't even specified what ARM you have, so we don't know if your addresses are in RAM or in flash. If your code is stored in flash, then it is more or less impossible for your program to overwrite the code. IAP interfaces are normally quite hard to trig by mistake.
Have you compared the output from the linker with the contents in the chip? Have you single-stepped the application? What work have you done to figure out the problem?
so we don't know if your addresses are in RAM or in flash.
the addresses from the map file are in the flash memory, where I start the application.
Per, that's the real problem... When I start the programm, then it started at the wrong position - so the first line is line19 in the usart.c file - and not the main.c file.
There's no problem with the content (like where's the SRAM or the Flash). It's really crazy, because, if I commend out one printf() then the code is working. I've a few printf() commands, but only when I commend out the last printf() I have installed, then it works..
If your code is stored in flash, then it is more or less impossible for your program to overwrite the code
I think so too. But what could be the problem for that - is it possible that there are errors in a library file or within the uvision template for this special processor?
A lot of strange things can happen if you get a stack overflow.
Have you tried to set a breakpoint in the startup code - normally uVision will try to run all the way to main() before stopping the first time.
Have you tried to set a breakpoint in the startup code No but I will test it tomorrow.
A lot of strange things can happen if you get a stack overflow
that's true, but I take a look in the memory window, too - and there's no stack overflow...
thanks for your hints...