Way to connect MCF5232 lower data line (D0-D15) to flash

[ManojM]

Hi,

In one of our project, we are using processor MCF5232 and schematic is already freezed down and layout is released to  manufacturer. But we found one major difference between Evaluation board schematic and our schematic. In evaluation board schematic upper 16-bit of Processor data lines (D16 to D31) are connected to D0-D15 of flash. While in our schematic we have connected lower 16-bit data lines (D0-D15) of the processor to D0-D15 of the flash. Is there any way to use processor data lines D0-D15 while accessing 16-bit flash. I am expecting typical problem while booting. Please guide me.  This is on urgent note as layout is already released to the manufacturer

Thanks

[TomE]

> layout is released to  manufacturer

Stop them ASAP. The design is toast. Don't make boards. Don't populate them. Junk whatever you have.

> Is there any way to use processor data lines D0-D15 while accessing 16-bit flash.

Once your device is booted it could read and write the FLASH by setting the port to 32-bit and then only reading and writing the lower 16 bits, but that would mean you couldn't read or write data without going through "translation software" and you couldn't execute code from it.

Your fatal problem is:

> I am expecting typical problem while booting

The board cannot boot from that FLASH. Period. It could "boot" from an attached debug pod, but you can't ship them like that. You could use these boards for some sort of internal code development, but it wouldn't be worth it.

If you had a different 8-bit FLASH on D31-D24 or 16-bit FLASH on D31-D16 you could boot from that and then (possibly) operate on the D15-D0 chip. You wouldn't have that.

The only supported booting options are 8/16/32 bit memory on the data pins STARTING at D31 and NOT at D0 (the mistake).

The Reference Manual is very clear on how the chip operates. The Reference Design is there to be copied. Someone used to little-endian designs just didn't do their homework and got is wrong.

After you fix that, be VERY CAREFUL about where BS0 to BS3 connect. Even people who know how these chips work and who have read the manual get that wrong. Copy the reference design slavishly. Don't change anything without a lot of checking.

> The Reference Manual clearly states that D0..15 are "driven with indeterminate values"

That only applies when the CPU is writing to a 16-bit port. To boot it has to read data from the FLASH.

The only option would be to program the port in 32-bit mode, in which case the reset vector would consist of 32 bits, with the lower 16 from the FLASH and the upper 16 from unconnected bus lines, being effectively "random".

So the first branch would be to one of 65536 "random" addresses somewhere in the 4G memory space. Which surprisingly might actually work as on reset, CS0 decodes the entire (or most of) the 4G space:

    16.3.2.1 External Boot Chip Select Operation

    After system reset, CS0 is asserted for every external access. No other chip

    select can be used until the valid bit, CSMR0[V], is set, at which point CS0

    functions as configured and CS[7:1] can be used.

So now try to write a boot program that consists of an array of 16-bit instructions, every second one of which is RANDOM. Have it set up the SRAM, then copy data from the FLASH to there, then start executing from it. I don't think this is possible with this instruction set. It sort-of assumes sequential instructions are valid.

This is not like a PC. There is a REAL difference between little-endian and big-endian CPUs. It is not like a 386/Pentium/ISA anything, meaning "the PC-little-endian way of doing things) is NOT the only way to do things.

On a big-endian chip (68000, Coldfire, Power PC) the bytes are numbered from LEFT to RIGHT, so D24-D31 is "byte zero" and D8-D0 is "byte three". That's why they connect things to the bus in that order. You're lucky you're not using a PPC core, as that chip (thanks to IBM who designed it) names the 32 BITS left-to-right as well as the bytes, with "D0" being the MSB and "D31" being the LSB. Except when the LSB is D7 (8 bits wide) or D15 (16 bits wide).

Now try to transfer "Structured binary data" over Ethernet or disk or memory stick or SD card from there to a little-endian PC and back. It is always a lot of fun.

Tom

[stzari]

Hi,

I fear that won't work.

The Reference Manual clearly states that D0..15 are "driven with indeterminate values" (Chapter 17.5.1, Figure 17-2).

I seem to remember having seen the values of D0..15 on a logic analyzer beeing related to the D16..31, but it would be pure luck if it would work.

HTH

  Stamatis