PLEASE HELP! Processor = MCF523X, CodeWarriors V10, external Flash memory connection question

[Dogbert256]

PLEASE HELP -- PLEASE HELP -- PLEASE HELP --

My design uses the MCF5232 processor with an 16 bit external flash chip(s).  Got back 10 prototypes some months ago, and have been programming using the internal 64K SRAM on the processor.  Everything OK.  But now I'm past the 64K limit and need to run my code from external Flash memory.  I've managed to erase and blank check the flash boot chip, but cannot program it.  Simple quesions concerning how to connect a 32 bit ColdFire uP to a 16 bit flash device:

A)  I've connected A0 on the processor to A0 on the Flash chip (A1 to A1, A2 to A2, etc...).  Have just now noticed that for the M523XEVAL board schematics that A1 is connected to the Flash chip A0 (A2 to A1, etc...).  Have I just done a Boo Boo and will I have to now rewire the address lines such that A0 is not connected to anything, A1 is connected to A0, etc...  And is this why the flash algorithms provided do not work?  I'm thinking now that the processor uses the A0 to get bytes, and since my Flash does not have a BYTE pin, which would normally be connected to A0, there is a screw up whenever the processor tries to access byte data from the 16 bit device.  And this would screw up the flash algorithms provided since they all seem to be based on byte level access.

B)  If this be the case why is there not a warning/recommendation in red capital letters that says such.  This is my first time with this processor and 16 bit Flash, I'd assume that A0 is connected to A0.  Nowhere does the MCF523X Reference Manual mention this.

THANK YOU, and by the way, if you are able to (PLEASE) help me I have connections with Saint Dogbert and I guarantee that you will be blessed!

Dogbert256 

[TomE · Accepted solution]

Yes, A0 on the FLASH chips addresses 16-bit words.

The CPU provides A0 so you can program an 8-bit-wide port. For 16-bit ports you shift the addresses by one, and for 32-bit ports you shift by two (if the 32-bit chips address 32-bit words and their address pins start from zero).

> If this be the case why is there not a warning/recommendation in red capital letters that says such.

Partly because everyone knows this, sorry. They can't warn about everything that someone might get wrong.

Secondly because the Reference Manual isn't meant to detail how to USe the chip. That's what the App Notes and the Development Boards are for, and that's where this information is.

Check Figure 1 on AN2982. It shoiws A23-2 connecting to A21-0 on a 32-bit FLASH chip. Figure 2 shows A22-1 connecting to A21-0 on a 16-bit FlaSH chip.

Those App Notes are filed under the MCF5208, but you have to search every similar processor to the one you're using to find this.

Then check the development board schematics here:

http://www.freescale.com/files/32bit/doc/user_guide/M5235EVBUM.pdf?fpsp=1&WT_TYPE=Users%20Guides&WT_...

They show the proper address line connections.

What you're meant to do is to start with one of the Development Boards, get your code working on them, and then *SLAVISHLY COPY* the development board schematic.

The schematic has lots of pullup and pulldown resistors that you might miss out if you "design from scratch". Then there are lines that might need series terminators, and all the complexities of all the different power supplies and their bypassing and sequencing. Then there's the difficulty of making sure you get the "byte lane selects" the right way around. The MCF chips are big-endian (high byte is low address). So are the MPC chips, except they number the BITS from the top down! And so on.

We used the MCF5329. There are THREE or FOUR different Development Board schematics, they're all different, sometimes contradictory and some of them seem to deliberately do things the manuals say not to do.

I'd suggest you compare your schematic with the development board ones, and then seriously check every discrepancy.

Tom

[Dogbert256]

Thank you so much for your >>competent<< reply.  Yes I did do the entire board "from scratch" w/ out first using the EVAL board.  I did look at the EVAL schematics, but failed to appreciate and/or didn't notice how the address bus was shifted by one for the 16 bit flash chip.

This is a Boo Boo on my part.  Fortunately everything else is working OK.

Fortunately I'm using the 160 pin QFP package, and I can get to the uP pins.  Next is to bend the pins up and rewire with some cat's whiskers.

Thanks again and I will have a word with the Big Dog in the sky.

Dogbert256

[scifi]

Don't forget that you'll probably have to rewire only a couple of lines. A1, A2 and so on can stay.

[TomE]

> Don't forget that you'll probably have to rewire only a couple of lines. A1, A2 and so on can stay.

That's a good point.

The simplest fix is to disconnect pin A0 on the FLASH and wire it to the highest-order CPU address line.

That would have no effect on a RAM chip, but with a block-oriented FLASH it would mess up the erasing and programming because  you would now have alternate FLASH words in different FLASH blocks.

The FLASH may have "burst programming" where sequential words within a block have meaning. If not, then you may only have to preserve the block addresses.

Of course you can write software to try and handle any level of address pin scrambling (and data pin scrambling if required), but that could waste more time and money than getting new hardware might.

The simplest fix may be to treat the FLASH as an 8-bit part on these boards as that's how it is currently wired. The chip may have a pin that swaps it between 8 and 16 bit access. You have to be driving RCON to boot from a 16 bit part (RCON off defaults to 32-bit), so just swap the straps on the pins that set BOOTPS[1:0] and it will work as an 8 bit part and boot from it.

Tom

[Dogbert256]

Thanks for the replies.

I had briefly considered just reconfiguring RCON to make for an 8 bit address port to the MCF523x.  But then I got to thinking about how the Flash would be programmed, and came to the conclusion that it couldn't, unless I rewired the data lines.  Unfortunately in 8 bit mode the active data lines are D[31: 24], which as now wired correspond to the upper byte on the Flash chip.  The programming algorithm (Common Flash Interface - CFI) require writes to the Flash chip such as 0xAA, which is lower byte data (unless there's some type of Endian thing going on w/ the Flash, which isn't mentioned in the Flash data sheets so i doubt it). 

Either way, I'm stuck into rewiring the prototypes.  So I guess I might as well try to just shift all addresses by one, and pray that I don't screw things up worse.

Dogbert256