MC9S08GT32A - Can't zap the flash (any more)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MC9S08GT32A - Can't zap the flash (any more)

2,130 Views
Wings
Contributor I
If I had enough hair to spare I'd be pulling it out over this. This flash programming routine *USED* to work, until I went through all my code and took out the use of the COP timer. I must have done something but I'll be darned if I can find it. Someone, please have a look and make a suggestion. I'd appreciate it. It was derived from an app note and section 4.4.4 of the data sheet.

The facts:
I get an access error (FACCERR set) when I attempt to program.
The FCDIV register was written with $98 just after reset (BusClk=14.68MHz, FlashClk=180KHz).
The NVPROT register is $98 (FPOPEN set & $F000-$FFFF protected).
The NVOPT is $FE although I didn't do it (debugger?). Sec1:smileyfrustrated:ec0 = 10 = unsecured.

The strange thing is, FACCERR is becoming set as soon as the instruction to clear it is executed. If you'll notice the "###" within the comments, that's where I'm grabbing and saving the FSTAT register. The 3 samples of FSTAT (at $FB, $FC, $FD) are $C0, $D0, $D0. So, you see that FACCERR is getting set when it is supposed to be getting cleared.

Here's the code (that runs from RAM):

;*********************************************************************
; When FLPROG is called, stack is a mess. It looks like:
;          1:2,sp                           Return addr (to Progflash).
;          3:FLprogSize+2,sp                This subroutine.
;          FLprogSize+3:FLprogSize+4,sp     Flash address to be prog.
;          FLprogSize+5,sp                  Byte Count (0=256).
;          FLprogSize+6:FLprogSize+7,sp     Return addr.
;          FLprogSize+8:FLprogSize+9,sp     Source address of prog data.

FLPROG     LDX        FSTAT      ;### TEST
           STX        $FB        ;### TEST. Saved FSTAT is $C0
           sta        FSTAT      ;abort any command and clear errors (A = $30)
FLPROG2    LDA        FSTAT
           BPL        FLPROG2    ;WAIT FOR FCBEF SET (READY 4 CMND).
           STA        $FC        ;### TEST. Saved FSTAT is $D0, FACCERR set!
           LDHX       LOW(FLprogSize+8),SP  ;GET SOURCE ADDR. ($0198)
           LDA        0,X        ;GET DATA AT SOURCE.
           AIX        #1         ;BUMP SOURCE ADDR.
           STHX       LOW(FLprogSize+8),SP
           ldhx       LOW(FLprogSize+3),sp  ;get flash address from stack ($8200)
           sta        0,x        ;write to flash; latch addr and data
           AIX        #1         ;BUMP FLASH ADDR.
           STHX       LOW(FLprogSize+3),sp
           lda        #$25       ;get flash command, Burst Program.
           sta        FCMD       ;write the flash command
           lda        #$80
           sta        FSTAT      ;[pwpp] register command
           nop                   ;[p] want min 4~ from w cycle to r
           NOP
           LDA        FSTAT
           STA        $FD        ;### TEST. Saved FSTAT is $D0 (FACCERR still set)
           BIT        #%00110000
           BNE        FLprogEnd  ;error if FPVIOL or FACCERR bit set.
           DBNZ       LOW(FLprogSize+5),sp,FLPROG2  ;do for COUNT bytes.
CkFPDone   lda        FSTAT      ;[prpp] so FCCF is valid
           lsla                  ;FCCF now in MSB
           bpl        CkFPDone   ;Loop until prog complete.
FLprogEnd  rts                   ;back into ProgFlash in flash
FLprogSize equ        (*-FLPROG)
Labels (1)
0 Kudos
Reply
2 Replies

841 Views
Wings
Contributor I
Weird stuff. I got the programming code working, but by doing something that I wasn't doing before. In the code where it initiates the command action (by storing a 1 into FCBEF, at the line "LDA #$80, STA FSTAT" ), I changed that to also store a 1 into FPVIOL and FACCERR at the same time. This is not the recommended method shown in any examples I have seen in the data sheet, app notes, or reference manual.

And even weirder... If I put in a breakpoint after my code that erases the flash page and before the code that programs a page (the FLPROG code), then continue on from the breakpoint, the FIRST byte of that page does not get programmed and no error flags are raised. If I have no breakpoint the entire page is programmed correctly.

Freescale: Are there any secrets about flash programming that you'd like to share with me?
0 Kudos
Reply

841 Views
Wings
Contributor I
Found the problem. Early in my code where I handle power-up/power-down situations I was storing a value into memory at label PWRCHEK, rather than variable PWRFLAG. PWRCHEK is in flash and storing something to flash is the 1st step in a programming sequence. Evidently that got the flash programming machine's panties in a knot, and even clearing the FPVIOL and FACCERR error status bits and aborting any flash command possibly underway (setting FCBEF=0) prior to programming still didn't clear things up completely.

And this all started when I disabled the COP and went through my code and removed all the "STA SRS" instructions. I'm not even going to think about that.

Hopefully my experience will help someone who makes a similar mistake.
0 Kudos
Reply