How to program MCF5223X Flash on chips

[gxd]

When I erase 9s12NE64 flash(on chip),   I must "Do On Stack". I can not erase flash from flash itself.

I must move this code to RAM and run it from RAM.

but now when  update to MCF52235,  how can i do?  or  can program flash from flash itself ?

ask for help.

//     mcs9s12ne64  erase  flash sector must call DoOnStack().

;*********************************************************************
;* DoOnStack - copy SpSub onto stack and call it (see also SpSub)
;*  De-allocates the stack space used by SpSub after returning from it.
;*  Allows final steps in a flash prog/erase command to execute out
;*  of RAM (on stack) while flash is out of the memory map
;*  This routine can be used for flash word-program or erase commands
;*
;* Calling Convention:
;*           jsr    DoOnStack
;*
;* Uses 32 bytes on stack + 3 bytes if Call instruction used
;********************************************************************
DoOnStack: 
            pshb                 ;save B - PPAGE
                                                    ;

            ldx   #SpSubEnd-2    ;point at last word to move to stack RTC
SpmoveLoop: ldd    2,x-          ;read from flash
            pshd                 ;move onto stack
            cpx   #SpSub-2       ;past end?
            bne    SpmoveLoop    ;loop till whole sub on stack
            tfr    sp,x          ;point to sub on stack
            ldaa  #mFSTAT_CBEIF  ;preload mask to register command
            call   0,x,00        ;execute the sub on the stack
            leas   SpSubEnd-SpSub,sp  ;de-allocate space used by sub
            pulb                 ;restore B
            rtc                  ;to flash where DoOnStack was called
                                 ; assume banked calling function

[gxd]

From install subdir, find some source code.

but  not certain if it can work?

Thank you TOM.

Have any easy way to program flash on chip?

i just to save some parameters byte at Flash.so want erase a sector of Flash or a page of Flash to avoid used i2c eeprom.

Message Edited by gxd on 2007-06-28 07:43 AM

[gxd]

i am puzzle about below  #define

SSD_CONFIG ssdConfig = {
    IPS_BASE_ADDR + CFM_REG_OFFSET,     // Base address of CFM control registers
    CFM_CORE_BUS_BASE,                  // Base address of CFM core bus space
    IPS_BASE_ADDR + CFM_IPS_BUS_OFFSET, // Base address of CFM IPS space
    CFM_BLOCK_SIZE,                     // Size of CFM logic block
    CFM_BLOCK_NUM,                      // Number of CFM logic block
    FALSE,                              // Interrupt mode or polling mode selection flag
    FALSE                               // Debug mode or embedded application mode selection flag
};

 if   #define cpu MCF5223X

CFM_CORE_BUS_BASE= 0x0                            //

CFM_REG_OFFSET= 0x1D0000;

CFM_IPS_BUS_OFFSET=0x1D0000

it is right?

any one can tell me?

[Obetz]

don't waste your time with the SSD drivers. Try to understand how Flash programming works, it's pretty simple!

Oliver

[mccPaul]

Hi

I haven't seen the example source that you have but I may be able to help.

CFM_CORE_BUS_BASE= 0x0

This is the base address of the flash module - your memory map is set up so that FLASHBAR is at 0x00000000.

CFM_REG_OFFSET= 0x1D0000;

This is the offset from IPSBAR to the start of the CFM registers

CFM_IPS_BUS_OFFSET=0x1D0000

This is the same as the one above.

The values appear to match the values in the reference manual so they appear to be correct.

I have attached the code that I wrote for a driver for the mcf5282. It will not be hard to modify this for your CPU but you must do the following:

You will need typedefs for uint8, uint32, etc. For the system header to work, you must have defined __IPSBAR.

Also, you must understand at least a little of the the way that the flash module works - there are TWO busses used to access flash. One uses the normal flash base address of FLASHBAR and there is a backdoor address of FLASHBAR + 0x04000000 see section 17.3.2 in the manual. My code assumes that you have used the backdoor base address.

Paul.

mcf5282_cfm.h

cfm.c

cfm.h

Message Edited by t.dowe on 2009-09-02 05:43 PM

[Obetz]

Hello Paul,

> I have attached the code that I wrote for a driver for the mcf5282.

are you running this code from RAM, from the same "Mass erase block" (logical block) as processed, or from the "other" logical block?

As far as I know, the OP's 5223x has only one logical block. If executed from Flash, your code will still work but not benefit from "pipelined commands".

Besides this, you could increase programming speed by programming two long words (even/odd) with one write command. But since page erase is always slow, it doesn't help very much.

Oliver

[mccPaul]

I run this from RAM (simply because I have loads of RAM).

It will run from flash as you say, and could be improved for a flash implementation by pipelining two writes before starting the first flash command.

Cheers,

Paul.

[gxd]

Paul:

 I down you code, but find it run in FLASH to erase FLASH.

can you definitely to tell me it(code) can run in one page of FLASH to erase another page of FLASH(no used)?

Thanks a lot!

Message Edited by gxd on 2007-06-29 02:52 AM

[Obetz]

Hello "gxd" - whatever your name is,

if you ask for help, you should read the replies!

Paul wrote that _he_ runs the code from RAM, not Flash.

