ColdFire/68K Microcontrollers and ProcessorsのトピックRe: Incircuit FLASH programming - M5223X

Incircuit FLASH programming - M5223X

mjbcswitzerland — Fri, 12 May 2006 06:40:08 GMT

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

Re: Incircuit FLASH programming - M5223X

mjbcswitzerland — Fri, 12 May 2006 23:13:06 GMT

Hi. Is there any one out there???

I'm in big trouble with the FLASH programming and today made no progress. There must be a very simple answer but I haven't been able to find it as of yet.

1. I loaded an assember routine to the EVB so that I could get dBUG to dump me the contents of the CFM after I had commanded it to erase a page of memory:
All registers were all 0x0 apart from
CFMCLKD = 0xcf (the same value as I was setting)
CFMUSTAT = 0xc0 (infoming ready and no errors)
CFMCMD = 0x40 (the last page erase command)

So no help here since the contents are the same I have.

2. I studied the data sheet in great detail. The following point is really confusing me since it represents a simple test of life which is not reacting as expected.

In the section 17.4.2.3.5 there is a list of actions which result in an error, which sets the ACCERR flag.

The simplest test of such an error is point 1 "Writing to the FLASH memory before initializing CFMCLKD".

After a reset CFMCLKD is 0x00 since it has not been initialised so all one has to do is write a long word to an address in memory and the error has taken place and the bit will be set.

When I write to FLASH there is no reaction...

3. I then concluded that the write to FLASH must be failing otherwise it would surely cause the described error. I believe this now to be the case because it seems as though when the write is attempted there is immediately an interrupt (handled by the default handler and almost invisible) - I assume due to illegal access. The write probably never actually takes place and so the FLASH command sequence never actually begins. So my hunt turns to the FLASH access itself. Using the CodeWarrior and P&E Coldfire Multiling BDM I could evaluate that the Write protect bit is always set in FLASHBAR and I don't find a way of removing it - I can program it as I like but the bit stays at '1', which is possibly the root cause of the problem.

I find no explanation of the FLASHBAR register being nitialised with writes protected (a reset value of 0000_0000 is given in the data sheet) which doesn't tie up with the value I see with the debugger.

Status:

I believe that the FLASH programming is not working because the FLASH is protected against write instructions but I can not explain whether the protection is normal or not in my system and how to remove it. How can the dBUG erase FLASH?

Basically a bad day. Please, please someone put me out of my missery......

Regards

Mark

Re: Incircuit FLASH programming - M5223X

nanoGeek — Fri, 12 May 2006 23:55:04 GMT

I can't help with the flash issue, but I have had some experience with dbug.

The "mm" (memory read/modify) and "md" (memory display) use a "." convention to specify the size you desire:

mm.b = byte, mm.w = word, mm.l = long. mm with no dot defaults to word (I think, I've since changed this on my dbug so that it defualts to byte).

cheers,

Joe

Re: Incircuit FLASH programming - M5223X

mjbcswitzerland — Sat, 13 May 2006 01:10:56 GMT

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

Re: Incircuit FLASH programming - M5223X

nanoGeek — Sat, 13 May 2006 02:02:16 GMT

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

Re: Incircuit FLASH programming - M5223X

mjbcswitzerland — Sat, 13 May 2006 02:27:18 GMT

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

Re: Incircuit FLASH programming - M5223X

JeffB — Mon, 15 May 2006 07:03:46 GMT

Mark,

Did you get your problem resolved?

I have run into the same brick wall. I have sent an e-mail to the Freescale application engineer but have not yet received a reply.

Thanks.

Re: Incircuit FLASH programming - M5223X

mjbcswitzerland — Mon, 15 May 2006 17:04:56 GMT

Hi Jeff

Yes, thankfully.

You mustn't write to the FLASH directly but to the CFM FLASH (this is sort of a copy of FLASH at ISPBASE + 0x4000000). EG: If you want to program the address 0x10000 in FLASH (FLASHBAR set up to start at 0x00000000) then you write the value to 4410000 (ISPBASE + CFM FLASH + FLASH offset). Then it works.

Therefore the FLASH itself is protected against writes (it generates an access error). The FLASHBAR seems to default to 0x00000100 and not 0 as in all documents and this bit can not be cleared, which is OK since it is not necessary to write to it.

There seems to be other protections against writing to the CFM FLASH and I couldn't get the sequence working by writing manually via the BDM (presumably this is possible if the access rights are set up correctly but I didn't experiment very long). The core itself has access rights by default and the code sequence works fine when the processor is running.

