CY8C4146LQS-S423 / KBA228069 for Em_EEPROM_Init issue

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

cross mob
KaKo_4074056
Level 4
Level 4
Distributor - Marubun (Japan)
First like given First solution authored 25 replies posted

Hello,

When a power interruption occurs during Em_EEPROM_Write processing, the corresponding Row may be filled with 0xFF. In this state, Em_EEPROM_Init processing might not be returned after PSoC4 is restarted. I can't find any process in Em_EEPROM_Init that causes an infinite loop.

The configuration of EEPROM is as follows.
- Component v2.20
- Size: 64 bytes (actual size: 128 bytes)
- Redundant Copy: No
- Wear Level Factor: No

KBA228069 patch is not applied to the project of PSoC Creator yet. It mentions the FindLastWrittenRow function called in Em_EEPROM_Init. Will adding this patch avoid an infinite loop?

Best regards,

0 Likes
1 Solution
Alakananda_BG
Moderator
Moderator
Moderator
50 likes received 250 sign-ins 250 replies posted

Hi,

Does your comment mean that it can also be corrupted for Rows that contain program areas?

Yes, it is possible.

We should avoid power interruption during flash write as the behavior is unexpected.

Regards

Alakananda

View solution in original post

0 Likes
5 Replies
Alakananda_BG
Moderator
Moderator
Moderator
50 likes received 250 sign-ins 250 replies posted

Hi,

Unstable power supply during Em_EEPROM_Write causes the corruption of not only the row it is writing, other rows may also be effected. So it is required to reprogram the device after flash corruption. Can you also compare the hex file after corruption and before corruption. You can read hex from the device using PSoC Programmer.

 

Regards

Alakananda

Alakananda
0 Likes
KaKo_4074056
Level 4
Level 4
Distributor - Marubun (Japan)
First like given First solution authored 25 replies posted

Hi Alakananda_BG, 

Thank you for your reply.

Sorry, but there was an incorrect information of the size. It should be as follows.
- Size: 256 bytes (actual size: 512 bytes)

Em_EEPROM has 4 Rows, one of which is filled with 0xFF (128 bytes: Header(64B) + Data(64B)). It looks like there is no change in the area other than Em_EEPROM in Flash.

Best regard,

0 Likes
KaKo_4074056
Level 4
Level 4
Distributor - Marubun (Japan)
First like given First solution authored 25 replies posted

Hi Alakananda,

Does your comment mean that it can also be corrupted for Rows that contain program areas? As far as I saw, the Flash area that was corrupted due to the power interruption was the just Row being written by Em_EEPROM.

Best regards,

0 Likes
Alakananda_BG
Moderator
Moderator
Moderator
50 likes received 250 sign-ins 250 replies posted

Hi,

Does your comment mean that it can also be corrupted for Rows that contain program areas?

Yes, it is possible.

We should avoid power interruption during flash write as the behavior is unexpected.

Regards

Alakananda
0 Likes
KaKo_4074056
Level 4
Level 4
Distributor - Marubun (Japan)
First like given First solution authored 25 replies posted

Hi Alakananda,

Thank you for your reply.

In my case of the infinite loop in Em_EEPROM_Init, the program area in Flash wasn't corrupted. Although applying the KBA patch for APIs of Write and Erase will not help the problem of the infinite loop in Em_EEPROM_Init, but basically do you recommend applying this patch?

Best regards

0 Likes