Hello,
we have a weird problem on a MCF5329-based board (16 MB SDRAM, 16 MB NOR-Flash).
On bootup (assembler), we first invalidate the cache completely:
move.l #CACR_CINVA|CACR_ESB|CACR_DNFB,d0
movec d0,cacr
nop
After initializing some stuff, among them the SDRAMC, the cache is enabled with:
move.l #CACR_EC|CACR_ESB|CACR_DNFB|CACR_DCM_CIP,d0
movec d0,cacr
nop
Looking at the memory with the debugger (winIDEA using BDM) when
single-stepping the enabling 'movec d0,cacr', the memory content of the SDRAM starting
at 0x40000000 (cache off):
00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
01 12 23 34 45 56 67 78 89 9a ab bc cd de ef f0
.
.
changes in this way (cache on):
00 11 22 33 44 55 66 77 00 11 22 33 44 55 66 77
01 12 23 34 45 56 67 78 01 12 23 34 45 56 67 78
.
.
That is, every 8 bytes are mirrored onto the following 8 bytes.
Disabling the cache restores the old, correct memory content.
This problem does _not_ occur when the cache is enabled on
the NOR-flash, so it seems to be related to the SDRAM.
I am suspecting that it could somehow be related to the SDRAM-bursts,
because the cache can, as far as i know, initiate burst transfers.
We have an older board which does not have this problem. We triple-checked
the schematics, but it seems ok. But layout changed a bit between the boards,
so the problem could also be timing-related.
Does anyone have any idea ?
Any help is very appreciated !
Update:
we might have found the problem:
at initialization of the SDRAM, we did:
move.l (a1)+,#0x008B0000 // Issue LMR
move.l (a1)+,#0x40130000 // Lock SDMR
The second command is the problem, it seems to apply to an 'extended mode register',
but our SDRAM does not have such a register. Removing this command solves the problem.
Does anybody know something about this ?
Thanks,
Wolfram