I put my project online - see the following post:

http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&message.id=274

I luckily found the tip in a BDM manufacturer's documentation about the CFM FLASH. I still don't see where it is described in the Coldfire datasheet!! Once you know it is obvious, but I lost 2 days looking and experimenting.

If you don't like too far away you can buy me a beer for the tip!!

Don't forget to check out the uTasker (also in other post) which now includes a read-to-run Coldfire project with FLASH file system.

Regards

Mark
www.mjbc.ch

Re: Incircuit FLASH programming - M5223X

JeffB — Mon, 15 May 2006 20:38:21 GMT

Mark,

That did it!. Thank you so much for your help.

You did leave off one zero, the write location for 0x00010000 would be

0x44010000.

If you are ever in the middle of the United States, I'll buy you that beer.

Jeff

Re: Incircuit FLASH programming - M5223X

mjbcswitzerland — Mon, 15 May 2006 21:43:43 GMT

Hi Jeff

Sorry about the zero (I do get a bit dizzy looking a these long numbers!!).

Glad it helped. Send me an air ticket from Zurich, Switzerland and I'll be over - just keep the beer cold until then.....

Cheers

Mark

Re: Incircuit FLASH programming - M5223X

p_vagnoni — Mon, 11 Sep 2006 17:38:37 GMT

Hello Mark,

I read your mail about the flash program and it will help me because I am not able to program the flash on the CFM52235. I would use a part of them (maybe only one block of 8 Kb) as EEPROM to record parameters. I try to make a simple program that make it but when I try to write in the CFM register I have no results. Can you help me in this way?

Thank you,

Paolo

PS: If you come in Rome you will have a lot of beer, or if you prefer we have a good wine!

Re: Incircuit FLASH programming - M5223X

mjbcswitzerland — Mon, 11 Sep 2006 18:35:51 GMT

Hi Paolo

First a few things to know about the FLASH in the M5223X:

1. It must be written as long words.
2. It must first be deleted (to 0xffffffff) before programming. It is necessary to delete it as sector.
3. A sector is 2kb in size in the M5223X (this is not that obvious from the data sheet), meaning that it is the smallest block of memory that can be deleted at a time. I think that it is often refered to as the GRANULARITY.
4. It IS possible to cumulatively program the bits in a long word to '0', which make it easier to use that FLASH which doesn't support this (eg. the HCS12 FLASH).
5. When deleting or writing, the whole of the FLASH no longer accessible. This means that the code must run from RAM during this time and interrupts best disabled (if their service routines are not also in RAM).
6. When actually writing to the FLASH one doesn't write to the FLASH address but to CFM_FLASH (this is a sort of copy of the FLASH buffer at a certain offset from the FLASH address range). This is not described very well in the data sheet and many people (including myself) do get rather stuck until somehow working it out or finding the tip somewhere (eg. in this thread).

So here comes some code, which works well (it is from the uTasker project, where it is used as FLASH interface for the file system and parameter routines). I haven't included any code which controls higher level stuff but it is all available in the uTasker project for the M5223X - see the following posting for more info, linsk and on-line demos:
http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&message.id=274
and the uTasker web site. (www.uTasker.com) It is free for educational and non-commerical work, including email support, and there is an application form on the web site if you would like to evaluate the complete code including a unique M5223X simulator).
The parameter management controls a dual-parameter buffer allowing temporary parameter changes and old parameter rescue. Its size can be configured (min. 4k in the M5223X since it works with at least 2 FLASH sectors).

Unfortunately Rome is a bit far but I will be in Milano on Sunday and will certainly be tasting some good Italian wine while there.

Send an application for the uTasker since you are (as are others) more than welcome to join the uTasker user's community. We can catch up on the drink later once you have got your complete project up and running!!

