Download failure with CRC mismatch

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

cross mob
Anonymous
Not applicable

I'm facing download failure issue and the end of log as following:

---------

Download minidriver successfully had written 21 bytes to address 0x00203C1F

Download minidriver successfully had written 8 bytes to address 0x002043FC

Launch minidriver at 0x00201000 succeeded

Download config successfully had written 40 bytes to address 0xFF000000:  01 08 00 F0 00 00 62 08 C0 5D 89 FD 04 00 FF FF FF FF 40 06 00 97 6F 16 6A 73 20 02 0A 00 80 05 00 00 40 01 00 00 00 04

Downloaded 0 code bytes ( 0.0%) and 40 data bytes ( 0.5%). Verified 0 code bytes ( 0.0%) and 0 data bytes ( 0.0%).   Current state: Terminated with error

A total of 1 contiguous memory areas were filled:

[FF000000..FF000027] DATA (40 bytes)

CRC mismatch while checking 40 bytes starting at address 0xFF000000; host computed A1A68F21, firmware computed 213E3225

---------

I'm using BCM20736 chip, and there is only EEPROM device on IIC bus, no other iic device.

Pls give me some advice, thanks.

0 Likes
1 Solution

If we set I2C address of EEPROM to 0xA2(write) & 0xA3(read), how do I change download config file?

ROM always uses 0xA0 as the slave address of the EEPROM.  I don't think you can change this as it is used to determine whether or not the part comes up in App or Programming mode.

For instance, if you look at the boot button on the TAG3 board, the way we use this to connect SDA to Vdd/Vio to recover is probably not optimal for the following reason.

SCL and SDA are both open-drain configuration and the pull-ups pull the signal high while the HW drives it low (never drives high, but floats the output pad leaving the pull-up to pull the line high). If you put a scope to either of these lines on the board when the firmware accesses these, you will see that high to low transitions will be very sharp while low to high transitions will be pretty slow due to the intrinsic RC.

If you connect SCL/SDA to Vdd, then when the HW block drives SDA low, there will be a direct short (though momentary) between Vdd and GND, which is not ideal (even if the recovery works fine). This will happen pretty early during boot because the ROM always uses 0xA0 as the slave address of the EEPROM and you can see that there are repeated 0s in this sequence (and the shorts) which could do bad things to the supply or the chip.

Shorting to GND on the other hand, is safer because that is what happens when there is a 0 bit on the bus and there is a 10K pull-up which will limit the current to something within the max ratings of all components on this line.

And yes, if this is not correctly understood by the firmware, the part comes up in recovery mode and users will NOT be able to program.

View solution in original post

0 Likes
21 Replies