Saving Data In Flash on GT32

[glork]

Hello All.
I'm using the 9s08gt32 in an application that requires that I save a small amount of semi-perm. data in internal flash. I've followed the Freescale guidelines pretty carefully with these results:
my routines work correctly if I single-step thru them
if I use them while running at full speed they don't work

This is how I set the main clock:
CLOCK_INIT:
mov #$28,icgc1
mov #$31,icgc2
lda icgs1 ; dummy read
mov #01,icgs1
rts

which sets FEI mode with a bus clock of approx. 5.4MHz (which I've verified independantly).

I set the flash clock thusly: lda #$1f sta fcdiv which should yield a flash clock of approx. 174KHz.

Then I have a small routine if flash which gets copied down to ram at $0300 by the startup routine. This routine does the actual writing of flash, and is called by the main routine which runs out of flash. Here is what that looks like:
PROGFLASH:
; write the command
sta fcmd
lda #$80
sta fstat
nop
WFLOOP:
lda fstat
lsla
bpl wfloop
rts

Finally, here is the main flashing routine:
SAVEFLASH:
; check for errors
lda fstat
and #$30
beq asfbt1
; had error(s), try to clr
lda #$30
sta fstat
; then we have to erase
; our flash buffer @ $d000
; min erase is 512 bytes
;
ASFBT1:
sta flashbuf+3 ; any data
lda #$40 ; page erase
jsr progflash
; then write the marker
lda #$a5
sta flashbuf
lda #$20 ; write byte
jsr progflash
lda #$5a
sta flashbuf+1
lda #$20
jsr progflash
; then filterontime
lda filterontime
sta flashbuf+2
lda #$20
jsr progflash
lda filterontime+1
sta flashbuf+3
lda #$20
jsr progflash
; then filter display
lda fltdisp
sta flashbuf+4
lda #$20
jsr progflash
lda fltdisp+1
sta flashbuf+5
lda #$20
jsr progflash
; then temp
lda setpoint
sta flashbuf+$6
lda #$20
jsr progflash
lda setpoint+1
sta flashbuf+$7
lda #$20
jsr progflash
rts

Its probably something simple, but I just don't see it yet. Any help would be appreciated.
ron

[Steolino]

The application note AN2770 is about a Flash Library (HCS08_Flash_Lib.Lib)

Do you know where I can download this library?

I think it seems very useful and easy. Do you use it?

Thanks

Stefano

[rhinoceroshead]

Here is one thing I see that may cause the problem you describe.  The flow chart on page 49 of the datasheet says that you should wait a minimum of 4 bus cycles between setting the FCBEF and then reading FSTAT.  You have one NOP there, which only uses 1 bus cycle.  You could try throwing a few more NOPs in there to see if that helps.  Or if you want to keep the programming routine in RAM as short as possible, you could replace the NOP with a MUL (only 1 byte opcode but 5 cycles) as long as you aren't holding anything important in the index register.

I'm still looking, but that's one thing you can check.  It would explain the fact that it works when stepped.

[peg]

Hi Ron,

Well I just took what you posted and added just enough to make it a full programme.
Then I put it in my demo GB board and it works!

Rhinoceroshead is correct about the delay but it seems to work without it!

I wouldn't be relying on this though for the sake of a few bytes.

I have included my programme here with the extra delay commented out along with additional error checking that you may want to include escpecially if you are still having problems.

Code:

.NOLIST$Include "9S08GB60v1rdp.inc".LIST* Additional initialisation by pegPROGFLASH EQU $0300 ORG RamStartfilterontime RMB 2fltdisp  RMB 2setpoint RMB 2 ORG $D000flashbuf RMB 8 ORG RomStart MOV #$11,filterontime MOV #$22,filterontime+1 MOV #$33,fltdisp MOV #$44,fltdisp+1 MOV #$55,setpoint MOV #$66,setpoint+1  LDA #mBKGDPE STA SOPT *Hello All.*I'm using the 9s08gt32 in an application that requires that I save a small amount of semi-perm. data in internal flash. I've followed the Freescale guidelines pretty carefully with these results:*my routines work correctly if I single-step thru them*if I use them while running at full speed they don't work*This is how I set the main clock:CLOCK_INIT: mov #$28,icgc1 mov #$31,icgc2 lda icgs1 ; dummy read mov #01,icgs1; rts;which sets FEI mode with a bus clock of approx. 5.4MHz (which I've verified independantly).;I set the flash clock thusly: lda #$1f sta fcdiv which should yield a flash clock of approx. 174KHz. lda #$1f sta fcdiv* copy routine to RAM by peg ldx #WFLEND-PROGFLASHF+1WRRAM: lda PROGFLASHF-1,x sta $02FF,x dbnzx wrram* now actually do it by peg jsr saveflash bra *FAILED: bra *;Then I have a small routine if flash which gets copied down to ram at $0300 by the startup routine. This routine does the actual writing of flash, and is called by the main routine which runs out of flash. Here is what that looks like:PROGFLASHF:*write the command sta fcmd lda #$80 sta fstat nop* additional delay and error checking by peg* brn ** lda fstat* and #mFPVIOL|mFACCERR* bne failedWFLOOP: lda fstat lsla bpl wfloopWFLEND: rts;Finally, here is the main flashing routine:SAVEFLASH:; check for errors lda fstat and #$30 beq asfbt1; had error(s), try to clr lda #$30 sta fstat; then we have to erase; our flash buffer @ $d000; min erase is 512 bytes;ASFBT1: sta flashbuf+3 ; any data lda #$40 ; page erase jsr progflash; then write the marker lda #$a5 sta flashbuf lda #$20 ; write byte jsr progflash lda #$5a sta flashbuf+1 lda #$20 jsr progflash; then filterontime lda filterontime sta flashbuf+2 lda #$20 jsr progflash lda filterontime+1 sta flashbuf+3 lda #$20 jsr progflash; then filter display lda fltdisp sta flashbuf+4 lda #$20 jsr progflash lda fltdisp+1 sta flashbuf+5 lda #$20 jsr progflash; then temp lda setpoint sta flashbuf+$6 lda #$20 jsr progflash lda setpoint+1 sta flashbuf+$7 lda #$20 jsr progflash rts;Its probably something simple, but I just don't see it yet. Any help would be appreciated.;ron* reset vector by peg org $fffe DW RomStart

Don't forget to let us know what you find...

Regards Peg

[rhinoceroshead]

I just read the Flash section of the S08GT32 datasheet very carefully and I didn't notice it ever mentioning anything about having to program the flash from code executing in RAM.  The HC08GP32, however, clearly states that it must program from RAM.  Are we blindly assuming that it is like the HC08 in this respect or does it in fact have to be executed from RAM?  It seems like a few days ago there was a similar post that seemed to get resolved by executing from RAM, but I know sometimes when debugging, it's easy to apply two solutions to one problem and then misinterpret which solution it was that really solved the problem.  Peg, could you by any chance, try changing the address of the Flash programming code that you just posted to a Flash location and see if it works?  I'm just curious  It's not a big deal if you don't have time.

[glork]

---

rhinoceroshead wrote:

I just read the Flash section of the S08GT32 datasheet very carefully and I didn't notice it ever mentioning anything about having to program the flash from code executing in RAM. The HC08GP32, however, clearly states that it must program from RAM. Are we blindly assuming that it is like the HC08 in this respect or does it in fact have to be executed from RAM? It seems like a few days ago there was a similar post that seemed to get resolved by executing from RAM, but I know sometimes when debugging, it's easy to apply two solutions to one problem and then misinterpret which solution it was that really solved the problem. Peg, could you by any chance, try changing the address of the Flash programming code that you just posted to a Flash location and see if it works? I'm just curious It's not a big deal if you don't have time.

---

Hi Rhinoceroshead and Peg.
It is strictly prohibited to run out of flash whilst trying to erase/program it. I suppose this is because the flash gets disabled when the high voltage gets keyed on.

I tried putting in more cycles in the place recommended by Peg (added 5 nops to the 1 already there for a total of 6). This appeared to make no difference at all; it still works in single-step but not at full speed. I'm still missing something.
ron

[peg]

Hi Ron,

What if you assemble and run my code as is.
The error check may throw some light on it, though you will have do fix my faulty error branch.

Anyway I'm of to do some stuff that i will get paid for now....

Regards Peg

[peg]

Hi rhinoseroshead,

It might not say there but it does refer you to the HCS08RM where it definately does say the flash doesn't work while erase/prog.

4.8.2 Erase One 512-Byte Page in FLASH

Program and erase operations for the FLASH memory are a little more

complicated compared to many application programs because it is not

possible to execute a program out of FLASH during FLASH program and

erase operations.

Also after I turned the computer off last night I realised that I put a relative branch into the error check which is in the code the moves to RAM. So it will blow up if it branches. Woops! No time to fix it now.

Regards Peg

[Alban]

Hi Rhino & Peg,

I haven't had my coffee yet, but I think I won't tell too many rubbish here . Well at least I'll try.

The topic is quite similar to a new one... Still, let me clarifiy a few things, if I may.

It is not physically possible to execute from a Flash block being programmed because to program a block the charge pump is applying the high voltage on the array.
But there is nothing preventing you from executing code from another block while one is under the high voltage programming voltage.
This also applies to all HC9S12 and S12X.

Actually, there is only one thing forcing you to execute programming routine from RAM is when:

     - You only have one Flash Block,

     - You want to reprogram all Flash.

So, that's why a small HC08 datasheet might lead you to the RAM.
Also, some of these having very small RAM on top of very small Flash, the programming routines were implemented in ROM (generally all HC(S)08 devices below 8-16KB Flash size).

Now, I'll go and have this famous coffee....

Cheers,

Alban.

[peg]

OK Alban, I hope you have had that coffee.

I am starting to hate the word 'block' it seems to have too many meanings with reference to FLASH.
Here's what I understand:

FLASH Array: All of the flash. Sometimes called a block.

FLASH Page: Minimum erase size (512 in a GB/GT) Sometimes called a block

FLASH Block with reference to block protection: Multiples of pages 1,2,4,8,16,32,64 pages.

FLASH row: Rows relate to burst mode programming (8 rows of 64 in GB/GT page).

So what is the block that you are referring to. How many of your blocks are there in a GB/GT60. That is these blocks that you can programme one from the other. Because I can't find any reference to this in HCS08.

Time to grab a beer! (I am 10 hours ahead of Alban).

Regards Peg

Message Edited by peg on 05-05-200606:53 PM

[rhinoceroshead]

My guess is that Alban is referring to the segment which you (Peg) are calling a 'page' when erasing and he is referring to a 'row' when programming.  My (probably out of date) understanding from an electrical standpoint is that Flash and EEPROM are the same thing, except EEPROM can distribute the high voltage and erase signals down to the byte level, which requires a lot of extra address decoding logic and Flash can be fabricated much more densely than byte erasable EEPROM for this reason.  So using Peg's terminology, which sounds right on to me, the 'page' is the minimum erasable chunk, and this would be defined by how many bits of the address bus are decoded for the erase signal.  Then the 'row' is defined by how many bits of the address are decoded for the high-voltage signal, which must be present for programming or erasing - meaning the row size must be smaller or the same size as the page size.  The 'block' term also seems poorly defined to me, but I like Peg's interpretation where it means block protection.  The only problem with that is that the block protection has nothing to do with Flash technology electrically and just refers to the number of bits used by Freescale to define the available points that divide protected from unprotected Flash.  Different Flash manufacturers might use slightly different techniques for manufacturing, and they have a right to call their segments as they please - but then it gets confusing when their definitions overlap.  Anyway, I would like to check this out, because it would really be nice to know if you can write into Flash while executing from Flash.  It should be physically and electrically possible to do it as long as the segment of Flash you are executing from is not being disturbed by high voltage or erase signals as Alban is pointing out.  However, if Freescale engineers are looking at the first few bits of the program counter to determine when the high-voltage is allowed to turn on, it would take fewer logic gates for them to mask out the entire Flash array rather than to mask just the row that is being programmed, so it is also reasonable for them to do that as well.  I'm fairly certain that the HC08GP32 can not write to Flash at all without executing from RAM but I will gladly confirm this sometime over the next few days.  I have an SX12DP512 board at home that I can test this on too - but on that particular device there are multiple independent Flash modules anyway, so you could just as easily execute from one while writing to another and you would never need to copy code to RAM.  I would also gladly mail a bottle of beer to Australia if Peg would be kind enough to test this on the HCS08.  :smileyhappy:

[peg]

Hi all,

Well I've done some experimenting and this is what I have found:

I fixed the problem with my previously posted code.

I moved the flash buffer to E000. and made two versions (GLORK.asm and GLORKram.asm. the ram one is mostly just the fixed original code and the non ram one tries to write FLASH at E000 from FLASH very near the bottom of the array. They are both actually the same with different bits commented out.

The RAM one works perfectly as expected.

Now if there is several "blocks" (there is that word again!) surely some at the very bottom is in a different block to some very near the top.

What I found is it doesn't work!

I think I found the answer to Glork's problem as well. That is I believe he may be copying his routine down to RAM but actually using the version in FLASH.

This is exactly what I found:

If I single step all the way through it appears to work perfectly, even the bits I added where I read the recently flashed values back and copy them to RAM. But if you power down and back up the FLASH all reads $FF!

If I single step half way through then RUN, I end up in the FLASH failure loop.

If I RUN right from the top it blows up and when I stop it I am anywhere in memory.

So it appears that when you write the values to FLASH to prepare for flashing these values appear to the user programme as the actually flashed data.

So this begs the question. Can you use FLASH as RAM?

I'm off to see if I can find some documents on how this FLASH actually works.

Regards Peg

Message Edited by peg on 05-06-200601:18 PM

[peg]

Hi,

After some more testing I found this:

If I start with erased flash at E000 then multistep the programme with the erase command commented out, I can flash the data in and it becomes non-volatile!

I still can't run it at full speed run though.

Anyway, all this proves is that even with the biggest available flash array you still have to execute flash erase/prog from RAM. This applies to ALL 8-bit FLASH based MCU's!

If you try to do it from FLASH you will get all sorts of strange results, none of which I'm sure no one is going to rely on.

BTW, AN1837 explains how the flash works but unfortunately doesn't really shed any light on what is going on here as it tends to look at it on a bit level and does not explain how the actual programming mechanism works at a byte level.

Regards Peg

[glork]

To Rhino, Peg & Alban:
After some testing I can report the following:
1. As far as I can tell my code is executing correctly (verified by sintle-stepping the debugger which is connected and running the actual target).
2. I follow the freescale procedure (you can see my code) (yes, I did put in the error check recommended by Peg).
3. It still works in single-step mode but not running at full speed.

I'm sure that it is possible to program flash because the debugger/pod does it all the time. I suppose there is some deviation to the procedure that freescale knows about but hasn't seen fit to publish, which is absolutely typical of them.

Designing with these micros is what I do for a living; its my only source of income. I never have time to agonize over/piddle with this type of problem. If I can't make something work in a reasonable (read short) amount of time I have to abandon it for a solution that actually works. In this case I will have to patch in an external memory that really does work.

Thanks for your help.
ron

[Alban]

Glork,

I would think there could be a problem with code or something like this. (I'm thinking initialization of clocking divider of the charge pump or a delay not respected somewhere).

These Flash are starting to be quite old and are SST licensed (as you can read in footer of quite a few documents). They have been used in zillions of applications everyday for more than 5-7 years.

I suggest you Open a Service Request NOW so your problem is treated ASAP and you can eat without having to worry. (please private me the SR# and I'll follow). Include CodeWarrior project as an attachment but do NOT select it as a CodeWarrior/Tool problem !
The page is also accessible from http://www.freescale.com/techsupport.

People behind the Technical Request HAVE to reply to you quickly.
Most Freescalers only appear on the Forums on a voluntary basis only.

Cheers,
Alban.

[glork]

Alban, Peg & Rhino.
Well...ok this is really embarrasing. I'm old enough to know that if you post a rant you will get caught with something stupid.

My code always worked when I single-steped, never worked running full out.

Let me give everyone on the forum a hint: IF YOU NEED TO PROGRAM FLASH BE SURE TO TURN OFF ANY HEART-BEAT OR OTHER INTERRUPTS FIRST!!!!

The fact is that my code (with some suggested enhancements from you guys) works just fine. But of course if an interrupt occurs while the flash is disabled...

Sheesh, I'm never going to rant again.
ron

[Alban]

Dear Ron,

I am completely with you and I understand you let the pressure out !
Actually I suggested a board to the Admins with "Express Yourself" as a title...
A board where people could just shout their frustration because they can't get it working.

Funnily enough, this board was not approved

I'm also 100% with you with Interrupts during Flash Programming.
If an interrupt occurs and should execute code from Flash, it will screw the programming.
On HC08 as the Adress to program/erase is locked by reading it, if you have an interrupt, you could erase the vector page... Except with block protection.
Even more important on HC08 (and not S08), you have to do the timings 'manually' and if an interrupt occurs it could change the timings and DAMAGE the cells...

But I will only say: I like when things go to plan..........
Alban. {GT exists both on HC08 and S08}

[glork]

'Express yourself' probably means different things for different people. I think such a forum might be useful but I can't see how to moderate it. Freescale's hair probably stuck straight up when you suggested it.

Actually, it seems that 'slightly loose' moderation, such as I think we have here, accomplishes much of that goal. Although I made a bit of a fool of myself with this problem I wasn't restricted by a moderator and the thread ran, suggestions were made and...my problem is solved. A net gain for all at a moderate price.
Cheers,
ron

[peg]

Well.....

Without the banter this thread probably would have stalled, unresolved.

Now at least it should assist people in the future.

Although your promise is also permanently recorded for anyone to quote back at you in the future.

Peg

[glork]

---

peg wrote:

Well.....

Without the banter this thread probably would have stalled, unresolved.

Now at least it should assist people in the future.

Although your promise is also permanently recorded for anyone to quote back at you in the future.

Peg

---

"Although your promise is also permanently recorded for anyone to quote back at you in the future"
Yes, this is called 'compounding the mistake'. I'm much better at this than at programming (completely obvious).
ron

[peg]

Hi,

I was going to say all S08 are like this, then when writing it I got cocky and expanded it to cover everything even though I have probably never even seen more than half of them. Sorry!

Perhaps I am correct if it is qualified with "except where there obviously is distinctly seperate flash arrays".

BTW all of the stuff I have presented in this thread in no way indicates there is any problem with the programming of flash on these devices!

I have been trying to do things that are outside of what the manuals suggest can be done. All of what they say works - DOES WORK!

All that I have found is that you seem to be able to get away with only one cycle delay before checking FSTAT. But this doesn't mean to do this, more that you should be careful that you have the correct delay because just the fact that it works doesn't mean it will do so forever, always. Flash wears out and gets slower to prog/erase.

Also I found that you seem to be able to programme flash from code running in flash if you do it slowly or something. But it doesn't really work.

Ron, your code as presented is WRONG! And I have proven that if you run your code as presented you will get the results you are seeing. You are calling progflash which is the version in flash. Please check you are really executing in RAM before making wild accusations.

Regards Peg