privelege violation when attempting to erase a flash block

[tomdininio]

I have an application written in C (new to me) in CodeWarrior. The processor is MCF51QE128.  I am familiar with assembly language in the old MC6809 (8 bit) processors.

The troublesome code is:

    FSTAT=(byte)(0x30);

    asm {

      move.l D0,0x1f000;       // Dummy address writeVarA_Flash

    }//End of asm

    FCMD=(byte)(0x40); // Sector Erase Command (4000 cycles 0f 5 microsec period = 20,000 microsec.

    FSTAT=(byte)(0x80); // Start the command

In the .lcf file I have changed the permissions as

    MEMORY {

       code (RWX) : ORIGIN = 0x00000410, LENGTH = 0x0001DBF0

     userram     (RWX) : ORIGIN = 0x00800000, LENGTH = 0x00002000

     userrom     (RWX) : ORIGIN = 0x0001E000, LENGTH = 0x00000002

    }

The code causes a "Protection Violation" flag to appear in the FSTAT register (observed in DeBug) and the program goes into lala land.

The Security is turned off. Is the userrom section still considered as a "protected" area of flash? I need to store volatile integers during power outages.

What am I missing?

[TomE]

> I have an application written in C (new to me)

It shows. Get rid of that assembly. It is completely unnecessary.

Do something like the following instead:

unsigned char *p = (unsigned char *)0x1f000;

*p = 0;

FSTAT is telling you you're violating the privs. Read and print the FPROT register to find out what it is set to. The value it is set to is read from another Flash location on Reset. That is set by something CW is doing, but as I don't use CW and I don't use that chip I can't tell you how to fix it.

I can't see you setting up the FCDIV, FOPT and FCNFG registers. Are you setting them up properly?

Tom

[TomE]

I wrote:

unsigned char *p = (unsigned char *)0x1f000;

*p = 0;

Can you spot the bug I accidentally put in that?

Read through "Table 4-1. CPU Access Type Allowed by Region", and not it says only 32-bit writes are permitted to FLASH. So to fix that:

unsigned long *p = (unsigned long *)0x1f000;

*p = 0;

There's another likely problem. From the Reference Manual:

4.4 Flash

It is not possible to read from a flash block while any command is executing on

that specific flash block.

That means the CPU can't RUN code from a Flash Block while it is erasing or programming.

So where is your code running from? It can't be running from the Flash. The standard way to handle this (that works on all devices) is to write a small block of code that handles the erasing and programming, and then you (in your code) manually copy that block of code to RAM. These functions are called from your code in Flash to do the erase and programming. This also means that all interrupts have to be disabled or you'd get interrupted back into Flash code. This is murder (or impossible) on embedded devices that must respond to external events.

If you're so new to C that you use ASM to write to an address then you probably don't know the tricks for copying functions to RAM and running them from there. I may be wrong of course and you may be doing this already. Are you?

Another way to handle this is to always run all your code from RAM and to treat the Flash as a file system. This only works if you have a lot of (usually external) RAM on the CPU. You don't. Another way is to manipulate the Cache Controller to "preload and lock" the flash programming functions into the Cache. The V1 Coldfire core doesn't have a cache.

Some chips have two Flash controllers so you can be reading code from one block of Flash while changing the other one. This chip isn't one of those. Some Flash controllers can "dead stall" the CPU while they're busy. There's nothing in the manual to say this is one of those, so it probably isn't..

> The code causes a "Protection Violation" flag to appear in the FSTAT register (observed in DeBug)

Possibly because you violated the command timing by READING from the Flash (with the instruction fetch) after telling it to erase. I'd expect a FACCERR in this case, but you're doing something so illegal that anything could happen.

> and the program goes into lala land.

Because it is reading garbage from the locked-out Flash controller and trying to execute it. Then it tries to trap, tries to read the vector from the locked-out flash, gets garbage, jumps to "random" and you get the idea.

> In the .lcf file I have changed the permissions

Does that have any effect on the FPROT register? If it does that's something the development environment might have to handle for you, and I'm guessing it doesn't. I'd guess the LCF permissions only affect what memory has what permissions to the compiler, and what it will let you access in C code.

If you search this forum for the right combination of keywords you'll probably find where this question has been addressed before. Yes, search for "eeprom emulation" (include the quotes). That's what you need.

Another thing to look for. Flash wears out. If your code updates variable too often you may wear it out. The limit is given at 100,000 erases, but if your device is meant to last for 10 years that's only one update per hour! What you really want is mentioned in the manual as "EEPROM emulation applications". That's where you emulate a word-writable EEPROM by writing "update blocks" into a Flash sector and only erase it when it is full of updates. See if you can find anything like that. It would make the part a lot easier to get running if Freescale provided an App Note with working code showing how to do this, but I haven't been able to find one.

Tom

[tomdininio]

