MCF8315C-Q1: EEPROM values got reset during test-run

Hi Aman,

Please refer to the FAQ link (+) [FAQ] MCF8316C-Q1: General EEPROM Write procedure recommendations - MCx83xx family (MCF8316A, MCF8316C-Q1, MCF8315A, MCF8315C(-Q1), MCF8329A, MCT8316A(-Q1), MCT8315A, MCT8329A) - Motor drivers - INTERNAL forum - Motor drivers - INTERNAL - TI E2E support forums

We highlight device conditions in order to program EEPROM successfully. 

Jus a quick note, EEPROM write/read should not be done while device is in Motor Run state, we should put device to Motor Idle state.

Then proceed for write instruction and before power cycling or issuing motor run command make sure to provide minimum delay of 500ms, verify EERPOM write bit is cleared which indicates successful completion and then power cycle.

Thanks and Best Regards

Venkatadri S

Hi Venkatadri,

Please understand that there was no issue in flashing the EEPROM. The motor driver was working as expected. The issue only came after a long time and no deliberate flashing attempt was made after the first flash. Hence I wanted to know if there is any other condition (line undervoltage, brown-out etc) where EEPROM data can get corrupted, leading to the data getting reset.

The datasheet mentions a minimum delay of 300ms after sending EEPROM write command, so please let me know the reason for that extra 200ms (regardless, I am sure that the EEPROM was flashed properly). However I couldn't find any mention about the connection between EEPROM_WRT bit and EEPROM write status in the datasheet. Please mention the section, incase I am missing it.

Also the link you provided says "Page not found"!

Hi Aman,

The link is not active yet, sorry I did not verify it as it is about to release.

I am copying the image here which answers your question about minimum delay

About the issue, can you confirm in your application are there anywhere EEPROM write function exists and when it is invoked?

This is a common issue, may applications call EEPROM write during every power up and verifies if the configuration is not matching.

Reasons

1. Let us say when EEPROM write started and there is power drop which leave in complete EEPROM writes.

2. Power cycling after EEPROM write instruction without waiting for minimum delay.

Can you share some data which is corrupted and expected value?

Thanks and Best Regards

Venkatadri S

Also can you please let me know if there is any meta-data section for the EEPROM, that can give some hint on how many times the EEPROM was flashed or something similar?

Hi, 

Unfortunately I don't have the data of the corrupted EEPROM. But as the buck output reverted to 3.3V and slave ID also became zero, I suspect it must have reset to 0.
I am checking the application code and there is no EEPROM write happening on power-up. Like the EEPROM flashing part is a separate section of code which is kept disabled. However, I don't completely deny the possibility of an accidental write, but just wanted to know other possibilities. As accidental EEPROM write is verifiable at my end, but if there is any other clue, it would be very helpful

One more thing, can you please confirm that the state of shadow registers are same as value in EEPROM upon power-on reset? In case shadow to EEPROM transfer command is given without writing valid values in the shadow registers, the state of EEPROM will be maintained correct?

Hi Aman,

The EEPROM endurance and programming voltage are good. 

Only if any issue with the sequence like mentioned before EEPROM can be changed.

Upon power up device copies configuration from EEPROM to shadow registers.

Did you connect GUI and run I2C address find? If the values are changed device may have different I2C address than 0x1.

Can you confirm about I2C find?

How many devices you have like this?

Thanks and Best Regards

Venkatadri S

Thanks for the confirmation.
I had re-flashed the MCF by keeping slave ID as 0 and it was successful. As I mentioned, this suspicion (of slave ID being zero) came from BUCK output reverting back to 3.3V.
Till now only one instance has been identified.

Hi Aman,

How about other features, are they working properly? Motor parameter and other tuning?

Anyway, please make sure to follow the EEPROM write flow as mentioned in the earlier thread.

Thanks and Best Regards

Venkatadri S

Yes Venkatadri, everything else is working fine. 

Wanted some clarification on the below note given in datasheet

Currently this is being violated, as this is not feasible to insert 100us delay after every byte as this will severely hamper the communication rate and hence the overall functionality. Can you please comment on this.

Hi Aman,

We do not need this, device implements clock stretching.

When motor is running there can be bandwidth issue, hence we recommend 100uS delay or us lower I2C clock frequency.

Thanks and Best Regards

Venkatadri S