- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
Solved! Go to Solution.
- Labels:
-
Recovery
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jcardona,
Yes, your description is same with my understanding.
Best Regards,
Ocean(Zhaohua) Sun
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.