FSTAT_BLANK bit in FSTAT on S12NE64?

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

FSTAT_BLANK bit in FSTAT on S12NE64?

2,057件の閲覧回数
dkelly
Contributor I
I don't see any errata on this, but am also not seeing any example code using FSTAT_BLANK.

This code is located in RAM and issues commands to the FLASH system:

#pragma MESSAGE DISABLE C12002
static void near
ram_flash_cmd( UINT08 cmd, UINT08 page, UINT16 *address, UINT16 data )
{
UINT08 old_page; // don't know if this is important to save

_RESET_COP_();

// clear access and protection bits
FSTAT = ( FSTAT_ACCERR_MASK | FSTAT_PVIOL_MASK );

old_page = PPAGE; // save
PPAGE = page; // set
*address = data; // Sets data and address for FLASH state machine
FCMD = cmd;
FSTAT_CBEIF = 1; // start FLASH command execution

nop();
nop();
nop();

while( FSTAT_CBEIF != 1 ) // infinite loop until set
;

if( FSTAT & ( FSTAT_ACCERR_MASK | FSTAT_PVIOL_MASK ) )
ram_errno = 10;

PPAGE = old_page; // restore
}
#pragma MESSAGE DEFAULT C12002

When called ram_flash_cmd( 0x05, 0x3e, 0x8000, 0xffff ) to check the blank status FSTAT returns containing 0xC2, bit 1 is set. Manuals and #include files say bit 2 (mask 0x04) is the one we are looking for. Having previously called this routine with cmd = 0x40 I would expect the area to be erased, and looking with the memory window in the debugger confirms the apparent erased state. In all references bit 2 is undefined, said to always read as 0.

Is this an error in documentation? My chip's mask? Debugger anomaly? Or a caffeine deficiency?
ラベル(1)
0 件の賞賛
返信
4 返答(返信)

790件の閲覧回数
kef
Specialist I
Erase verify command verifies if all bytes in flash block are erased. It checks not only sector you just erased, but whole flash block, which probably is not blank. FSTAT bit 1 is documented. It's a FAIL bit. See NE64 datasheet rev1.1.
0 件の賞賛
返信

790件の閲覧回数
dkelly
Contributor I
Ah, thanks! Not the sector but the whole shooting match (in my case the NE64 which has only one FLASH block)!

Guess I'm just being too smart for my own good and should always erase a sector before writing to it rather than check to see if its already erased before erasing.
0 件の賞賛
返信

790件の閲覧回数
peg
Senior Contributor IV
Or just read the whole sector to see if it is blank?
0 件の賞賛
返信

790件の閲覧回数
dkelly
Contributor I
Yes, could read the sector of memory to verify blank but for all I knew there was a flag indicating whether any writes had occurred since last erase. There is an admonition in the data sheet against multiple writes to the same cell, for example when one might clear bits when external events occur. Or possibly someone had written 0xffff and the cell isn't the same as an erased 0xffff?

Anyway, the command was there and I tried to use it only to discover it only applied to the entire 64K block and not a 512 byte sector.

Rather than test for blank I'll simply erase the entire sector as I'm about to write it anyway. It should never be blank but thought it would be nice to verify it was blank after erased. Rather than blank check manually its more useful to verify my writes. And if the write fails I'll loop back, erase and try again.
0 件の賞賛
返信