how do i store volatile int in flash without gettingviolation error interrupt? MCF51QE128 processor I have anapplication written in C (new to me) in CodeWarrior. The processor isMCF51QE128.  I am familiar with assembly language in the old MC6809 (8 bit)processors.The troublesomecode is:  FSTAT=(byte)(0x30);asm {  move.l  D0,0x1f000;       // Dummy address writeVarA_Flash}//End of asmFCMD=(byte)(0x40);        // Sector Erase Command (4000 cycles 0f 5 microsecperiod = 20,000 microsec.FSTAT=(byte)(0x80);       // Start the command   In the .lcf file Ihave changed the permissions asMEMORY {   code       (RWX) : ORIGIN = 0x00000410, LENGTH = 0x0001DBF0  userram     (RWX) : ORIGIN = 0x00800000, LENGTH = 0x00002000  userrom     (RWX) : ORIGIN = 0x0001E000, LENGTH = 0x00000002}  The code causes a"Protection Violation" flag to appear in the FSTAT register (observedin DeBug) and the program goes into lala land.The Security isturned off. Is the userrom section still considered as a "protected"area of flash? I need to store volatile integers during power outages.What am I missing?

Reply to TomE Using the P&E Multilink / Cyclone Pro connected to asingle wire (6 pin ribbon cable header) on our board, the following readingswere taken. FCDIV = 1001_0011 The register has been written in startup code. Theclock frequency is 8Mhz oscillator giving a 4MHz bus_clock. FCLK =(4000KHz)/(119) = 200KHz as requested. FPROT = 1000_0111 Bit 0 set indicates bits 7-1 determine size ofprotected area.Bits 7-1 are 0x43 which from Table 4-13 protects 0x0_0000–0x1_DFFF.I am tryingto clear location (block) 0x1_F000 that should be unprotected. FOPT = 0100_0011 Backdoor Key security is disabled.Flash is unsecured. Is this possibly the problem? FCNFG = 0000_0000Writes to the flash block areinterpreted as the “start of a command write sequence”, not as keys to open thebackdoor. You didn’t ask, butthe S bit in SR is set. It is the supervisor mode. The assembly you suggested I get rid of came from the flowchart (Figure 4-13) of “MCF51QE128 RM rev. 3.1.pdf” Using your suggested code, I replaced “char” with “int”because flash wants an aligned long word when addressed. The code compiles as:movea.l    #1f000,A0;clr.l          (A0); The code does not contain write FCMD = 0x40; or FSTAT =0x80; as the algorithm (Fig 4-13 of Ref Man) dictates. Also, FSTAT = 1100_0000before the execution of clr (A0) and FSTAT = 1101_0000 after the single step.The 1 in bit 4 is reporting (Access Error). The code does not causethe processor to halt (fault on fault?), but the sector is not erased. TrTrial 1Set *p = 0x20000000; to force a move command into the objectcode. It compiled as move.l #0x20000000, (A0). Nothing erased. Same access error in FSTAT. No changein the 5 registers above.  TrTrial 2Changed the code to      unsigned int *p= (unsigned int ) 0x1f000;       temp=p;    FSTAT=(byte)(0x30);     *p =0x20000000;            // Write dummydata to address in block     FCMD=(byte)(0x40);      // Sector Erase Command (4000 cycles 0f 5microsec                                                 period = 20,000microsec.    FSTAT=(byte)(0x80);     // Startthe command     RecordStep=3;    if((signed)(FSTAT)<0) test1=FSTAT;     else test2=(byte)(FSTAT1);     Breakpoint  ROM is already erased on the first attempt to store informationafter BDM load. The store algorithm works. When I try to erase prior to storing 2nd set of information, the problem occurs. "temp” is a global variable andretains the prior write information (=0x43b4_0000 in this case) prior to the programcrashing. At the breakpoint, FSTAT = (test1)  = 1110_0000. “test2” is never written and remains clear. Bit 5[FPVIOL] showed a privilege violation error. The sector had failed to erase asconfirmed by Bit 7 and had failed to launch. At least the program is not causing afault on fault halt. When I remove the Breakpoint, the program goes into haltshowing “ILLEGAL_BP” and PC=0xB51050. HOWEVER, the sector of flash is erased(?????) After the BDM reset command is issued, 0x1f000 = ffff_ffff while itequaled 0x43b4_0000 prior to the erase attempt as proven by (temp). I think I need to figure a way to see if there’s a stackoverflow or empty branch address read by an interrupt. R response to second email1)     I already spotted the bug in your first reply and used "int" instead of "long".2)     My code (in trial 2 above is at PC = 0000_1CF4.  I am trying toerase the 1k block starting at 0001_F000. These addresses are on opposite endsof the FLASH. I don’t think this is the problem.3)     You are correct about the change in .lcf file not affectingFPROT.4)     You are correct that I don’t know the tricks in C to move thecode from ROM to RAM. Based on comment 2) above, I don’t think this is theproblem, but I had planned (but not yet done) to affect a transfer of code toRAM using brute force ASM. I’ll report the results when I’ve done it.5)     Regarding comment 3, I want to continue the interrupt drivenpart of the program in ROM during the 20,000-microsecond erase cycle. For now,I’ll set the interrupt mask to level 7 before branching to RAM. The highestinterrupt I use is level 6. This should do it for the testing purposes.6)     The code starts at 0000_0410 and ends at 0000_5473. That’s toolong for the 2k of RAM available. 7)     The chip is a few years old, but I have only lately beentrying to get this segment of code debugged. There are only 1-2 erase cycleseach time the code is reassembled then the chip is mass erased and a newprogram loaded. This is not worn out Flash. When the customer is using thechip, I estimate 2-3 erase/write cycles per day.8)     Right now my plans are to a)     Try moving the “erase block” code to RAM as a subroutineb)    Look thru the interrupt vector table to try to get a cluewhere the PC may be goingc)     Search for eeprom emulation algorithms. I’ll try to inform you of progress (or lack there of) in afew days. Thanx for the direction so far.

#yiv9809144564 * #yiv9809144564 a #yiv9809144564 body {font-family:Helvetica, Arial, sans-serif;}#yiv9809144564 h1, #yiv9809144564 h2, #yiv9809144564 h3, #yiv9809144564 h4, #yiv9809144564 h5, #yiv9809144564 h6, #yiv9809144564 p, #yiv9809144564 hr {}#yiv9809144564 .yiv9809144564button td {}

|

NXP Community

|

privelege violation when attempting to erase a flash block

reply from Tom Evans in ColdFire/68K Microcontrollers and Processors - View the full discussionI wrote: unsigned char *p = (unsigned char *)0x1f000; *p = 0; Can you spot the bug in that?Read through "Table 4-1. CPU Access Type Allowed by Region", and not it says only 32-bit writes are permitted to FLASH. Sp: unsigned long *p = (unsigned long *)0x1f000; *p = 0; There's another possible problem: 4.4 FlashIt is not possible to read from a flash block while any command is executing onthat specific flash block. That means the CPU can't RUN code from a Flash Block while it is erasing or programming. So where is your code running from? It can't be running from the Flash. The standard way to handle this (that works on all devices) is to write a small block of code that handles the erasing and programming, and is copied to RAM. These functions are called from your code in Flash to do the erase and programming. This also means that all interrupts have to be disabled or you'd get interrupted back into Flash code. This is murder (or impossible) on embedded devices that must respond to external events. If you're so new to C that you use ASM to write to an address then you probably don't know the tricks for copying functions to RAM and running them from there. I may be wrong of course. Another way to handle this is to always run all your code from RAM and to treat the Flash as a file system. This only works ir you have a lot of (usually external) RAM on the CPU. Another way is to manipulate the Cache Controller to "preload and lock" the flash programming functions into the Cache. The V1 Coldfire core doesn't have a cache. Some chips have two Flash controllers so you can be reading code from one block of Flash while changing the other one. This chip isn't one of those. Some Flash controllers can "dead stall" the CPU while they're busy. There's nothing in the manual to say this is one of those, so it probably isn't.. > The code causes a "Protection Violation" flag to appear in the FSTAT register (observed in DeBug)Possibly because you violated the command timing by READING from the Flash (with the instruction fetch) after telling it to erase. I'd expect a FACCERR in this case, but you're doing something so illegal that anything could happen. > and the program goes into lala land. Because it is reading garbage from the locked-out Flash controller. > In the .lcf file I have changed the permissions Does that have any effect on the FPROT register? If it does that's something the development environment might have to handle for you, and I'm guessing it doesn't. I'd guess the LCF permissions only affect what memory has what permissions to the compiler, and what it will let you access in C code. If you search this forum for the right combination of keywords you'll probably find where this question has been addressed before. Yes, search for "eeprom emulations" (include the quotes). That's what you need. Another thing to look for. Flash wears out. If your code updates variable too often you may wear it out. The limit is given at 100,000 erases, but if your device is meant to last for 10 years that's only one update per hour! What you really want is mentioned in the manual as "EEPROM emulation applications". That's where you emulate a word-writable EEPROM by writing "update blocks" into a Flash sector and only erase it when it is full of updates. See if you can find anything like that. It would make the part a lot easier to get running if Freescale provided an App Note with working code showing how to do this, but I haven't been able to find one. Tom  

Reply to this message by replying to this email, or go to the message on NXP Community

Start a new discussion in ColdFire/68K Microcontrollers and Processors by email or at NXP Community

Following privelege violation when attempting to erase a flash block in these streams: Inbox

This email was sent by NXP Community because you are a registered user.

You may unsubscribe instantly from NXP Community, or adjust email frequency in your email preferences |

|

[TomE]

I can't read that mess. Click on "Action - Edit" and then reformat it, or preferably, delete the lot and start again.

This site has a fairly terrible user interface, you just have to work around it and be very careful with formatting, cutting and pasting. It doesn't handle that at all well.

Tom