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
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

Is this a custom board or the TAG3 development board?

If a custom board, what type of programming cable (USB to Serial) are you using to program the board (we recommend one in one of the many threads on this subject)

If a custom board, how are you managing the HCI UART RX line?  Is it pulled high?

Have you tried programming the custom board with one of the default programs included in the SDK?

As many have discovered here on the forum, bringing up custom designs for the first time is tricky.

The best bet is to start with the TAG3 development board and load your custom program onto it while understanding how the HCI UART is changing states from App to Programming mode.

Then, in an effort to emulate this on the custom board, ensure the state of the HCI UART and that the FTDI cable you selected matches the one we recommend.

0 Likes
Anonymous
Not applicable

Hi, mwf_mmfae

It is not TAG3 dev board, it is our board

The firmware is default program in SDK, hello_sensor.

From the log, the minidriver have been launched success. If can I think the HCI UART should be OK?

Based on the CRC mismatch on BCM20737S, the root cause should be the IIC.

But I remove the other iic devices, and only EEPROM device on IIC bus, the problem remains.

So pls give us more advice, thanks.

0 Likes

There is no issue downloading the hello_sensor app onto the tag3 reference board, using the cgs.exe and chipload.exe method executed from a console. For a start, what is the programming cable you are using? How are you doing the download?

Check out this thread for more details on downloading to custom boards. Ignore the tag2 and 20732 content.

Programming the TAG2/TAG3 Board using command line tools

0 Likes
Anonymous
Not applicable

Hi, boont

on my board, using the cmd: make hello_sensor-BCM920736TAG_Q32 download recover DEBUG=1 UART=COM8    ----- it is failed, the download.txt show CRC mismatch when firstly writing 40 bytes to address 0xFF000000.

on wiced_sense board, using the cmd:make hello_sensor-BCM920736TAG_Q32 download DEBUG=1 UART=COM17  ---- it is OK, the download.txt show Download config successfully had written xx bytes to address 0xFF00xxxx.

Based on the download log, can you help us lock the problem?

By the way, my board using the 512Kbit(64KByte) EEPROM, any script or makefile must be modified for this EEPROM? Can minidriver support it?

Thanks.

0 Likes

It is not straightforward to pinpoint the issue. Based on the work on your own board (failed) and the SENSE board (passed), it somewhat guides me in the direction of hardware.

Your EEPROM size is OK as we used this size on the tag3 too. We support these brands: Microchip® 24LC128, Microchip 24AA128, and ST Micro® M24128-BR.

I suggest we take a step back and use the IDE to recover your own board first.

And one note on the HCI Rx pin:

HCI UART Rx = High (Programming mode)

HCI UART Rx = Low (Application mode)

0 Likes
Anonymous
Not applicable

Hi Boont

In our schematic, UART Rx is pulled down to GND by 10k resistor. Should I pull it up to Vdd?

捕获.PNG

It's just like TAG3 reference design:

捕获2.PNG

Best Regards

Edward

0 Likes
Anonymous
Not applicable

Since we use ST Micro M24512, not M24128-BR, should we change some config file ? and how?

Thanks advanced!

0 Likes

It should work just fine. Do ensure the following:

1) Supply voltage of the eeprom

2) correct pull-up resistors (4.7Kohm) on the I2C bus

3) Write-protect pin is muxed to P1

4) Use 0xA0 for eeprom

0 Likes
Anonymous
Not applicable

1 2 4 are ok.

we just connect WP  to GND. Should I change it to P1 pin?

BR

EDWARD

0 Likes

I think this thread answers your question on the WP pin: [BCM20736] The EEPROM Write Protect

Firmware (and the Minidriver) essentially relies on WP residing on P1.

0 Likes
Anonymous
Not applicable

Yes, we just use P1 as SPI interface for ADI sensor, like them. So we couldn't use P1 as WP of EEPROM.

But theoretically, even I connect WP to GND, minidriver/firmware still could write EEPROM, right? Because WP=low means no write protecting, CPU could write data into EEPROM at any time.

Is there a way to ignore WP in uart_disable_EEPROM_WP_PIN1.hex in case your firmware use WP signal for special page writing mode? Or, is there other minidriver hex file instead of uart_disable_EEPROM_WP_PIN1.hex?

Best Regards

Edward

0 Likes

Are you using a SIP module or CoB design? And we cannot ignore that as P1 has been hardwired to the WP pin of the eeprom.

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

With the SIP module, we even go to the extent of including a 10Kohm pull-up resistor so as just to ensure that P1 is in a known state (high).

0 Likes
Anonymous
Not applicable

We are using CoB. But it still report same error even we add a wire from 20736 P1 to EEPROM WP. Is there a special minidriver to test EEPROM and report detail error code between 20736 and eeprom? I guess eeprom is not work fine, but don't know how to debug it.

Best regards

Edward

0 Likes

There is not a special minidriver needed to use either Serial Flash or EEPROM as the NVRAM source.

If you look at the TAG3 evaluation board (uses the SoC as well), it can use either.  By default the board is setup to use EEPROM connected via I2C.  To troubleshoot, the best bet would be to start with the standard TAG3 configuration (all default firmare assumes this HW configuration), then work slowly to add all of your custom modifications to GPIO/HW.

0 Likes
Anonymous
Not applicable

Hi mwf_mmfae & Bont

I'm studying cgs & btp file. Noticed start address of MiniDriver is 0x00201000 and  start address of Config is 0xFF000000. Actually EEPROM is just 64Kbytes, why these address is so high? Is there a virtual address map?

I guess 0x00201000 is mapping into internal RAM, and 0xFF000000 is mapping into beginning of EEPROM. Is that right?

If we use different EEPROM( it's not in 20736 spec), should we change address mapping?

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

If we want set I2C speed to 100KHz, instead of 400KHz, could I change cgs file?

Thanks

Edward

0 Likes

If we want set I2C speed to 100KHz, instead of 400KHz, could I change cgs file?

Yes.

Just add this to the .cgs file in the platform directory you are using:

ENTRY "I2C Speed"

{

    "Speed" = "400 KHz"

}

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.

0 Likes
Anonymous
Not applicable

For customer's board, recover mode is mandatory for first downloading?

Actually we use 0xA0/0xA1 for EEPROM. I just wonder weather we could modify I2C address in config file.

The issue is, there is NOT I2C signal in our board(based on 20736+ST M24512 EEPROM) while we try to download,

and in recorver mode, we could download minidrvier into 0x00201000, but it's failed at 0xFF000000 for config file downloading.

Now I have no idea how to debug it.

Thanks.

0 Likes

If we use different EEPROM( it's not in 20736 spec), should we change address mapping?

This thread applies to Serial Flash, but I believe the same concept should apply to EEPROM: External Serial Flash for wiced smart BCM20736

We can ask the developers if this assumption is correct.

0 Likes
Anonymous
Not applicable

thinker fujianjun

is this still an issue?

0 Likes