cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Smart Bluetooth

Anonymous
Not applicable

Hi,

We've been following the recovery steps provided by mwf_mmfae in this thread:

How to recover BCM20736S on custom board?

but we still observe certain failures in our firmware that make us doubt of our understanding of the boot/recovery process.  Let me start with the facts:

1. We have a development firmware image that compiles, downloads and runs fine EXCEPT that after loading that image, the device cannot be re-programmed normally.  Let's call this the "faulty" firmware.

2. We are able to recover by asserting reset while holding SDA high (VDD).  After doing that, we can download the "faulty" firmware again, with the same behaviour described in 1.

3. We can "correct" our firmware image by simply reducing the program size.  By #ifdef'ing out a 1 kbyte constant array in the code, we obtain a firmware image that can now be re-programmed normally over and over.

4. The "faulty" firmware is this size:

Patches start at            0x00204568 (RAM address)
Patches end at              0x00205280 (RAM address)
Application starts at       0x00204F9C (RAM address)
Application ends at         0x00208D1C (RAM address)

Patch size (including reused RAM) 3352 bytes
Patch size                        2612 bytes
Application size                 15744 bytes
                                ------
Total RAM footprint              18356 bytes (17.9kiB)

5. The "corrected" firmware is this size:

Patches start at            0x00204568 (RAM address)
Patches end at              0x00205280 (RAM address)
Application starts at       0x00204F9C (RAM address)
Application ends at         0x0020890C (RAM address)

Patch size (including reused RAM) 3352 bytes
Patch size                        2612 bytes
Application size                 14704 bytes
                                ------
Total RAM footprint              17316 bytes (16.9kiB)

Now some questions...

1.  Our theory is that the "normal" download requires some firmware that is stored on EEPROM, let's call that a "download helper".  And that our "faulty" firmware overwrites the area where the "download helper" is stored.  Is that correct?

2.  If 1 is correct, how can we find the exact address where the "download helper" is stored?  We would then include a check in the build scripts to raise a warning if a firmware build exceeds that memory address and avoid a painful recovery.  Makes sense?

3.  What is the purpose of the "download helper"?  Could we *always* program the device using the recovery sequence?  Are there any problems with that?  Seems to be more robust, and it also seems like this would allow us to use more of the EEPROM memory.

Thanks!

1 Solution
Anonymous
Not applicable

Thanks, zhaohua.

I will double check the code, as it seems, based on the responses, we should not be running into issues regarding EEPROM or RAM size.

But just to be sure I got it right, let me summarize my understanding of the download/recovery process and please let me if it is correct.

The code that checks the UART RX line and switches into download mode does not reside in ROM.  Instead, it is pre-compiled and linked with the firmware at build time.  That logic is then stored in the EEPROM with the firmware image.  After reset, the first step is to load that code from EEPROM, and only after that, the UART RX line is checked.  This is why a faulty EEPROM cannot be re-programmed: the check for the UART RX line might never get to be executed.

However, there is another way to enter download mode, and this happens when the EEPROM cannot be read at all.  This can be achieved by pulling SDA to VDDIO (btw, SDA to GND did not work for us, only VDDIO).  This method to enter download mode seems to always work.

Based on this, I am tempted at using *always* recovery mode to transition into download mode.  It's more reliable and has no side effects that we know of.  Is that correct?

Thanks,

Javier

View solution in original post

7 Replies