Trying to understand programming failure and recovery process on BCM20736S

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

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

I am not sure what is causing this issue, but for clarification purposes, the EEPROM includes BD ADDR (Bluetooth Device Address), Patches and Bonding/Pairing information only.

When programming the part, the application will be automatically loaded to EEPROM initially, then to internal RAM for execution.  It is then stored in EEPROM and on boot up it will also be loaded from EEPROM into RAM for execution.

At a lower level, the SDK downloads a minidriver to RAM and then runs it, it then pushes the code over the HCI uart to the minidriver which will then write to EEPROM.

Perhaps one of the others have an idea as to what is happening in this scenario.

leonid zhaohua maxsu phu arvinds j.t vik86

0 Likes
Anonymous
Not applicable

Hi mwf_mmfae,


Thanks for the additional info.  It definitely helps. 


But I still don't understand what is being read from EEPROM on normal reset, and why it is necessary.  I understand that the recovery procedure (pulling SDA high) just aborts that initial EEPROM access, and even after that, the chip can receive firmware just fine.  So 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.


Best,



0 Likes

Hi Jcardona,

As I known, no like "download helper" in EEPROM.

As I understanding, the boot firmware of 2073x always read the EEPROM after reset, but will be failed  if SDA line was pulled to VDDIO or GND, so boot firmware decide to enter the download mode.

For your issue, please check whether have abnormal access for the 1KB constant arry, like use the pointer to access the array, but out of range.

0 Likes
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

Hi Jcardona,

Yes, your description is same with my understanding.

Best Regards,

Ocean(Zhaohua) Sun

0 Likes
Anonymous
Not applicable

Very interesting to know the FW loader and checking the UART Rx line does NOT sit in ROM.
If it is part of the patch, the user image - where could I find this piece of code checking if UART Rx is active?

It would solve the problem to boot WICEDSense also when it is USB powered. Instead to cut the trace on CP2105 chip I would like change the logic there: it should check for the UART Rx just if a special button combination is pressed (e.g. both buttons pressed when booting). Otherwise it should not enter the FW loader just due to fact it sees a high value on this line.

It would make the WICEDSense use much more convenient, e.g. to run without battery and just with USB, even booting with USB only. No HW hacks needed.

Please, where is this piece of code?
Really sure it is part of my user image, does not sit in ROM?

0 Likes

My understanding that the firmware in ROM checks to see if a valid image is stored  in NVRAM (i.e. application mode), and if not found, the part enters programming mode

The part also enters programming mode if an external host pulls the HCI UART Rx line high.

It should also be noted that the SWD pins are muxed with HCI UART and are used in such a manner that the hardware and firmware can auto-detect the presence of SWD or the HCI host; this means that HCI based download (programming) and SWD (debugging) are mutually exclusive of one another.

0 Likes