Trouble initializing chip select after flash programming

[louis_springbok]

I've run into a problem with coldfire 5272 and the flash interface.

This is a problem that seems to be hit and miss. I've programmed dozens of instruments with P&E's progCFZ flash programmer and have not had any issues, after removing the programmer the instrument would boot. Now I suddenly have each instrument verify correct programming in flash but the instrument will not boot.

Stepping through the bootloader with codewarrior I get an address error when attempting to initialize the chip select register for the Flash.

If I replace the flash on the board with another chip with a different date code the instrument will work. But why was this necessary? I'm able to remove power after programming the Flash and then reconnect to progCFZ and verify the S19 files correctly with an instrument that does not boot.

If the ProgCFZ BDM interface is able to communicate with the flash through the 5272 then the 5272 should be able to operate with the flash, correct?

Here is my chip select initialization code:

MCF5272_CS_CSBR0 = 0

        | MCF5272_CS_BR_BASE(FLASH_ADDRESS)

        | MCF5272_CS_BR_SRAM

        | MCF5272_CS_BR_BW_16

        | MCF5272_CS_BR_EN;

    MCF5272_CS_CSOR0 = 0

        | MCF5272_CS_OR_MASK_32M

        | MCF5272_CS_OR_WS(3);

[TomE · Accepted solution]

There are two possible answers to your problem, but I don't have enough data to be sure. So the following is "back of the envelope".

First, what is the speed rating of the FLASH chips you're using? What are the address-to-data specs and the OE-to-data specs?

Second, I assume you're running the bus at 66MHz, or 15ns.

The Chip Select Decoder defaults to a CSOR) value of 0xfffff078, which means 30 wait states or an extra 450ns.

You're reprogramming that to 45ns of extra delay.

> If the ProgCFZ BDM interface is able to communicate with the flash through the 5272 then

> the 5272 should be able to operate with the flash, correct?

Yes, if you didn't change anything between the BDM and your access. Changing from 30 to 3 wait states is an obvious place to start looking for any problems.

Looking at "Figure 20-3. Longword Read; EBI = 00; 32-Bit Port; Internal Termination", it looks like Address and CS are asserted prior to the low C1 cycle, and the data is latched around the end of low C2. "Figure 23-3. Read/Write SRAM Bus Timing" gives the real figures.

The minimum bus access time with no wait states is four clock edges minus MAX(B8, B6a) minus B4, or 4 * 15/2 - 13 - 14 = 3ns.

The minimum output enable to data time (no wait states) is two clock edges minus B6c minus B4 or 2 * 15/2 - 9 - 14 = -8ns.

Adding your three wait states means the FLASH chip you're using must be faster than 48ns (address) and 37ns (OE).

Ths chips we use are 90ns. How fast are yours?

If you're running the bus at a different bus speed these figures will need to be reworked. If you have and address or data buffers in your design you'll have to add all of the delays through those chips too.

Changing the date codes of the FLASH chip might get you a faster batch that might be just within the timing you're demanding of it while the other ones might be just outside. At room temperature. Under ideal circumstances. You'll need to consider the "worst case" operation.

So what happens after you reprogram the Chip Select from 30 to 3 wait states and the FLASH isn't quite fast enough? You'll start reading illegal instructions or bad addresses from the FLASH.

The second possibility might be that the chip select decoder may not handle having its control registers rewritten WHILE it is using those control registers to generate the bus timing for current accesses. This simultaneous access might "glitch" the output timing, generating a fast cycle. That may be tripping up the Flash.

The manual doesn't say you CAN'T reprogram Chip Select decoders that are currently operating, but it doesn't say you CAN either. The safest approach is to copy a small function to RAM that reprograms the registers and to call that instead of pregramming the registers "in-line".

Tom

[louis_springbok]

Thank you for the very informative reply.

Some more information:

5272 is running on a 48MHz clock (20.8ns)

The flash has 110ns CE# Access Time

                    25ns OE# Access Time

                    30ns Data setup time

So if I recalculate your equations

minimum bus access time with no wait states = 4 * 20/2-13-14 = 13ns

minimum output enable to data time (no wait states) = 2 * 20/2 -9-14 = -3ns

Flash must be faster than 73ns (address) and 57ns (OE), correct?

After changing to 7 wait states (140ns) I have proper system operation.

Thank you!!!

Louis

[TomE]

> Flash must be faster than 73ns (address) and 57ns (OE), correct?

Near enough. To generate 110ns timing the wait states have to be (2 + W)*t = 110+13+14, or W = ((110+13+14)/t)-2.

For "t" = 20.833ns, W = 4.57, so round up to 5 wait states.

Recalculating (2 + 5)*20.833-13-14=118ns, which is within spec for the Flash.

Why did you choose 7 wait states? Do you have address and data buffers between the CPU and the Flash?

> The flash has 110ns CE# Access Time

>                     25ns OE# Access Time

>                     30ns Data setup time

The Data Setup time for the FLASH is only for when you're writing to it. There's no "data setup time" for that chip when reading it. Instead you have to use the "B4 Data input (D[31:0]) valid to SDCLK (setup)" time for the CPU of 14ns, which is already in the calculation.

So you can use 5 Wait States. But you should check every other part of the timing in case the Flash has a requirement that needs RDAH, WDAH or ASET.

Where did the original "3 wait states" come from? Was that from a previous project with a slower bus clock, or from Freescale (or other) sample code for a different chip?

So you'll be using 5 wait states on top of the minimum 3 bus cycle read timing. That's 8 clocks at 48MHz or 166.7ns or 6MHz. Since you're using a 16 bit chip, than means a maximum 32-bit read rate of 3MHz which will limit your 48MIP CPU to about 3MIP for instructions that need 32 bits. Or about the same speed I was getting from 68300 series chips in 1991. Is performance important in your application?

Most FLASH chips support burst or page mode which reduces the page access time to 30ns or less. The MCF5272 Chip Select module doesn't support Burst Mode. You need to use the MCF53xx chips to get that.

If you have an SDRAM chip on your board, then the code will run a lot faster from there than from the FLASH. The SDRAM controller supports burst/page mode. You can also load small critical functions into the SRAM, but as there's only 4k of that they have to be small. You also have to put the stack somewhere fast (but then you have to be very careful to not run off the end of the stack).

This CPU has an instruction cache, and it can get the CPU back near one instruction per clock. It is a relatively tiny cache, being only 1 kbyte, or 256 32-bit words arranged in 64 16-byte lines. It is very easy for a long function call or long loop to break it. If your current code isn't fast enough there's a lot of scope for tuning.

I also wrote:

> The manual doesn't say you CAN'T reprogram Chip Select decoders that are currently operating, but it doesn't say you CAN either.

> The safest approach is to copy a small function to RAM that reprograms the registers and to call that instead of programming the registers "in-line".

I looked back through some previous code. I found code changing the chip-selects (while running in the memory they address) in 68331 code in 1993, apparently without problems. But the CPU32 in that chip probably didn't "pipeline". I was more paranoid programming an MCP860 in 1998. In that code I call a function in RAM to change the chip selects. Where I work at the moment we use MCF5235 and MCF5329 chips. We reprogram the Flash chip-selects on both of them while running from them, so it seems to work.

Tom