- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would like to update the application via the HCI-UART. I have read the
- AIROC™ HCI Firmware Download Guide
- AIROC™ HCI Control Protocol
- AIROC™ Over-the-Air Firmware Upgrade Library
When I sniff the ModusTool when it downloads firmware to the device, I have these phases,
- HCI_RESET - expected.
-
> 01 4d fc 05 1c d2 00 00 01 < 04 0e 05 01 4d fc 00 ab <fail>
- Mini-driver download
- Launch ram
- Update baud rate
- A strange response ... after baud change... < 04 0e 04 01 ce ff 00 ???
- Config/SS write
- CRC32
- Main image write
- CRC32
In 6, it looks like a response to a chip erase? Was this just garbage or does the mini-driver erase the flash?
Can I skip 7,8 if I just want to update the application software, but keep all MAC, etc initial parameters.
Is the packet in '2' of any consequence. Could I skip it. Is it documented?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @bpringlemeir ,
Can you please let us know from where you got the download log? Typically, download logs can be found in this location. I have attached my log for reference.
\build\CYW920719B2Q40EVB-01\Debug\download.log
The sequence of steps should be as follows:
1. HCI reset
2. Download Minidriver command. Opcode-> 0xFC2E
3. Write Ram - 0xFC4C
4. Launch RAM - 0xFC4E
5. Update baud rate -to 3M (Optional ) - 0x FC4E
6. Chip Erase (Optional - Do not issue if want to retain SS and VS section) - 0x FF CE
7. Write RAM (Only the regions that you wan to write , example only DS) - 0x FC4C
8. Verify CRC - 0xFCCC
8. Launch RAM - Download complete
Please note that the procedure for partial download and full download are the same. The only difference is that you do not issue Chip Erase command and you only write the DS region to the flash.
Bragadeesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @bpringlemeir ,
Can you please let us know from where you got the download log? Typically, download logs can be found in this location. I have attached my log for reference.
\build\CYW920719B2Q40EVB-01\Debug\download.log
The sequence of steps should be as follows:
1. HCI reset
2. Download Minidriver command. Opcode-> 0xFC2E
3. Write Ram - 0xFC4C
4. Launch RAM - 0xFC4E
5. Update baud rate -to 3M (Optional ) - 0x FC4E
6. Chip Erase (Optional - Do not issue if want to retain SS and VS section) - 0x FF CE
7. Write RAM (Only the regions that you wan to write , example only DS) - 0x FC4C
8. Verify CRC - 0xFCCC
8. Launch RAM - Download complete
Please note that the procedure for partial download and full download are the same. The only difference is that you do not issue Chip Erase command and you only write the DS region to the flash.
Bragadeesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The log was obtained by sniffing the serial link. Actually an USB-FTDI layer of the serial link. For instance, with usbmon on Linux and Wireshark. The one I cited was a commercial Windows sniffer.
Also, I don't see your download.log attached? I will look at generating my own. I did not know this feature existed. I see it in the ChipLoad.pl script now.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @bpringlemeir Looks like the attachment is missed. Attached with this response.
Bragadeesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you. It is interesting, our 20719-B2 tools/logs do not show the full packets. However, maybe this is due to the revision of software we use (v2.9.0). Also, our logs show a chip erase, so I think the sniffer may have missed this packet (but did see the reply).
I will try to use ChipLoad.pl directly instead of from the Eclipse UI. I think the data in '2' is from the DetAndId binary.
In 6, it looks like a response to a chip erase? Was this just garbage or does the mini-driver erase the flash?
As per the download.log, the ChipLoad.pl and 'chip_load' binary was performing a chip erase. The sniffer missed this command.
Can I skip 7,8 if I just want to update the application software, but keep all MAC, etc initial parameters.
As per accepted answer, this is possible.
Is the packet in '2' of any consequence. Could I skip it. Is it documented?
Believe this is from the 'DetAndId' binary.