cpu: at91sam7x256
I have in my project some global objects, they are by default placed at address 0x200000. My program seems to work properly but occasionally beginning of RAM is filled with zeros by Keil library function at label: __decompress1 in deassembly window. It makes some my variables and pointers are useles and program stops responding. The worst is, that pointers are defined as const and they are not expected to change.
Any idea how to solve this error?
This sounds like a problem in your part of the code. Look for watchdog resets, stack overflow, pointer corruptions or use of uninitialized pointers/array indices in your code.
The zero-init and decopress of const variables should only happen during program startup, so you either gets restarts when not planned, or your code somehow manages to jump into code functions you don't intended to call.
My program seems to work properly but occasionally beginning of RAM is filled with zeros by Keil library function at label: __decompress1 in deassembly window.
I do remember having my variables overwritten be the decompression code. After some investigation, I came to the conclusion that it was a bug in the compression/decompression feature. To work around it, I switched the feature off.
Here is the relevant linker command line option:
www.keil.com/.../armlinkref_chdchgae.htm
It happens even if I disable decompressor.
I noticed, sometimes when should be called function spi.DMA_Transfer( buff, size ); program jumps to code at label __main:
Function works OK but it sometomes happens error in function call...
Any idea... ?
void AT91SPI::DMA_Transfer( void * buff, unsigned int size ) { pPDC->SPI_RPR = reinterpret_cast<unsigned int>(buff); pPDC->SPI_TPR = reinterpret_cast<unsigned int>(buff); pPDC->SPI_RCR = num; pPDC->SPI_TCR = num; while( !( pPDC->SPI_SR & AT91C_SPI_ENDRX ) ); }
It jumps to main()? It doesn't jump to an even earlier position - somewhere in the startup file?
It happens even if I disable decompressor.... How to disable mem init?
It always jumps there. It happens occasionally and there is a few calls of that function and error happens in all of them.
Sorry for my lang mistakes ;)
I don't think you should disable memory initialization. You should find out why your program re-runs memory initialization after startup. It could be caused by software bugs as well as hardware faults.
reinterpret_cast
this is a very unsafe cast, if my memory does not betray me. surely you can get rid of it.
The reinterpret_cast is basically the same as a traditional C cast, but with the difference that it can't remove const or volatile.
But the important thing here is that it will silently cast NULL pointers - that function should contain some code to validate your pointers before you start the DMA transfer. Not only should you check that you have non-NULL pointers, you should also try to verify that the pointers are to reasonable memory areas.
It may be even better to have a special function that does not take several pointers as parameters, but have hard-coded statically allocated buffers.
I haven't checked the datasheet for your processor - have you verified if it is safe/allowed to use the same address for SPI receive and SPI transmit?
OK. I changed some things in my code and now in also jumps to __main: but in LR is always 0xfffe0000 (AT91C_BASE_SPI0).
Is there any way to set breakpoint when LR is written with 0xfffe0000?
Did you check the Stack **AND** Heap size values in your startup file ? This behaviour is likely to happen when you are running out of heap space...
OMG :( The same thing sometimes happens inside assembly code of printf... (if value in LR is correct).
I dont remember but when I use SPI without DMA it changes nothing ;)
With a stack overwrite, you may see a lot of funny addresses all-over. I you jump the processor into the middle of perfectly working code, it doesn't matter that the code is working.
After all, it's contracts programming. The supplier of a function guarantees that the function will do the intended task, as long as you guarantee that you will supply the function with the expected runtime environment and the correct input parameters.