STVD and Data EEPROM unlock

fggnrc2 · ‎2011-04-03

Posted on April 04, 2011 at 05:40

brazov22 · ‎2011-05-17

Posted on May 17, 2011 at 15:12

never tried in ASM. Try to remove the instr:

BTJT FLASH_IAPSR,#3,Unlocked

it'd work, even if you insert again correct keys to unlock memory.

brazov2

fggnrc2 · ‎2011-05-17

Posted on May 17, 2011 at 15:12

Brazov,

I thank for your hint but it doesn't solve my issue.

I made some tests and found some explanations.

STVD unlocks EEPROM and program FLASH.

This can't be avoided because any breakpoint is set by replacing the first opcode of one instruction with the reserved instrucion BKPT (opcode $8B) as it's said at page 18 of UM0470 ''STM8 SWIM communication protocol and debug module''.

Any BKPT is then replaced with the original opcode to resume execution.

This means that no RASS key input code can be single-stepped because STVD interferes with its execution.

STVD release notes confirms this in paragraph 3.5 ''Known problems for STM8-ICD-SWIM targets''.

I dowloaded STM8S_StdPeriph_Lib_V2.0.0 to compare that code with mine.

I found a potential bug in the function FLASH_EraseBlock which is contained in stm8s_flash.c

This bug may happen when EEPROM is busy, as ERASE bit of FLASH_CR2 bit is locked and its value can't change (see RM0016: STM8S Microcontroller Family Reference Manual).

By the way: the same happens for NERASE bit of FLASH_NCR2.

To erase the EEPROM block whose starting address is stored in X, I use the following code:

EEPROM_Eraser

; Select EEPROM Block Erase

LDW Y,#$20DF

ErasingStart

LDW FLASH_CR2,Y

BTJF FLASH_CR2,#5,ErasingStart

; Erase Block

CLR (X)

CLR (1,X)

CLR (2,X)

CLR (3,X)

; Wait for completion, by polling HVOFF bit in FLASH_IAPSR

BTJF FLASH_IAPSR,#6,*

RET

EEPROM_EraserEnd

NOTICE: this code runs from RAM.

Now my code doesn't erase an EEPROM block, even if it executes the same steps of STM8S_StdPeriph_LibV2.0.0 and follows exactly what RM0016 says.

Since it only clears the first four bytes of a block, it seems that a word erasing is taking place even if block erasing is enabled.

It's very, very strange...

EtaPhi

fggnrc2 · ‎2011-05-17

Posted on May 17, 2011 at 15:12

Things are getting more and more strange...

In my new experiments I replaced the instructions:

LDW Y,#$20DF

ErasingStart

LDW FLASH_CR2,Y

with the following ones, whose effect is the same:

ErasingStart

MOV FLASH_NCR2,#$DF

MOV FLASH_CR2,#$20

If I swap them, i.e.

MOV FLASH_CR2,#$20

MOV FLASH_NCR2,#$DF

my code loops forever.

This may be due to the test which follows them, since FLASH_CR2 is read some clock cycles later.

To prove my assumption, I used this code:

MOV FLASH_NCR2,#$DF

MOV FLASH_CR2,#$20

NOP

BTJF FLASH_CR2,#5,ErasingStart

which loops forever too...

When there is at most one NOP, no infinite loop happens.

I now understand why the firmware library uses a timeout while waiting...

fggnrc2 · ‎2011-05-17

Posted on May 17, 2011 at 15:12

The attachment contains a STVD project which runs on STM8S-Discovery board.

If the EEPROM block from $4080 to $40FF hasn't been erased, the led will blink.

Regards

EtaPhi

brazov22 · ‎2011-05-17

Posted on May 17, 2011 at 15:12

If what you say is true, I suggest to spot this problem to ST support. It seems a bug, dependent on how the ASM code is written ... mhhhh

brazov2