Hello David,

The issue listed in your post has been fixed in HalCoGen 4.07.01. Please download the latest version of HALCoGen with new FEE driver.

So far I haven't noticed any open issue with the new FEE driver.

We are still using 4.07.00, so I am curious about how the bug manifests itself.

Thanks.

Hi David,

Please use the latest version.

SDOCM00122496: EEPROM seems to corrupt when Flash Bank 7 sector 0 is copied to Flash Bank 7 sector 1. When you write the data to EEPROM sector 0, if the sector0 is full, the valid block data will be copied to other sector (sector 1). Reading the data from FEE might get abort It doesn't happen always. This bug has been fixed in 04.07.01.

Hello QJ,

We have product in the field which uses FEE routines from HALCoGen v4.07.00.  It is good to hear that v4.07.01 has a fix to this problem, and it certainly makes sense for us to create an updated firmware using HALCoGen v4.07.01's FEE routines.  This involves the usual complications (the need to validate the updated FW, the need for some of our products to schedule an in-field service call to perform the update, the risk that some customers will never find out about the updated FW until they've experienced an equipment failure, etc.).  Having a complete understanding of this issue is crucial as we work on the specifics of our plan to address it.

I have some particular questions:

Does this problem only occur when copying data from sector 0 to sector 1, or does it also occur when copying data from sector 1 to sector 0?

Is the problem one where the flash _does_ get corrupted (i.e. invalid data is actually written to the "EEPROM", or data fails to get written when it needs to be, and hence is lost), or is the problem one where the flash _seems_ to be corrupted (i.e. the data was actually written correctly, but even though it was written correctly, attempts by v4.07.00-based FW to read that data will fail)?

You said that the failure doesn't always happen; what are the conditions for when this will or will not happen?

Does updating a unit that has been using v4.07.00-based FEE routines with v4.07.01-based FEE routines fix the problem, or is the FEE potentially already corrupted, and will need to be re-written after installing FW with v4.07.01-based FEE routines?

--thx

Hello QJ,

We are working on our mitigation plan for this issue.  Having a correct understanding of the issue is critical for determining our handling.

Can you please provide an update on our query?

--thx

QJ,

I am interested in your responses to the questions posed by 1138.

Thanks,

Dave Crose

QJ,

I am interested in your responses to the questions posed by 1138.

Thanks,

Dave Crose