Does Fapi_doBlankCheckByByte() checks for ECC Space when the address parameter is DATA Space

Pashan,

I think this is covered in the documentation - SPNU501F -

If you have to disable ECC in order to correctly blank check the EEPROM array then you would also need to blank check the ECC area separately.    

Hello Anthony,

When EDACEN=0x0A and EDACMODE = 0x05 as well as EE_ALL1_OK=0, then does the function Fapi_doBlankCheckByByte() check for BLANK correctly when the address range is with FLEE Bank 7 DATA Space?

Please confirm.
Thank you.
Regards
Pashan

Hello Anthony,

My previous mail is for DATA Space only. Under the above condition if all the DATA cells are erases then Fapi_doBlankCheckByByte() will see values as 0xFF for DATA space and it will pass.
Fapi_doBlankCheckByByte() doesn't read internally ECC Space is the parameter to the function is within DATA Space. That's what I am assuming.

Are all these correct?

Thank you.
Regards
Pashan

Pashan,

I checked the source code and it is not trying to match up a certain byte in data space with it's corresponding ECC value and check that both are blank, it only checks the data space.

Correction - it only checks the range that you are asking it to.  If you ask for data space, it checks data space but doesn't check the corresponding ECC space.

But in the particular example we've been talking about that means the EEPROM data space.

Pashan,

Sorry - I also missed something in the bitfield values you asked about - you were asking about ECC enabled and EE_ALL1_OK = 0 not 1...  that's not going to work - you will get ECC errors during the blank check.

You need to have ECC disabled when you are running the blank check like the manual explains.

Hello Anthony,

I agree that we will get ECC Errors. But because all the DATA Space is in ERASED State [0xFF], will the function Fapi_doBlankCheckByByte() tell me that ADDRESS Range in question is BLANK irrespective of ADDRESS Value?

I am asking this question because if don't have source code for Fapi_doBlankCheckByByte().
Thank you.
Regards
Pashan

Pashan,

Sorry - I don't understand the question.   ECC would be on,  so there would be ECC errors and some of these would get 'corrected' to return an non 0xFF value while others would be uncorrectable.    What functionality would you want under these conditions?

Hi Pashan,

You are right that EDACMODE=0x5 is no correction - but in this case every error is treated as uncorrectable and there will be signalling to the ESM module that an uncorrectable error occurred.    I read that section incorrectly.

However, I guess I still have an issue answering this question without understanding that there is a good reason to raise it.   Because if you are asking me to tell you the unspecified behavior of the particular implementation of the EEPROM emulation library today - based on looking behind the curtain at the code - this seems like a recipe for problems down the road.   When it's mainly a clarification like does the ECC area get blank checked at the same time as data - where that info should be in the user's guide today - I'm ok w. answering.    But this particular question seems to be regarding a mode that the library documentation says 'don't do' ...    

That type of question we might want to take offline and would typically only get into if it's 'too late' -- like if you already have code in production that is doing this and you need to understand the impact.   But if it's new development that we're talking about then I think the correct thing to do is understand the reason why you would need to leave the ECC enabled - and see if the team developing the library agrees to add this use case to the specified behavior.

Sorry to be difficult here but I don't want to give you an answer that will cause problems down the road.