DATA EEPROM area - problem writing byte

[wolfgang239955_stm1_st]

Posted on July 12, 2011 at 13:13

Hi experts,

in my application I am trying to write a single byte to an address in the DATA EEPROM area immediately after disabling ''the DATA area write protection by writing consecutively .. MASS keys to the FLASH_DUKR register''.

--> But writing will be ignored!!

 

Inserting at least one instruction after writing the MASS keys solves the problem.

Code:

...

     FLASH_DUKR = 0xAE;

     FLASH_DUKR = 0x56;

     *DATA_EEPROM_destination = char_value; 

From the Disassembler:

.......

eep.c:226        FLASH_DUKR = 0xAE;

0x8db2 0x35AE5064     MOV   _FLASH_DUKR,#0xae

eep.c:227      FLASH_DUKR = 0x56;

0x8db6 0x35565064     MOV   _FLASH_DUKR,#0x56

eep.c:231       *DATA_EEPROM_destination = char_value;

0x8dba 0x7B01         LD    A,(0x01,SP)

0x8dbc 0xF7           LD    (X),A

........

The problem does not to appear always, but I can't see any principle :o(

Any ideas???

Regards,

WoRo

BTW: can anybody help me? How can

find

 related discussions by search function in this ****** forum???

[fggnrc2]

Posted on July 12, 2011 at 13:36

Nice to hear news from you, WoRo!

I had your same problem in writing EEPROM.

As you know, I develop my code in assembler, but it's easy to translate it in C.

Your observations are true: between the RASS key input and the EEPROM write some clock cycles must elapse.

If my memory doesn't fail, somewhere in the STM8 manuals I read a ST hint to check always the RASS state after the right key sequence is written in FLASH_DUKR.

Since this takes some time, it confirms your observations.

I use the following code:

.UnlockEEPROM

        BTJT    FLASH_IAPSR,#3,UnlockedEEPROM

        MOV     FLASH_DUKR,#$AE

        MOV     FLASH_DUKR,#$56

UnlockedEEPROMTest

        SCHEDULER

        BTJF    FLASH_IAPSR,#3,UnlockedEEPROMTest

UnlockedEEPROM

        RET

And this one to lock EEPROM again:

.LockEEPROM

        ; Wait programming end...

        SCHEDULER

        BTJF    FLASH_IAPSR,#2,LockEEPROM

        BRES    FLASH_IAPSR,#3

        RET

My SCHEDULER macro hands over the CPU to the other tasks, since I use a RWW device. If you doesn't need this option you can remove it.

Regards

EtaPhi

[wolfgang239955_stm1_st]

Posted on July 13, 2011 at 10:44

Hi EtaPhi,

thanks for your prompt response.

I read the text you, have been pointing to:

Before starting programming, the application must verify that the DATA area is not write protected by checking that the DUL bit is effectively set. The application can choose, at any time, to disable again write access to the DATA area by clearing the DUL bit.

 

 

I thing it is not very clear whether they mean

- to check the DUL to decide starting the MASS procedure

- or to check it after writing the MASS keys. 

Anyway, as you recommended I will now insert a bit test FLASH_IAPSR,#3 (DUL) after writing the MASS keys.

Thank you again and bye for now,

WoRo

[brazov22]

Posted on July 22, 2011 at 09:50

I think there is some internal delay into the micro before memory is unlocked, so this is the reason why you have to check that memory is really unlocked cheking DUL bit before to write.

brazov