2 Critical bugs in Emulated EEPROM component, negative effect on all users. DO NOT USE.

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

cross mob
kemic_264446
Level 4
Level 4
First like received

 Just a quick heads up for everyone. (Are you listening Cypress?)

   

There are 2 serious bugs in the Emulated EEPROM component which make it not suitable for use in any application.

   

It has to do with the way the internal addresses within the flash arrays are calculated. The user has no control over these and a work around is only possible by editing the generated-source or modifying the supplied library source.

   

1. If the constant structure, variable or array you have defined just happens to live outside of flash array-0 then writing to it will corrupt other areas of flash. The data will get saved to the wrong flash array and could overwrite code, or configuration data.

   

2. If the data you are storing in flash just happens to occupy part of the last row of a flash array (again you have no control over this) then the last row will be written to the wrong flash array, which could damage code or configuration data. 

   

 

   

I have raised tickets with Cypress for both of these issues. I have given them sample code which demonstrates the issues and I am sure a fix will be forth coming, but until then you canot use the Emulated EEPROM component.

   

If you are currently using this component and not suffering any bad effects, then it is only by chance - a small change to ANY part of your code could push your flash data into one of the affected areas and cause your code to behave in strange ways.

   

For those on PSoC 5 or PSoC 5LP here is a work around:

   

After you code is built and compiled, find the generated source for the Em_EEPROM_Write() method. [Its name will depend on what you names the component in the schematic, for example if your component is named 'FlashSave' then the method will be FlashSave_Write() ]

   

Then edit the four lines at approximately line 121 in the file and replace them with this:

   

   

        rowNumber = dataAddress / CY_FLASH_SIZEOF_ROW;

   

        arrayNumber = dataAddress / CY_FLASH_SIZEOF_ARRAY;

   

        rowOffset = dataAddress - (CY_FLASH_SIZEOF_ROW * rowNumber);

   

        readSrcIndex = 0u;

   

And then add this line immediately following the previous four:

   

rowNumber &= 0x000000ff; 

   

 

   

This will allow the rowNumber and arrayNumber to be calculated properly for any address in flash.

   

 

   

I hope this helps.

0 Likes
1 Solution
Anonymous
Not applicable

This problem is mostly contained to PSoC 5 / 5LP.  Those devices can have up to 4 Flash blocks.  PSoC 3 and PSoC 4 have just a single Flash block.  Therefore they are only prone to the second problem that you describe that can occur if you are trying to write the last row of flash.  Flash is allocated by the linker sequentially, so for PSoC 3 /  4 the problem doesn't occur unless you fill all the Flash in the device and the location you attempt to write got allocated to that last piece of Flash.

View solution in original post

0 Likes
18 Replies
AlanH_86
Employee
Employee
100 replies posted 50 replies posted 25 solutions authored

 I dont know the cause.  And that doesnt sound very good.

   

We will sort it out and post a more detailed response today.

   

Alan Hawse

   

EVP Software

   

Cypress Semiconductor

0 Likes
Anonymous
Not applicable
        Thanks for pointing us to this bug. After analyzing the issue, we filed 3 CDTs (CDT 162480, 164212 and 163792). The CDTs are already fixed. New version of component, with fixes, has been merged to the dev line and is currently under regression test. We are planning to release the fixed component in the upcoming WW42 Component Pack 7 release. We can send you the fixed version of the component in the next days after it passed the regression test. Please let me know. Thanks, Heinz   
0 Likes
Anonymous
Not applicable

This problem is mostly contained to PSoC 5 / 5LP.  Those devices can have up to 4 Flash blocks.  PSoC 3 and PSoC 4 have just a single Flash block.  Therefore they are only prone to the second problem that you describe that can occur if you are trying to write the last row of flash.  Flash is allocated by the linker sequentially, so for PSoC 3 /  4 the problem doesn't occur unless you fill all the Flash in the device and the location you attempt to write got allocated to that last piece of Flash.

0 Likes
kemic_264446
Level 4
Level 4
First like received

 Heinz,

   

 

   

Yes - I'd like to be able to help test the fix for you.

   

 

   

-Kenny

0 Likes
Anonymous
Not applicable

 Kenny,

   

our regression is expected to finish on Monday. I will let you know on Monday where to access the fixed component. Thanks for your help!

   

Heinz

0 Likes
Anonymous
Not applicable

Hello,

   

we use the EEPROM module with a 5LP too.

   

So it would be very interesting to read here, when and where the new module will be released.

   

Kind regards,

   

Thomas

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked
        @treess   
There are two different usermodules: EEPROM and Emulated EEProm   
The error Kenny found here is ONLY concerned with the Emulated EEProm.   
   
Bob   
0 Likes
Anonymous
Not applicable

Kenny got an alpha version of the fixed emulated EEPROM componeent for validation in his product. If anybody wants to validate the alpha component please let me know. (you can't use it in production!). We are planning to release the fixed component in the next 3 weeks in the next Creator 3.0 Component pack.

   

Heinz

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

A new version of Creator 3.0 has been released (called "component pack7"). It contains the updated Emulated EEPROM component.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

If you use the Cypress Update Manager it will flag you

   

automatically to update to new service packs, including

   

the aforementioned one.

   

 

   

Regards, Dana.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

The updated notes in datasheet -

   

 

   

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

OK, lets do this the hard way, attached.

0 Likes
RobynW
Employee
Employee
5 likes given First comment on blog 10 likes received

We've updated the Knowledge Base Article "Using the Emulated EEPROM Component with PSoC 5 and PSoC 5LP Devices - KBA89725" to include a PSoC Creator 2.2 component and directions on how to install for anyone neededing the Emulated EEPROM on PSoC 5.

   

 

   

As hli posted earlier (thanks!) for PSoC Creator 3.0 users, the Emulated EEPROM was fixed in Component Pack 7.

   

 

   

Thanks,

   

-Robyn

0 Likes
Anonymous
Not applicable

 I'm still experiencing issues with this component when using the PSoC4. 

   

strangely enough some array's I store will work and other won't.

   

Yet the _Write() function returns succes. but.. it doesn't write it. 

   

any one experiencing the same issue?

   

matijs

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Can you please upload an example project showing the error? Use Creator's "Create Workspace Bundle" and upload the resulting file using ie (Chrome still does not work)

   

 

   

Bob

0 Likes
RobynW
Employee
Employee
5 likes given First comment on blog 10 likes received

Posting an example project would be great.  Make sure you're using PSoC Creator 3.0 Component Pack 7.  It was released late October and has a fix for the Emulated EEPROM component.  If you're using 2.2, you'll need to follow the directions in KBA89725 to get the updated component into the 2.2 release.

   

 

   

-Robyn

0 Likes
Anonymous
Not applicable

pastedImage_0.png

0 Likes