I _confirmed_ that it works from Flash on a MCF5213 and cited the data sheet why it works. I also cited the MCF5282 UM saying that it shouldn't work on this chip (but there can be errors in data sheets, I would try it).

You should now read again this thread and the data sheet of your derivative to check whether it should work for you. Then you should try whether it works really on your derivative. Data sheets have errors...

You have all the necessary information to proceed.

BTW: to make reliable embedded designs, you _need_ a certain degree of knowledge and understanding of the hardware you use. This means: read the data sheet, read it again and again...

Oliver

[mccPaul]

Hi gxd

Just try it!

I cannot confirm this for you - there are subtle differences between the chips and I only have a 5282 development system set up. You should use the examples that you have, and the example I posted along with the Reference Manual to learn how to use the flash.

When you have found out it it works, please post back.

Paul.

[gxd]

Hi,PAUL,

mcf5282 have two logic block flash. so it can be erase a block flash from another. No problem.

mcf52235 only a block flash. so I try some method,one is down the code to RAM as 9S12NE64,but it is very trouble, because I must have a  obj code to copy to RAM.

another is erase and write flash by backdoor address. I find when I writeit used backdoor address, but read it from normal address correctly(if from backdoor address , error result return.). it is good.

NOW two method all  earse and write flash OK.

I test the  driver from MOT SPS, but it can not work right(it is not a sorce code, only binary code,so I can not modified it.

Thank you for your work and help to resolve the problem.

togxd

Message Edited by gxd on 2007-07-16 06:13 AM

[gxd]

if any one used MCF52235 PWM function

below is  a bug:

MCF_GPIO_PTAPAR |=MCF_GPIO_PTAPAR_ICOC3_PWM7;/*------------------ do not work.*/

MCF_GPIO_PTAPAR |=MCF_GPIO_PTAPAR_PTAPAR3(0x03); /* it is OK     */

[Obetz]

Hello Paul,

maybe I was wrong again - I'm not familiar with the MCF5282.

There seems to be a difference between derivatives in Bus arbitration during write commands:

From the MCF5213RM: "After a command has been successfully launched, the CFM signals the core platform to hold off read accesses to any active flash physical block until all active and buffered commands have completed (CCIF=1). A flash write operation from the internal flash bus holds off the Core platform until it is completed."

MCF5282UM: "If a Flash physical block is read during a program or erase operation on that block (CFMUSTAT bit CCIF = 0), the read will return non-valid data and the ACCERR flag will not be set."
Do you know whether the latter is correct, IOW whether the 5282 would indeed crash if a Flash write command is launched from the same logical block?

I have no 5282, but I can confirm that the MCF5213RM is right, IOW it is possible to have the programing routine in the same block.

BTW: the MCF5282UM also doesn't mention the possibility to write to both blocks in one command.

Oliver

[J2MEJediMaster]

Check this forum thread here for some information on Coldfire Flash programming. You might also use the search function at the bottom left of this web page to search the forums for other relevant threads. Also, you'll still have to execute the programming routines from RAM unless the MCU has more than on Flash bank.

---Tom


Message Edited by J2MEJediMaster on 2007-06-27 09:42 AM

[Obetz]

Tom,

did you find any source code at the link you mentioned?

You download an Windows installer :smileyalert: which puts the "Standard Software CFM Driver" binaries (no sources as far as I see) in your programs directory. The contained PDF describes not much more than the reference manual (besides some timing information).

Regarding "have to execute the programming routines from RAM ", read the reference manual: "Bus Arbitration During Write Operations - After a command has been successfully launched, the CFM signals the core platform to hold off read accesses to any active flash physical block until all active and buffered commands have completed (CCIF=1). A flash write operation from the internal flash bus holds off the Core platform until it is completed."

Maybe you can program the Flash memory _faster_ by using a RAM based routine because you can use pipelined programming (don't know whether this works in the CF), but you don't need RAM or a second Flash block (not "bank" ).

Maybe someone can tell me whether all examples use a RAM based Flash programming routine. Did _I_ miss anything, or the others?

Oliver

[Obetz]

amendment: I just checked the different methods to program Flash on a MCF5213 running at 64MHz. Flash clock divider reads 0xD3 => 200kHz Flash clock.

Executed from RAM, buffered write (next write as soon as CBEIF is clear) of four (long) words took 157us (39us/longword). Waiting for CCIF after each write took 186us (47us/longword) regardless whether I executed the code from RAM or from Flash memory.

So if you can afford slightly longer programming times, you don't need to copy parts of your program to RAM.

I'm still curious why the samples from the 5213 eval board (IIRC DBUG sources) use a RAM routine.

Oliver

[Obetz]

sorry, the data above is incomplete and partially wrong.

Writing in "burst programming" mode (next command when CBEIF is set, don't wait for CCIF) takes 20us for each two long words if they are in even and odd blocks (you can write an even and an odd longword before executing the write command).

Waiting for CCIF (or executing from the affected Flash block pair) takes 47us for each two long words.

BTW: that's exactly the same timing as in the 9S12 (although the 9S12 writes 16 bits at once, and the 5213 writes 64 bits at once). The 9S12 documentation has much more details about Flash programming.

So there is a noticeable decrease in programming speed when running from Flash memory, but the page erase time is still longer than the slow programming (20ms vs. 5ms or 12ms).

Oliver