Regards

Mark
www.mjbc.ch / www.uTasker.com

============================================================
Code:

static void fnConfigFlash(void){CFMUSTAT = (ACCERR | PVIOL); // clear error flagsif (CFMCLKD & DIVLD) return; // already configured// before erasing or writing FLASH, the clock must be configured correctly// we want to be in the 150kHz..200kHz range but as fast as possible// This works for oscillator clocks greater than 12.8MhzCFMCLKD = (PRDIV8 | (unsigned char)((OSCCLK/200000/8))); // warning - If in doubt, best check that it is in range before using - errors can destroy FLASH!!!}// This runs from RAM (on the stack) and should normally be protected against interrupts//static void fnFlashRoutine(void){CFMUSTAT = CBEIF; // launch commandwhile (!(CFMUSTAT & CBEIF)) {} // wait until buffer freewhile (!(CFMUSTAT & CCIF)) {} // wait until execution complete}static int fnFlashNow(unsigned char ucCommand, unsigned long *ptrWord, unsigned long ulWord){unsigned char ucProgSpace[PROG_SIZE];unsigned char *ptrProg = (unsigned char*)fnFlashRoutine;void (*fnRAM_code)(void) = (void(*)(void))ucProgSpace;int i = 0;while (i PROG_SIZE) { // copy program to stackucProgSpace[i++] = *ptrProg++;}uDisable_Interrupt(); // protect this region from interruptsptrWord += (CFM_FLASH/sizeof(unsigned long)); // position the write into CFM FLASH (a copy of real FLASH for commands)*ptrWord = ulWord; // value not important for deletesCFMCMD = ucCommand; // The commandfnRAM_code(); // execute from RAM [stack]__enable_interrupt(); // safe to accept interrupts againreturn (CFMUSTAT & (ACCERR | PVIOL)); // if there was an error this will be non-zero}// The address must be on a word boundary or it will fail//static int fnWriteLongWordFlash(unsigned long *ptrAdd, unsigned long ulValue){fnConfigFlash();if (!(CFMUSTAT & CBEIF)) return 1; // the command buffers are full - we can not program yetreturn (fnFlashNow(CMD_PROGRAMM_WORD, ptrAdd, ulValue));}// Erase a FLASH sector. The pointer can be anywhere in the sector to be erased//int fnEraseFlash(unsigned char *ptrSector){fnConfigFlash(); // ensure that the FLASH is configuredif (!(CFMUSTAT & CBEIF)) return 1; // the command buffers are full - we can not proceedreturn (fnFlashNow(CMD_SECTOR_ERASE, (unsigned long *)((unsigned long)ptrSector & ~0x3), (unsigned long)0)); // ensure long word address}

(Alban formatted code + links)

Message Edited by Alban on 2006-09-11 12:47 PM

Re: Incircuit FLASH programming - M5223X

p_vagnoni — Mon, 11 Sep 2006 20:21:30 GMT

Hi Mark,

Thanks for reply. I have only something that is no clear:

you say that when I write in FLASH the routine must run from RAM because the FLASH is no longer accessible, but in the manual it seems that only the sector that i delete/write is no accessible, so if my FLASH routines are in a sector X I can rewrite anyone sector different from X (and so without disable the interrupts as I need).

It is another error on the manual or depends only to make the routine abvle to rewrite all sector of FLASH?

Thanks a lot!

Re: Incircuit FLASH programming - M5223X

p_vagnoni — Mon, 11 Sep 2006 20:25:39 GMT

ooops I forget this:

in your code part maybe you forgot the "<" sign in the while instruction:

...

while(i < PROG_SIZE) { // copy program to stack

ucProgSpace[i++] = *ptrProg++;

}

...

and PROG_SIZE is the size of fnFlashRoutine if I understand, correct?

Best Regards

Re: Incircuit FLASH programming - M5223X

mjbcswitzerland — Mon, 11 Sep 2006 21:06:43 GMT

Paolo

In the data sheet it states:
"It is not possible to read from any FLASH logical block is being erased, programmed, or verified.
FLASH logical blocks are divided into multiple logical pages that can be erased separately."
If you study figure 17-1 you will see that a logical blocks can also be even block arrays and odd block arrays.

My understanding is that the whole FLASH in the chip has to be considered a logical block, divided into logical pages (sectors), which can be deleted separately.

Therefore which ever logical page is being writen, erased or verified, it is in the same unique logical block. This means that it is not possible to write in one sector and still run code from another - all sectors are in the same logical block.

I have also never seen any code trying to do this. It is also a normal stated restriction that code can not run when writing so I am quite sure that it must be perfomred this way.

The missing (small than sign) is due to the code giving invalid HTML and was deleted when copying the code to the forum. Good you saw it - I did get a message that something had been modified but didn't see what. [Perhaps a moderator can edit the post to put it back in?]

Good luck.

Regards

Mark

Re: Incircuit FLASH programming - M5223X

mjbcswitzerland — Mon, 11 Sep 2006 21:10:08 GMT

Paolo

Yes

#define PROG_SIZE 80

It is the size of the routine to be run from RAM. It is also possible to calculate the size from the address of the routine and the address of the following routine. But I simply made it large and looked at the assembler size in the debugger - it is also generous in case a different compiler were to be a little less efficient...

Regards

Mark

Re: Incircuit FLASH programming - M5223X

p_vagnoni — Mon, 11 Sep 2006 21:58:02 GMT

Hi Mark,

About the memory I read on the Reference Manual of 52235 (overview of chapter 17)

"It is not possible to read from any Flash logical block while the same logical block is being erased,

programmed, or verified. Flash logical blocks are divided into multiple logical pages that can be erased

separately. "

So it seems that you can work on a logical block different from the code block. I think that is not clear because in the manual there are more terms as Logical block, sector, page.

As I wrote in the manual indicates every block as 8Kbyte large: you can protect this sector by the CFMPROT register and i suppose (it is not indicate) that 8Kbyte is the smallest part of Flash that I can delete (you wrote me that is 2 Kbyte, where do you read it?).

So if I understand (I hope!!!) in 52235 we have:

256 Kbytes (x 32 bit) of FLASH divided into 32 logical sector (the smallest part of memory that I can protect);

Every sector is divided into logical page of 2Kb (as you wrote the smallest part of memory that I can erase).

what do you think?

Re: Incircuit FLASH programming - M5223X

mjbcswitzerland — Mon, 11 Sep 2006 22:32:47 GMT

Paolo

The manual says that there are 32 x 8k logical sectors for PROTECTION. I haven't actually used protection but assume that this is correct.

I also ORIGINALLY understood that the smallest block which could be deleted would be this and I don't think that there is any more detail in the manual to suggest different.

If you use the CF Flasher you will see that it allows 16 sectors to be erased - this would suggest 16k size. But if you try using the FLASH programmer in the CodeWarrior you will find that the delete command allows you to really specify individual sectors to be deleted, of 0x800 (2k).

I can't remember how, but sometime I did realise that the size is really 2k. So trust me - it does work like that.

Regards

Mark

Re: Incircuit FLASH programming - M5223X

alexod — Tue, 05 Jun 2007 11:52:14 GMT

Guys - my heroes.

I've spent 4-5 hours trawling the web, and the MCF5213RM for this answer. They say to write the address and data, but they don't make a big fuss about using the offset to the CFM image of the flash.

I just want to drive back to the office now and try it out.

Thanks.

Alex

Re: Incircuit FLASH programming - M5223X

mjbcswitzerland — Tue, 05 Jun 2007 19:44:55 GMT

Alex

I have also programmed the 5213 with the same code - FLASH is the same - so you should find it works.

One small tip about interrupts. As you probably know, the FLASH can not be accessed to run code when it is being programmed. Therefore the code runs out of RAM during this period. Assuming that all interrupts are not also operating in RAM it is necessary to disable interrupts to avoid them trying to access FLASH and causing an exception.

Be ware that any interrupts set with priority level 7 are equivalent to NMIs and so will not be blocked. Therefore ensure than no interrupts in the system have a priority of greater than 6 (except maybe for the watchdog interrupt) otherwise they may lead to an unexpected crash.

Regards

Mark