Programming Trim Byte in Flash from RAM using IntFlash Bean

[PatrickW]

Hi,

I'm trying to program a trim/calibration byte into non-voltatile flash, to survive loss of power.  The Flash programming sequence is fairly complex, and the code executing it must be run from RAM.  I've never programmed in assembly before, and after multiple failed attempts to home-brew code for this using various application notes, I forked over the money for the IntFlash bean for CodeWarrior, which ostensibly provides a simple function for programming a byte to flash (SetByteFlash).  

Unfortunately, when theSetByteFlash function executes, my code stops.  Stepping through the program, I see that at a consistent point in the programming sequence, there is a "Cpu_Interrupt" triggered (the ISR contains no code, so it just stalls).  If I use set the simple "Write" mode in the IntFlash bean, this Cpu_Interrupt is triggered upon execution of this assembly line in RTSHC08.h:

JSR    ,X                     ; // call pushed copy loop on TOS

If I set the IntFlash write mode to Destructive Write,  a different line triggers the same interrupt:

PSHX                          ; // src addr

The IntFlash bean is advertised as a straightforward solution to programming a byte into flash, and the documentation is fairly sparse - it seems that just running the functions is supposed to work.  I can only find a few mentions on the forums here.  Any ideas on what could be causing this interrupt, or what I should investigate?  Is there better documentation on how to use PE beans somewhere?  I've spent hours digging through the reems of posts on programming to Flash from RAM, but applicability to the PE bean is not obvious, and I fear that I lack the low-level programming knowledge to properly implement the flash programming sequence without a bean.

Thanks,

Patrick 

[peg]

Hi Patrick,

Firstly, why are you doing this? It is normally done by your BDM adapter/programming software.

Perhaps you are using OSBDM?

Maybe you are running out of stack ?

Maybe the COP watchdog is triggering?

If you believe you are getting a interrupt that is causing the problem and that it iss un-handled then write simple handlers for the unused ones so you can trap which one it is.

If you have read a lot of the advice given here in these forums you would know the problems associated with stepping through code that does flash erase/programming so I am assuming that is not a problem here.

Another thing - When you say you are getting an interrupt, this is not a reset is it? Perhaps illegal opcode/address. Check the SRS register after it occurs.

[ProcessorExpert · Accepted solution]

Hello Patrick,

It's difficult to diagnose the problem without more details on bean setup and usage and version information on Processor Expert you use (The latest version of PE for CW 6.2 is PE V3.06).
However, the problem might be, for example, that you are overwriting the code the chip is currently running or you are out of stack space.

Please note that QD4 has only 256 bytes of RAM memory and a sector of Flash memory has 512 bytes. In this case it is not possible to use "Safe write" mode in "Write method" property. This mode performs automatic backup-erase-restore operation that allows to change just one byte in a sector. So it's necessary to erase the whole sector if you need to write to some non-erased flashed location.

Please find an attached example project for the latest PE V3.06 for CW V6.2 that shows how to write a data to flash on HCS08QD4 derivative using "Write" mode selected in "Write method" property. To write using this option it´s necessary to erase an sector before write. To this purpose there is created the "USER_SEC" memory segment - please see the "Build options" tab in the CPU bean. The size of "USER_SEC" is equal to a segment (512 bytes) to be sure that application code is not overwritten.

You can also find information about setting of IntFlash bean including some typical usages in the help for the bean.

best regards
Vojtech Filip
Processor Expert Support Team

Project_QD.zip

Message Edited by t.dowe on 2009-10-27 11:44 AM

[PatrickW]

Thanks very much for both of your responses.

Peg:  I believe you thought I was trying to program the oscillator frequency trim value - actually I'm programming a new calibration value (actually a trim for the built-in voltage reference).  Basically I just need to be able to write a byte or two to Flash memory from code running on the stand-alone MCU (rather than through an external programmer).   

Vojtech:  Thanks SO much for the code example - that should be a great starting point.  For some reason when try to compile your project in CodeWarrior I get an error in the CPU bean.  The error window says that the error should be described in the bean inspector, but in the CPU bean inspector I have a red exclamation point next to "Enabled High Speed Modes" with no error description.  I am downloading CW 6.2 to see if its an incompatability issue - I was on CW6.1 / PE 3.01.  After the update I will post back here.

I didn't realize that I needed to define a USER flash segment specifically for this - thanks for that.  After making that change, I at least do not get the "CPU Interrupt" I was getting.  But now I seem to get stuck in an infinite assembly loop - the program gets stuck in the EraseSector command.  I was indeed already using Write mode - I realize Safe Write isn't an option with the 256B RAM limitation.  By the way - is there any reason why using a "tiny" memory model would cause problems?  Your project uses "small."  Once I have CW updated, I will try compiling your simple program again, and start eliminating differences between the two programs until I find out why I'm getting this infinite loop.

Thanks a lot.

Patrick 

Message Edited by PatrickW on 2009-06-23 06:48 PM

[PatrickW]

I finally got this working using the code example you provided - thanks again.

I think I had multiple problems going on at once.  Not sure if this is an exhaustive list but for future reference on the forums:

1.  Make sure the stack size is large enough (at least 80 bytes if not 128).  Set in the build options tap of the CPU PE Bean.

2.  Define the specific sector to be written to seperately in the build options as suggested above.

3.  There is some issue with using the tiny memory model - I still can't get it to work, I had to switch to small.

One remaining question I have:  Is it necessary to erase the sector beforehand?  I've tried omitting this line in your code and it still works fine. 

Patrick 

[peg]

---

PatrickW wrote:

One remaining question I have:  Is it necessary to erase the sector beforehand?  I've tried omitting this line in your code and it still works fine. 

Patrick 

---

Not sure what PE is doin, but at a hardware level you must erase before programming.

Erasing sets all the bits to '1'

Programming sets selected bits to '0'

"overprogramming" does work if the new value only sets further 1's to 0's but it is not recommended to do this with the current generation flash.

[PatrickW]

Yikes - glad I asked.  So, if you have to erase the sector before programming each byte, is it ok to erase the sector once, and then immediately write consecutive bytes using the SetByteFlash function?  Otherwise, it seems that SetByteFlash would only be useful for setting a single byte in each sector.

To rephrase, is it ok to do this:

err_code = IFsh1_EraseSector(0xF000);  // Erase sector

err_code = IFsh1_SetByteFlash(0xF000, 12);  // Write 12 to first flash byte

err_code = IFsh1_SetByteFlash(0xF001, 20);  // Write 20 to second flash byte

err_code = IFsh1_SetByteFlash(0xF002, 11);  // Write 11 to thrid flash byte

or do I have to erase the sector before each individual SetByteFlash function?  If I have to reset for each, it seems impossible to set multiple bytes in the same sector using SetByteFlash.

Thanks,

Patrick 

Message Edited by PatrickW on 2009-07-11 01:24 AM

[peg]

Hello Patrick,

Once you have erased a sector of flash, you should only programme each byte once before erasing that sector again. Whether you programme all the bytes in the sector at once or one byte a day does not matter. So long as you do not programme the same byte more than once in between erasures. Hope that is clearer now.

[PatrickW]

Got it - thanks.

Patrick