- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all,
I loaded the .ota.hex file instead of .hex file by mistake into two BCM20736S modules and I'm no more able to program them.
I used chipload.exe from command line and SDK 2.1.1.
I have some question about this:
1) Is there any way to recover modules?
2) I guess there's a different addressing into two hex files, what's exactly the differece?
3) It's normal that modules doesn't work with ota.hex files if not loaded via OTAFU. Why does modules are no more programmable?
I was thinking that only user application resides in external flash, while stack and BOOT is in CPU flash. If all the logics that handles programming is not into potentially corruptable area, why this logics does not work now?
Thank you
Solved! Go to Solution.
- Labels:
-
FlashEEPROM
-
Recovery
-
SDK 2.X
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
thank you for reply.
I have a custom board with BCM20736S module but fortunately I have SDA pins on a test point.
I performed this procedure:
I grounded SDA trough 100 ohm resistor
hci serial connected.
turned on and wait about 5 sec
I released SDA
programmed with sdk and recover option.
Module is still not programmable
then I tried to connect serial after SDA release. Perhaps BOOT does something strange due to wrong fw:
I grounded SDA trough 100 ohm resistor
turned on and wait about 5 sec
I released SDA
hci serial connected.
programmed with sdk and recover option.
Module is now programmable!
There's something strange in boot procedure, seems that HCI serial connected influences boot even if no application is detected.
Anyway thank you, I solved issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
i think the below thread addresses your qns, especially on (2)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The recovery procedure is outlined here in the WICED Smart Quick Start Guide (SDK 2.x and TAG3 Board)
The Over The Air Firmware Update process is described here in Software Over-The-Air Secure Firmware Update
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
thank you for reply.
I have a custom board with BCM20736S module but fortunately I have SDA pins on a test point.
I performed this procedure:
I grounded SDA trough 100 ohm resistor
hci serial connected.
turned on and wait about 5 sec
I released SDA
programmed with sdk and recover option.
Module is still not programmable
then I tried to connect serial after SDA release. Perhaps BOOT does something strange due to wrong fw:
I grounded SDA trough 100 ohm resistor
turned on and wait about 5 sec
I released SDA
hci serial connected.
programmed with sdk and recover option.
Module is now programmable!
There's something strange in boot procedure, seems that HCI serial connected influences boot even if no application is detected.
Anyway thank you, I solved issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for providing an update as I'm sure others will find this information useful as well.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Interesting info. I have recovered many times without needing to disconnect the hci during power up... but I do not use the 100 ohm resistor. Good to hear you were able to recover. Do you think the 100 ohm resistor combined with voltage from the Hci prevented entering recovery mode? Maybe if you are curious you can try it without the resistor.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I used 100 ohm resistor only to limit currents, just in case output is effectively driven, and not used as open drain.
Today I recovered another unit with same method.
I don't know why starting with hci serial connected makes procedure fail. There is no electrical reason because we are speaking of different pins. I think instead this influences somehow boot logic.