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.
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 ) ); }
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?
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...
I dont remember but when I use SPI without DMA it changes nothing ;)
If you get the same problem with or without DMA, then maybe you should point out that the function was just an example, and you got the same problem in other functions and with or without DMA transfers.
The goal is to try to find the smallest possible program that has the problem, just so that you can eliminate as much code as possible.