2011-07-12 04:13 AM
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 canfind
related discussions by search function in this ****** forum???2011-07-12 04:36 AM
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 EtaPhi2011-07-13 01:44 AM
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
2011-07-22 12:50 AM
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