Incircuit FLASH programming - M5223X

[mjbcswitzerland]

Hi

I am having a bad time trying to program the FLASH on the M52235EVB from the application!!!!!!!

I am moving from the MC9S12NE64 which is almost identical and so I expected the code to work with a few small modifications.

Before letting the code run, I walked through with the BDM and tried the command manually. This is the sequence (which is indeed very simple and works fine on the NE64 using BDM - register names are the only modification).

1. Set CFMCLKD to 0x4f - it reads back 0xcf showing that it has been written to.
2. Write a long word to a FLASH location - say 0x20000
3. Write the command in CFMCMD - say 20 to program a long word
4. Write 0x80 to CFMUSTAT (to start the command - writing the '1' resets CBEIF).
I read back immediatly 0xc0 - indicating ready for command and no errors.

The problem is that it doesn't program, erase or do anything (with various commands attempted). Also when I intentionally do comething incorrectly, or cancel by writing 0x00 to CFMUSTAT there are never error error bits set as would be expected.

My only explanation is that there is some additional initialisation required which I have not yet found as my impression is that the commands are presently being totally ignored.

The result is the same whether I step through code performing this sequence or when I write the bytes manually using the BDM.

I then tried with the dBUG in the EVB. Using the inbuilt flash commands I managed to erase a block so the device is fine. I wanted to see how it had left the registers but this was not possible since I couldn't get a memory read of the registers to work - the reason being that reads default to half word reads, which cause a bus error in this peripheral area. When I tried a byte read (md b 401d0002, according to the documentation) it just gave me a memory dump from address 0 (like a serial upload because it never stopped and I had to reset the board), suggesting also a problem with the dBUG on the new EVB.

So I have a few questions:

- When setting CFMCLKD is the value correct for a 25MHz quarz and 60MHz PLL operation. I am not sure which clock is actually used for the calculation and so am using the faster to avoid destroying something if wrong - I would have loved to see what the dBUG programs but I just can't read the register - it is very frustrating....

- Does anyone know what is missing in the above sequence which is causing it not to work?

- After studying the data sheet I was convinced that the granuality of the FLASH is 8k (the smallest block which can be individually erased) but dBUG told me it is 2k and it really is so from the test results. I think that this point is missing in the data sheet.

By the way, I saw previous FLASH programming questions and looked at the dBUG code for the 5213 but the programing routine is defined as an array of constant data (I assume assembler code to be copied to RAM) so I didn't learn much there. 

I would be very grateful if someone could help since this is a very annoying problem, especially as I never had any trouble programming the HCS FLASH, which seems to be basically identical....

Regards

Mark Butcher
www.mjbc.ch

[mjbcswitzerland]

Hi Joe

That has helped since it gives me some more possibilities of comparing. In the dBUG instructions I read about the b,w,l but just couldn't work out the syntax since they are not mentioned in the help and the dot before them in the instructions looks like a bullet sign in a list so I never though about trying it in.

What I have learned is that the dBUG is intelligent when writing to FLASH locations. It programs changes (mm) in a word automatically as long as it can do this be programming bits to '0'.

This shows that the FLASH device supports programming individual bits in words to '0' which I find quite handly (several FLASH based devices only allow one write to a group which makes them somewhat tricky for some applications).

The fact that the dBUG does intelligent memory modifications doesn't allow the in-circuit FLASH sequences to be tested. So I still have to find out the solution using another method.

Do you know how the FLASHBAR register can be read with the dBUG?

I just found the "irmd" command which allows the registers in a peripheral block to be displayed - the contents CFM confirm my previous findings.

Since I am not getting anywhere using a BDM I will try to use the dBUG to debug a test program to see whether there is a difference with it.

Thanks

Mark

[nanoGeek]

The "BAR" registers (FLASHBAR, MBAR, RAMBAR, etc...) can't be read from the CPU so that means that dbug can't read them.  They are only readable from the BDM port.  Also, dbug can't write those registers unless it is modified since they are only accessed via the movec instruction (dbug does write to these registers during intial run from reset, but it doesn't have any commands that I have seen that allow you to write any value after the fact).  "irmd" only appears to operate on the "visible" peripheral and control registers (the same ones you can also get to via "mm").

I had a lot of difficulty getting my board's external flash to work from CW, but that was because we are using a newer flash device.  I would expect the internal flash to be better supported by CW.  BTW, are you using the latest CW (I think it is 6.2)?  Upgrading from 6.1 is one of the things that helped me.

Good luck,

Joe

[mjbcswitzerland]

Joe

I have CW6.3!! Only installed it a few days ago. Have got my operating system running, the EMAC + EPHY operate and I can ping the board. The ftp and web server code is loaded but I have to get the FLASH programming running so that FTP server can use the internal file system to upload the web pages.

I could modify RAMBAR and FLASHBAR using the BDM but couldn't get rid of the write protect bit in FLASHBAR (although it is only an idea that it may be the real cause of my problems).

I just modified the project slightly so that I can load it to the board using dBUG. It runs and I get exactly the same phenomena - when the code tries to perform the flash programming sequence, the write to the FLASH address results in an access error (I can catch the interrupt). This means that it certainly has nothing to do with CW and the BDM.

dBUG, which is starting my code, can delete and program the FLASH. I conclude that there is still an initialisation which is missing somewhere. I have programmed the FLASH on the HCS12, using identical sequences and so was expecting the porting of the file system to be a piece of cake. But it seems as though the code is not even getting past the first write to FLASH to kick off the command sequence.

I took half a day to get the new EMAC driver running but have required nearly 2 days to get a three write FLASH programming instruction to work (and still counting). It is becoming a nightmare....I just can't find any references to having to prepare anything before starting the write.

My last resort will be to reverse engineer the assembler code in the dBUG routines (which are made of data constant arrays to be run from RAM - with no assembler source). It must be doing something which I haven't thought of yet.

Bang goes my weekend....

Cheers

Mark

Message Edited by mjbcswitzerland on 05-12-200602:30 PM