- 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-20-2017 11:02 AM
I'd like to use the EFM8SB1 with the UART boot loader for production programming. I have the starter kit to test and I found the Errata that states chips before 1544 will not have the bootloader installed. The starter kit has a 1511 dated chip. I can use Simplicity Studio to compile and load the uart boot loader but the Errata also mentions the factory bootloader won't work pre-1544. That appears to be the case since I can't communicate with the chip via the UART pins after loading it on the starter kit board.
Is there any way to test this on the starter kit?
Did I miss something?
04-20-2017 04:41 PM
You can first download the appropriate bootloader HEX file and then in your own user program add a scanning of the ISP pin at RESET and then jump into the bootloader.
In the attached example the "start bootloader manually" jump will not work on older devices because of hardware bug so "start bootloader forced" jump needs to be used with the appropriate address of the bootloader HEX file.
04-20-2017 09:43 PM
I did not test this on the EFM8SB1 STK, but it looks like the post mentioned by@LB only cover EFM8UB1. I am wondering if they could share same issue. I strongly suggest you use a EFM8SB1 device with new date code that support the bootloader.
My views are my own and do not necessarily represent the views of Silicon Labs
04-21-2017 09:27 AM - edited 04-21-2017 09:32 AM
Bootloader enabled devices have the ability to check to see if they should jump to the bootloader or the application after a reset, before code starts running. The older devices don't have this capability. However, you can change this by mimicking this function in the bootloader and application firmware.
Firstly, the bootloader image should contain a jump to the bootloader at the reset vector 0x0000. You can do this by adding the following code to the boot_startup.asm file in the bootloader project:
?BL_JUMP SEGMENT CODE AT 0 RSEG ?BL_JUMP LJMP boot_start
So, if there is no application, this will jump automatically to the bootloader.
Now, you need to modify your application code to mimic the bootloader capable parts' additional functionality. I've done this in the SILABS_STARTUP.A51 file of an application, since this is where you can insert code that effectively runs before your application. In here, we'll simply need to check to see if the bootloader exists. If it does, we'll jump there first and it will perform the other checks to see if we should go to the application.
However, in this case, we'll also need to determine whether we just came from the bootloader, since we technically are the application. Without this, we would get stuck in a loop - jumping from the application to the bootloader, back to the application, back to the bootloader, etc. I used R7 to store a particular value to say that we've just come from the bootloader. Here is the modified SILAB_STARTUP.A51 file:
CSEG AT 0 ?C_STARTUP: LJMP BootloaderCheck RSEG ?C_C51STARTUP #include "efm8_device.h" #define BL_SIGNATURE 0xA5 BootloaderCheck: ; Read and test R7 to see if we've already entered the bootloader ; since the last reset. If so, we should skip to the application clr A mov A, #BL_SIGNATURE xrl A, R7 jz GotoApplication ; Read and test the boot vector enable byte (byte before Lock Byte) ; The signature is present if A is 0 (leave result in A) clr A mov DPTR, #(BL_FLASH0_LIMIT - 2) movc A, @A+DPTR xrl A, #BL_SIGNATURE ; Restore the DPTR mov DPTR, #0000h ; If the signature is present, jump to the boot vector jz GotoBootVector GotoApplication: clr A ; Restore A mov R7, #0x00 ; Restore R7 jmp STARTUP1 ; Jump to reset vector (use this to save a byte) GotoBootVector: ; A = 0, no need to restore mov R7, #BL_SIGNATURE ; Write 0xA5 to R7 to indicate we've bootloaded ljmp BL_START_ADDRESS ; Jump to boot vector
The full SILABS_STARTUP.A51 file is zipped and attached to this forum post.
- Rebuild the bootloader that contains a jump at address 0x0000 that jumps to the bootloader start address
- Replace the SILABS_STARTUP.A51 file in your application with the one attached to this post
04-21-2017 01:09 PM
Thank you for the replies everyone. I went ahead and replaced the chip on the starter kit. It had a much newer date code (1709) and seems to work just fine. I can program the chip over the UART.
When we were soldering on the chip, we used the starter kits' debug connector to ensure we had the solder job connected properly and everything was up. I then loaded the UART boot loader firmware and further tested programming from the UART.
In retrospect, I wish it would have been nice to see if the UART bootlader was enabled by default on the new chip. In our production product we're going to have the micro in a location without very many wires available for com and we'd like to use the uart as a one time program and then have our user program take over the communication.
Near as I can tell from all the documentation we can count on the new chips having the UART bootloader in place. Is this something that can be relied on?