M5223X FLASH - problem reading from one bank

[mjbcswitzerland]

Hi All

I have run into a problem which I can not yet explain and I am wondering whether anyone may have some details.

When performing a memcpy() operation from source FLASH to destination RAM data corruption is detected. The source (FLASH) is correct when monitoring it with the BDM.
The assembler code performing the copy is something like
move.b (a5), (a3)
where the pointer values are correct.

When copying a block of data, it works upto the FLASH address 0x20000 and then from this address the following is observed
4 bytes are correct
4 bytes have the values 0x00, 0x01, 0x20, 0x01
the next 4 bytes are correct, the next 4 have the strange pattern, etc. (what can cause this pattern to be read from FLASH?)

I think that the FLASH is made up of 2 interleaved banks and, if this is correct, it seems as though one of the banks (every odd word for example) is being correctly read by the BDM but not by the CPU. The other bank is however always read correctly.

The problem was never encountered before the starting address of the program was shifted from 0x800 to 0x1000 (a boot loader jumps to this address at start up).

Can anyone explain this? It is consistently observed on several different boards at different locations, by different developers (after the start address shift) and if the program entry point is put back to 0x800 all works normally again.

One extra clue is that also FLASH / RAM copies using DMA are failing. The exact reason is not clear at the moment but it looks as though any interrupts arriving during the DMA transfer result in an exception (as if the FLASH is not available for code access at that time).

There must be a simple explanation for what we are seeing (?)

Any ideas??

Regards

Mark

www.uTasker.com



Message Edited by mjbcswitzerland on 2007-09-04 01:14 AM

[mjbcswitzerland]

Hi All

The problem was solved and found to be due to the initialisation of FLASHBAR in the start up code.

    /* Initialize FLASHBAR - -simplified routine (usually it does work from SRAM) */
    move.l  #__FLASH,d0
    add.l   #0x21,d0
    movec   d0,RAMBAR0

__FLASH is defined in the linker script file and is usually 0.
If the flash starts at 0x1000 (__FLASH = 0x00001000) RAMBAR gets written with the value
0x00001021.
The 0x1000 is a non-defined bit in the FLASHBAR register but if set causes strange behavior (DMA memory operation failure and parts of FLASH can not be read correctly).

To avoid such problems the start up code should not allow undefined bits in the FLASHBAR register to be set. eg.
move.l  #__FLASH,d0
and.l #0xfff80000,d0                           /* protect undefined bit positions in FLASHBAR */
etc...

Regards

Mark

www.uTasker.com