- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
when download cgs into BCM20732,means write all cgs into EEPROM(cgs file first type will write to EEPROM first type )?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
> Please tell me that cgs file first byte will write to EEPROM first type and the last type w
This is not the case. The cgs file is in a user readable format. The image in the EEPROM will not be.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, the contents of the cgs file are processed by the download tools and are then written to the EEPROM. There is only a rough relation between the cgs file and the contents of the EEPROM.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1.I do not kown what it is mean a rough relation.Please tell me that cgs file first byte will write to EEPROM first type and the last byte will write to sizeof(cgs file) Byte in EEPROM is right or not?
2.How the WICED-Smart-SDK-1.1.0\Apps\RAM\ota_firmware_upgrade work? The upgrade opreate will overwrite the original file in EEROM?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
> Please tell me that cgs file first byte will write to EEPROM first type and the last type w
This is not the case. The cgs file is in a user readable format. The image in the EEPROM will not be.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks!
How the WICED-Smart-SDK-1.1.0\Apps\RAM\ota_firmware_upgrade work? The upgrade opreate will overwrite the original file in EEROM?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No, it will not. The EEPROM (or SF) is split into (about) equal halves, one of which is 'current' and the other is the 'upgrade' half. When upgrading, all new app code goes into the upgrade half. Once complete, the upgrade half is read back and verified. If this is successful, the upgrade half is marked as good and read back to ensure that it was marked correctly. If this is successful too, then the current half is marked as invalid and then the device will reboot. When it reboots, what was current before will now be invalid and so marked as upgrade half and what was the upgrade half before will be marked as the current half and the app will be loaded from the new current half.