BCM20737S reasons for corrupt EEPROM

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

cross mob
KoM_2154881
Level 3
Level 3
First like received First like given

Every now and then (very rarely), we have this issue where a download will fail with no apparent reason and then we would not be able to

download the firmware anymore. We have to bring the part into download mode by holding the SDA high and then do the recovery procedure.

From looking at other posts with similar problems, I can see two problems that could lead in download failure: 1) I2C line load or interference

and 2) having a sudden disconnection of the cable or power down. I assume here that the right 3.3V cable is used.

In the post: Rebooting/Recovery of a BCM20737S **HELP**  the answer given states that it common to have EEPROM corrupted if you download and

test new firmware. I am wondering if there is an explanation what could cause something like that, assuming we don't have I2C and power problems.

Is this something that we can avoid or this is something out of our control that could happen anytime?

Thanks

Kostas

0 Likes
1 Solution
BoonT_56
Employee
Employee
500 likes received 250 likes received 100 likes received

When the power supply is applied, the user must ensured that the serial ports are initialized properly before commencing any download. This can be done from the Device_Manager/Ports in Windows. This is the reason why a "wait for 3s" is recommended in recovery steps. I thought this could be an issue in an automated production line where this type of programmings were carried out. Other times, it could be an issue of poor/misaligned contact between the pogo pins and the PCB board.

View solution in original post

3 Replies
BoonT_56
Employee
Employee
500 likes received 250 likes received 100 likes received

When the power supply is applied, the user must ensured that the serial ports are initialized properly before commencing any download. This can be done from the Device_Manager/Ports in Windows. This is the reason why a "wait for 3s" is recommended in recovery steps. I thought this could be an issue in an automated production line where this type of programmings were carried out. Other times, it could be an issue of poor/misaligned contact between the pogo pins and the PCB board.

Could you let us know if the EEPROM program image is checksum protected?  If it is, what is the recover process when the checksum failed?

0 Likes

There is a crc check when the image is first being downloaded onto the eeprom but in subsequent boot-ups, no. If there is anything wrong, user has just got to recover it.