Writing to flash memory on MCF 5235

[sampson711]

Hi,

I'm relatively new to coldfire microprocessors and I am attempting to write a single byte of data to the flash memory on the 5235 evaluation board. The flash memory device on my board is the M29W160EB. I have consulted the data sheet for the flash memory and it is possible to write a byte of data by issuing the following sequence of write commands:

Address             Data

555                      AA

2AA                      55

555                      A0

PA                        PD                      where PA is the address to write to and PD is the data to write

I thought this would be straight forward to implement, but I can't seem to get it to work. I am working with the CodeWarrior IDE  which includes a basic hello world application specifically for the 5235evb which I am attempting to modify to accomplish my flash write. The base memory address of the flash is 0xFFE00000. I am running my code from external RAM. Here is the c code that I thought would accomplish the job:

vuint8 *faddr;

int main(void)

{

          faddr = (vuint8*)0xFFE00555;

          *faddr = 0xAA;

          faddr = (vuint8*)0xFFE002AA;

          *faddr = 0x55;

          faddr = (vuint8*)0xFFE00555;

          *faddr = 0xA0;

          faddr = (vuint8*)0xFFE00000; /* Write some byte to some address*/

          *faddr = 0x11;

}

I've played around with the wait state value in the Chip Select Control Register as I was concerned that it may be a timing issue but I have not had success with that. Also, I would have thought that this would be configured properly by default.

Anyway, if someone can shed some light on what I am doing wrong and steer me in the write direction (haha) I would really appreciate it.

Thanks

[stzari]

Hi,

a few things to check ...

- can you program your flash using other tools ?

- how is your flash connected to the CPU (Byte/Word, Adresses, Data)? Depending on how the flash is connected to the CPU you might not be able to program single bytes. Especially check how the Addresses translate to the Address lines in your configuration

- Wait States ...

- Cache? Don't use it for Flash writing

- Wait for completion

- Unblocking necessary ?

HTH

  Stamatis

[sampson711]

Hi stzari,

Thanks for the reply.

-I can program the flash using the Flash Programmer tool that is included with the Code Warrior development environment.

-The flash is connected to the CPU through the address and data buses on chip select 0 with a base address of 0xFFE00000. I think you are correct in that I should not be attempting to write single bytes. I have modified my code to write 16 bit words, but it is still not working.

-I have read about the wait states in the MCF5235 manual and I understand that they can be set using the CSCR, but I don't necessarily understand their exact impact. There is an initial wait state which is set to 6 in the system initialization routine that is provided with CodeWarrior. The secondary write wait state and secondary read wait states are disabled by default. Is a wait state one cpu cycle or is it defined somewhere? I can't seem to find any reference to the actual length...

-I just tried disabling the cache but it didn't seem to make a difference.

-As far as waiting for completion, if I understand correctly, the memory does not include a transfer acknowledge signal. An internal transfer acknowledge is generated after the specified number of wait states.

-Could you please explain in more more detail what you mean by 'unblocking necessary'?

Also, is there a way to directly manipulate the address bus, data bus, chip enable, write enable, etc. signals? i think I could probably tackle this if I had direct control over their values and I could create my own delays to conform with the timing diagram provided by the memory manufacturer...I am connecting to the evaluation board with a pemicro usb multilink.

Many thanks for any help provided.

[stzari]

Hi,

after a look at the datasheet and the EVB schematics I think that your problem might be the address translation.

As B_A1 from the CPU is connected to A0 on the device you will have to shift the command address. So, you would have to write faddr = (vuint16*)0xFFE00AAA; instead of faddr = (vuint16*)0xFFE00555;

With "checking for completion" I did not mean a single write access. Writing to a flash takes time - you will have to wait until the data are written to the flash. Repeatedly read the written address until the data read matches the programmed value. See page 20 in the datasheet for a flowchart.

Forget about unblocking ;-)  Checking the datasheet I found that this device does not offer an easily accessible sector protect/unprotect feature.

HTH

  Stamatis

[sampson711]

Good observation! I was hoping that making that adjustment would solve the problem, but I think I am now more confused than before. If the address bus is shifted up by one bit as indicated by the schematic, I would think that the purpose would be so that a 16 bit word would be returned containing the requested byte in either the Most significant byte (A0 = 0) or least significant byte (A0=1). To test this theory, I simply read the flash memory twice at addresses 0xFFE00000 and 0xFFE00001. This did not yied the expected result. To further explain, assume the memory contents are as follows:

Address                  Data

0xFFE00000          0xABCD1234

0xFFE00004          0x5678FEDC

A read issued at 0xFFE00000 will return 0xABCD (as expected)

A read issued at 0xFFE00001 will return 0xCD12 (not as expected, I would have expected 0xABCD since the A0 is not connected to the memory)

Can anyone shed some light on this for me?

[stzari]

This is the corect behaviour.

You have a 16bit databus and are doing 16bit accesses to the flash. The first one is aligned, the second one is misaligned.

The data in your flash are as follows

FlashAddr: 0 - 0xABCD, 1 - 0x1234, 2 - 0x5678, 3 - 0xFEDC (High Byte in D8..15)

This translates to the CF:

CF-Address: 0xFFE00000 - 0xABCD, 0xFFE00002 - 0x1234, 0xFFE00004 - 0x5678, ...

So the first access reads from 0xFFE00000 (Flash: 0) all 16bits: gives 0xABCD.

The second access does 2 reads. First at 0xFFE00000 and takes the lower byte of the data (0xCD) as the high byte of the result and then an access to 0xFFE00002 and takes the high byte of the data (0x12) as the low byte of the result.

See also RM chapters 17.7 and 16.3.1.1

HTH

  Stamatis