- Silicon Labs Community
- Welcome and Announcements
- Silicon Labs Knowledge Base
- 8-bit MCU
- 32-bit MCU
- Bluetooth / Wi-Fi
- Other Products Category
- Optical/RH/Temp Sensor
- Other Products
- Hardware and Software Tools
- Simplicity Studio and Software
- General Discussions and Suggestions
- Chinese Forum
- Software Libraries
- Development Kits
- Reference Designs
- Third Party Tools
- White Papers
- Official Blog of Silicon Labs
- Chinese Blog
04-13-2017 07:43 AM
I have created a bootloader that after reset, reads the application program through UART1 using the BLEAPI protocol from the BLE bluetooth co-processor and writes the program to the EFM8's flash memory. The bootloader is around 600 bytes located in 0xF800 to 0xFBFF. It erases the first 123 blocks of flash memory before starts the loading process.
It runs perfectly in the simplicity studio debugger. However, when launched automatically after a reset, the data written into the EFM8 flash are corrupted. The bootoaded was executed ok because I have set up the bootloader to change LED colors to indicate the begin and the end of the bootloading process. I believe the reading from the BLE using the BLEAPI should also be ok because otherwise the error checking process will keep the bootloader running forever.
Is it possible that the bootloader writes to the flash too early after reset before the flash module is ready? However, the evidence is against this theory because the first 15 bytes were correct and also placed correctly. I am attempting to delay the launch of the bootloader to see if it makes any difference. What is the best way to delay the launch of the bootloader? Any other idea for the cause of this misbehavior? Any suggestion for me to try?
04-13-2017 03:54 PM
The bootloader is around 600 bytes located in 0xF800 to 0xFBFF.
What is the entry point of this loader, - did you keep the exact same entry address the original loader uses ?
However, the evidence is against this theory because the first 15 bytes were correct and also placed correctly... Any suggestion for me to try?
If it partly works, there are going to be clues there.
Change the bytes sent, and check what is erased, and what follows code sent.
04-14-2017 04:26 PM
After I added more troubleshooting code in the bootloaded which, from what I understand, only has the effect of adding more time between reading from the BLE and writing to the EFM8 flash memory, the bootloaded started to work correctly. I tested it by downloading a copy of modified Blinky to the BLE. The Bootloader is able to retrieve the firmware from the BLE, write the firmware into the EFM8 flash, reset and then blink the LEDs correctly. It is a big step forward.
I will try the real firmware next. While the Blinky is only 260 bytes, the real firmware is almost 60 k.
Thank you again.