- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Solved! Go to Solution.
- Labels:
-
Debug
-
FlashEEPROM
-
HCI UART
-
I2C
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.