M5223X Internal Flash Speculation Address Qualification Incomplete - Workaround 2

[mjbcswitzerland]

Hi All

I am testing the workarounds to avoid the problem as described in the Errata Rev. 1, 11/2006 but am experiencing a problem with Workaround 2.

Here it is necessary to justify the FLASH to the lower address range of a 256k block and the SRAM to the upper 32k of the same range. I am trying with SRAM at 0x20038000..0x2003ffff.

The problem which I have is that it doesn't seem possible to have the interrupt address vectors in SRAM any more since the VBR can only be aligned to 1 Meg boundaries. To put the SRAM where I need it according to the workaround and also have the vector table in SRAM, the VBR would have to support alignment also at a 32kb boundary. This doesn't work due to the fact that the Coldfire doesn't implement the lower 20 bits of the VBR.

Question is - is this a non-mentioned restriction when using the workaround or is there some way out of the predicament?

Any one out there with the answer??

Regards

Mark Butcher

www.uTasker.com

[jvantol]

Mark,

As long as the lower 18 bits of the address don't match, you'll avoid this bug.

So, for example, if you map the memory in the standard way (flash starts at address 0x0, Ram at address 0x20000000) and you don't use the lower 32k of flash, you will avoid this bug. I've done this successfully, and it worked out great for me because I've got a bootloader that lives in the lower 32k. So what I do is disable speculation in the bootloader (workaround 1) and then, in the application, re-enable it.

Joshua van Tol
Watlow Controls, Inc

[mjbcswitzerland]

Hi Joshua

Thanks. The only disadvantage is that the lower 32k can not be used without workaround 1 as well. If there is enough FLASH in the device (you can afford the lower 32k) it is a practical solution. On the other hand if you have a small device with 128k in total it may be a restriction (can be decided on a per project base).

A base project which I use fits on the M52230 and requres 2k for the boot loader, about 70k for the application inkl. op-sys and TCP/IP stack and then 32k for the FLASH file system. Only workaround 1 is practicable but using an M52233 workaround 2 would also be possible by moving the application to start from 32k. If all interrupt vectors are hard programmed in FLASH, workaround 2 should always be possible by positioning the SRAM correctly. [It's quiet a long time ago now that I was investigating this point and I don't remember the exact details any more...]

Regards

Mark


www.uTasker.com