Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Level 1
Level 1
First like received

we have encountered problems related to the EEPROM emulation of the XMC4200.

1. When changing from one 16k block to the next 16k block, the old 16k block is erased during the next start of the firmware (reset or power cycle). If this is done during a power cycle, erasing could fail due to bouncing of supply (which can never be avoided). If this bouncing occurs, the flash gets into the following state:
- the sector used for EE emulation (64k starting at 0x08010000) is cleared completely to zeros
- the sector can no longer be written (tested with SEGGER J-Link Commander and with the firmware)
- other parts of the flash above 0x08030000 can be written (tested with SEGGER J-Link Commander)
- the EE flash emulation sector can be written after the chip has been erased completely (SEGGER J-Link Commander command "erase")
We got several chips into this state (~7 out of 50). We are going to fix the problem by rewriting the EE emulation code such, that it erases the flash immediately after it has been written.

2. The code, that checks the VERIFY error bit in the flash status register FSR checks using the equality operator which is wrong in my opinion. Shouldn't this be done using the AND operator? This check should return an error, when the chip got into the state described above, but it returns success, because a second bit number 4 called PROG is set too.

Anyone else got this kind of problems?
What state could the flash sector be in (point #1 above)?
Is this a "logical / physical sector issue"? How are they related to each other? Are they really separate or can clearing a logical sector clear the whole physical sector accidentally?
Why is the clearing of the flash delegated to the next bootup of the firmware instead of doing it immediately?
4 Replies
Level 1
Level 1
First question asked 10 sign-ins 5 sign-ins
We have encountered this problem also.
The data we save on flash sometimes disappears.
The problem happens after saving to flash a few times (we use 4600 byte data block) and then putting the laptop the board is connected to into sleep mode.
The USB hub that is supplying power to the board flashes a couple of times as the laptop is going to sleep, but the board is still powered after the laptop is asleep.
After waking the laptop up, the saved data is gone and subsequent attempts to save data to the flash say they saved OK, but nothing saves properly after this.

As you mentioned in number 2, the flash write routine returns the wrong status, so there is no warning that the flash was not written properly.
This is fixed with a change in E_EEPROM_XMC4_lWriteToFlash() in e_eeprom_xmc4.c:


// if (XMC_FLASH_GetStatus() == (uint32_t)XMC_FLASH_STATUS_VERIFY_ERROR)
if ((XMC_FLASH_GetStatus() & (uint32_t)XMC_FLASH_STATUS_VERIFY_ERROR) != 0U)

One solution as a workaround is to force a board reset after every flash write.
Then the power fluctuation would not happen during a flash erase in E_EEPROM_XMC4_Init() that would lock up the flash.

But a better solution is to mod the Dave App code.
If you have a reliable mod for the E_EEPROM_XMC4_UpdateFlashContents() routine to fix this issue, please let me know.
I will attempt some changes myself, but it would be good to compare notes.

Level 1
Level 1
First like received
Thanks for your response! A few months ago we did exactly, what you suggested.
We modified the DAVE app such, that it writes the flash immediately instead of delegating this step to the next boot process.
Our workaround until this change was implemented was to reset the target explicitely after writing the flash.
The problem seems to be gone. We can no longer reproduced it.

I am facing this issue right now.

Can you explain what exactly you did to rectify this error in a bit more detail.

Level 1
Level 1
10 sign-ins 5 sign-ins First like given

Hello, everyone. I'm a little late 🙂 , but I have the same problem with the XMC4500. I already have the app on version V.4.0.16 but still the same problem. Is there a bug fix for this problem? I would be very happy for an answer.

Kind regards, Dirk