Reply
Posts: 19
Registered: ‎06-28-2017
Accepted Solution

EFM8BB1 Firmware Upgrade Failed: Stuck in Bootloader Mode

Hi all,

 

We have Simplicity Studio v4 with the version 4.05 of the 8051 SDK tools installed, updated as of today (28 June 2017, Australian Eastern Standard Time).

It's connected to an EFM8BB1 Busy Bee dev kit.  The screenprint on the bottom says the board is "PCB5200 Rev A02"

 

Yesterday, everything was working happily.

 

This morning, there was a network failure here, so I moved to my other project on a different computer.

When I came back this afternoon and fired up SS, it told me there was a firmware upgrade available for my dev kit.  That's where things started to fall apart.  Every time I do the download, I'm now getting the message shown in the first attachment: "The kit is still in bootloader mode, it seems the installation failed.  Please try again."  I've now tried again about 10 times with the same result each time.

 

I've also tried re-booting the dev kit with the bootloader pin shorted to ground, but of course it's already in bootloader mode so nothing changed.

 

We do have peripherals attached to the port pins: Some LEDs and some photo sensors.  I was going to say that I was reluctant to remove them because of the difficulty of re-connecting in the same order, but they're all hooked up to plugs and it's actually easy.  With the connectors unplugged: same result.

 

The second attachment shows the details of the Jlink version. Note that after this screenshot was taken, I re-enabled the IDE and SDK and logged back into the SiLabs site.  No change.

 

I've just thought that I need to reset the PC as well.  I'll save this and report back later.

 

Posts: 19
Registered: ‎06-28-2017

Re: EFM8BB1 Firmware Upgrade Failed: Stuck in Bootloader Mode

After a reboot, the behaviour is still the same.  This time, I captured the console output:

 

C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\usb\usb_monitor.exe C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\usb\usb_monitor.exe -d -s
C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\inspect_emdll\inspect_emdll.exe C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\inspect_emdll\inspect_emdll.exe -slist -sn 000440087204
list: 17ef:6019@005:008[5&118F9870&0&8] 1366:0101@005:009[000440087204] 0403:6001@005:011[FTXO8EHN] 04f2:0841@005:010[5&118F9870&0&10]
# Simplicity Studio device detection

deviceCount=1

device(440087204) {
serialNumber=440087204
Connecting to device with serial number 440087204 .. ok.
EMDLL version: 0.14.1b246
J-Link DLL Version: 6.14`
AdapterType=JLink
adapterLabel=J-Link Silicon Labs
adapterId=5200A
adapterName=BRD5200A Rev. A02
adapterDescription=EFM8BB1 Busy Bee Starter Kit Board
adapterRevision=A02
adapterSerialNumber=170800286
adapterDate=0/0/0
adapterFirmware=0v8p4b61
adapterFpga=15v15p255b65535
adapterInBootloader=yes
supportedDebugModes=OFF,MCU,IN,OUT
debugMode=OFF
inferPart=no
supportsAEM=yes
supportsVCom=no
supportsEmucom=no
supportsIP=yes
boardCount=1
boardId[0]=5200A
boardName[0]=BRD5200A Rev. A02
boardDescription[0]=EFM8BB1 Busy Bee Starter Kit Board
boardRevision[0]=A02
boardSerial[0]=170800286
boardDate[0]=0/0/0
inferPart[0]=no
}

C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\jlink\jlink_configure.exe C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\jlink\jlink_configure.exe -sn 000440087204 -tif c2 -get-config
device(000440087204) {
serialNumber=000440087204
usbaddrmode=serial
serial=Serial number
usb0=USB #0
usb1=USB #1
usb2=USB #2
usb3=USB #3
jlinkspeed=65534
basefreq=48000000
mindiv=4
}
C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\commander\commander.exe C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\commander\commander.exe --apack adapter fwupgrade --serialno 000440087204 C:\SiliconLabs\SimplicityStudio\v4\offline\hwtools\firmware\S1015A_mcu_stk_firmware_package\S1015A_mcu_stk_firmware_package_0v15p3b761.emz
fwupgrade [> ] 0 out of 100, 0%
fwupgrade [==> ] 2 out of 100, 2%
fwupgrade [===> ] 3 out of 100, 3%
fwupgrade [====> ] 5 out of 100, 5%
fwupgrade [========> ] 10 out of 100, 10%
fwupgrade [========> ] 10 out of 100, 10% Checking manifest...
fwupgrade [========> ] 10 out of 100, 10% Checking if target is in bootloader...
fwupgrade [==========> ] 12 out of 100, 12% Checking if target is in bootloader...
fwupgrade [==========> ] 12 out of 100, 12% Package is usable
fwupgrade [==========> ] 12 out of 100, 12% Deleting previous firmware...
fwupgrade [==============> ] 17 out of 100, 17% Deleting previous firmware...
fwupgrade [==============> ] 17 out of 100, 17% Installing files...
fwupgrade [================> ] 19 out of 100, 19% Installing files...
fwupgrade [=================> ] 21 out of 100, 21% Installing files...
fwupgrade [===================> ] 23 out of 100, 23% Installing files...
fwupgrade [====================> ] 25 out of 100, 25% Installing files...
fwupgrade [======================> ] 27 out of 100, 27% Installing files...
fwupgrade [========================> ] 29 out of 100, 29% Installing files...
fwupgrade [=========================> ] 31 out of 100, 31% Installing files...
fwupgrade [===========================> ] 33 out of 100, 33% Installing files...
fwupgrade [=============================> ] 36 out of 100, 36% Installing files...
fwupgrade [===============================> ] 38 out of 100, 38% Installing files...
fwupgrade [================================> ] 40 out of 100, 40% Installing files...
fwupgrade [==================================> ] 42 out of 100, 42% Installing files...
fwupgrade [====================================> ] 44 out of 100, 44% Installing files...
fwupgrade [=====================================> ] 46 out of 100, 46% Installing files...
fwupgrade [=======================================> ] 48 out of 100, 48% Installing files...
fwupgrade [========================================> ] 50 out of 100, 50% Installing files...
fwupgrade [===========================================> ] 53 out of 100, 53% Installing files...
fwupgrade [============================================> ] 55 out of 100, 55% Installing files...
fwupgrade [==============================================> ] 57 out of 100, 57% Installing files...
fwupgrade [================================================> ] 59 out of 100, 59% Installing files...
fwupgrade [=================================================> ] 61 out of 100, 61% Installing files...
fwupgrade [===================================================> ] 63 out of 100, 63% Installing files...
fwupgrade [====================================================> ] 65 out of 100, 65% Installing files...
fwupgrade [======================================================> ] 67 out of 100, 67% Installing files...
fwupgrade [========================================================> ] 69 out of 100, 69% Installing files...
fwupgrade [================================================================> ] 79 out of 100, 79% Installing files...
left: 1366:0101@005:009[000440087204]
fwupgrade [================================================================> ] 79 out of 100, 79% Resetting target...
fwupgrade [================================================================> ] 79 out of 100, 79% Waiting for kit to restart...
fwupgrade [================================================================> ] 80 out of 100, 80% Waiting for kit to restart...
fwupgrade [================================================================================] 99 out of 100, 99% Waiting for kit to restart...simplicity_commander [ERROR: The kit is still in bootloader mode, it seems like the installation failed. Please try again.]

fwupgrade [================================================================================] 99 out of 100, 99% Waiting for kit to restart...
C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\inspect_emdll\inspect_emdll.exe C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\inspect_emdll\inspect_emdll.exe -slist -sn 000440087204
arrived: 1366:0101@005:009[000440087204]
# Simplicity Studio device detection

deviceCount=1

device(440087204) {
serialNumber=440087204
Connecting to device with serial number 440087204 .. ok.
EMDLL version: 0.14.1b246
J-Link DLL Version: 6.14`
AdapterType=JLink
adapterLabel=J-Link Silicon Labs
adapterId=5200A
adapterName=BRD5200A Rev. A02
adapterDescription=EFM8BB1 Busy Bee Starter Kit Board
adapterRevision=A02
adapterSerialNumber=170800286
adapterDate=0/0/0
adapterFirmware=0v8p4b61
adapterFpga=15v15p255b65535
adapterInBootloader=yes
supportedDebugModes=OFF,MCU,IN,OUT
debugMode=OFF
inferPart=no
supportsAEM=yes
supportsVCom=no
supportsEmucom=no
supportsIP=yes
boardCount=1
boardId[0]=5200A
boardName[0]=BRD5200A Rev. A02
boardDescription[0]=EFM8BB1 Busy Bee Starter Kit Board
boardRevision[0]=A02
boardSerial[0]=170800286
boardDate[0]=0/0/0
inferPart[0]=no
}

C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\inspect_emdll\inspect_emdll.exe C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\inspect_emdll\inspect_emdll.exe -slist -sn 000440087204
# Simplicity Studio device detection

deviceCount=1

device(440087204) {
serialNumber=440087204
Connecting to device with serial number 440087204 .. ok.
EMDLL version: 0.14.1b246
J-Link DLL Version: 6.14`
AdapterType=JLink
adapterLabel=J-Link Silicon Labs
adapterId=5200A
adapterName=BRD5200A Rev. A02
adapterDescription=EFM8BB1 Busy Bee Starter Kit Board
adapterRevision=A02
adapterSerialNumber=170800286
adapterDate=0/0/0
adapterFirmware=0v8p4b61
adapterFpga=15v15p255b65535
adapterInBootloader=yes
supportedDebugModes=OFF,MCU,IN,OUT
debugMode=OFF
inferPart=no
supportsAEM=yes
supportsVCom=no
supportsEmucom=no
supportsIP=yes
boardCount=1
boardId[0]=5200A
boardName[0]=BRD5200A Rev. A02
boardDescription[0]=EFM8BB1 Busy Bee Starter Kit Board
boardRevision[0]=A02
boardSerial[0]=170800286
boardDate[0]=0/0/0
inferPart[0]=no
}

 

 

I should have mentioned that I have actually done a search for this problem, on the assumption that it's been solved for somebody else.  Apparently, no, it hasn't been.

 

Regards,

 

Geoff

Posts: 2,108
Registered: ‎10-14-2014

Re: EFM8BB1 Firmware Upgrade Failed: Stuck in Bootloader Mode

@GeoffField

Are you using the VCOM to upgrade the application FW to the STK through the UART booloader?

Do you see the com port number showed up in the "device manager"?

Do you have a chance to configure the debug mode to "MCU".

Denver

WeiguoLu
Posts: 19
Registered: ‎06-28-2017

Re: EFM8BB1 Firmware Upgrade Failed: Stuck in Bootloader Mode

Hi Denver,

 

Thanks for your reply.

 

I'll answer in more detail when I get back to that desk later today.  However, I have to ask: What is the "VCOM"?

 

I'm using the USB connection to connect to the board and hitting the "Upgrade Firmware" link in SS.

We're using the UART in the application firmware for data output, so yes: The COM port shows up in Device Manager.

I tried configuring the debug mode to MCU, but it gave me an error.  I'll try again when I'm back at that desk.

 

Regards,

 

Geoff

Posts: 19
Registered: ‎06-28-2017

Re: EFM8BB1 Firmware Upgrade Failed: Stuck in Bootloader Mode

I've just Remote Desktopped into my other computer.

 

I tried switching to MCU mode and it came up with the "helpful" error message: "EMLINK failed."  See the attached screenshot.

 

I've also checked Device Manager: The UART is connected to COM5 via an FTDI adaptor (except I have unplugged the UART connection at present).  The USB port is showing up as a "J-Link driver" under the "Universal Serial Bus controllers" item and the Properties page of it says "This device is working properly".

 

Regards,

 

Geoff

Highlighted
Posts: 65
Registered: ‎05-19-2016

Re: EFM8BB1 Firmware Upgrade Failed: Stuck in Bootloader Mode

Our 2 bits from our past experience in working and programming with the EFM8 devices...

 

1) The EFM8 series devices include a factory bootloader

 

2) It is the factory bootloader that permits the uploading, etc. to the flash inside the EFM8 over the UART / SPI and/or USB interface.

 

3) The USB interface you see from your kit is another micro acting like an USB to UART bridge. This does not mean that the UART related bootlader inside the target EFM8 CPU is stable and working.

 

4) Perhaps, the bootloader inside the EFM8 is no longer valid. For this reason, consider to source an USB to C2 interface tool which will be worth the investment -> use this external tool to wire up as shown in the following diagram and fix the corrupted bootloader and test again.

 

http://community.silabs.com/t5/8-bit-MCU-Knowledge-Base/Recovering-an-EFM8-STK-using-an-external-8-b...

 

Using an external C2 programmer, you should be able to take even a blank EFM8 CPU and reflash with code of your choice.

 

We designed our own PCIe to C2 spec programmer to allow for our designs to be programmed when out in the field. If there is a need, we will review to offer such a product to the public (ie. PCIe to C2 programmer with isolation, etc.).

Posts: 19
Registered: ‎06-28-2017

Re: EFM8BB1 Firmware Upgrade Failed: Stuck in Bootloader Mode

Thanks Mon,

 

That's the link I was looking for and failed to find.  Too much noise, not enough signal (and a filter that needs work, too...)

 

Regards,

 

Geoff

Posts: 65
Registered: ‎05-19-2016

Re: EFM8BB1 Firmware Upgrade Failed: Stuck in Bootloader Mode

No worries. Hope it works out for you. Where possible, try to keep the lead fly wires short as possible. Also, review the schematic for your kit to be sure that the C2 interface port pins are not fighting it out with anything onboard. You should be able to download the schematics for any kit using the Silicon Studio toolchain. Write back with your results either way. Good luck.

Posts: 19
Registered: ‎06-28-2017

Re: EFM8BB1 Firmware Upgrade Failed: Stuck in Bootloader Mode

Interesting comment on the recovery page:

 

"To prevent this from occurring in the future, it is recommended to add a very long delay after reset (> 200ms) when running programs that utilize low power modes such as Sleep or Snooze. Other methods that cause the device to exit these low power modes and stay in either Idle or Active modes will also allow the STK to again communicate to the device. "

 

I'm using the Idle mode in my code, and definitely not the Sleep or Snooze modes.  However, I've added a start-up delay to the code now to try to minimise the problem.

 

And we now have two bricked units, because we don't have a debugger yet (our hardware engineer has buying debuggers on his list of Things To Do: Urgent) and of the two working dev kits we now have, one is allocated for testing and the other for development (plus we don't have a connector to connect to the debug output).  Long supply chains are a nuisance.

 

Oh, and happy Independence Day to our USalien friends on the other side of the Pacific.

 

Regards,

 

Geoff

Posts: 65
Registered: ‎05-19-2016

Re: EFM8BB1 Firmware Upgrade Failed: Stuck in Bootloader Mode

Posts: 19
Registered: ‎06-28-2017

Re: EFM8BB1 Firmware Upgrade Failed: Stuck in Bootloader Mode

Your Google-fu is obviously stronger than mine ;-)

Posts: 65
Registered: ‎05-19-2016

Re: EFM8BB1 Firmware Upgrade Failed: Stuck in Bootloader Mode

@GeoffField, can you post the code chunk of code that led to your locked device? Would like to replicate and take a stab against our C2 programmer to recover. Apparently the other URL (above), someone posted that even the C2 tool could not recover their locked device. That is one nasty condition. We have full control of the timing on our C2 interface adapter.

 

Also, Digikey appears to have stock of the C2 adapter for 8 bit micros:

 

https://www.digikey.ca/product-detail/en/silicon-labs/DEBUGADPTR1-USB/336-1182-ND/807653?mpart=DEBUG...

Posts: 65
Registered: ‎05-19-2016

Re: EFM8BB1 Firmware Upgrade Failed: Stuck in Bootloader Mode

Your Google-fu is obviously stronger than mine ;-)

 

>> Yes indeed. You need to watch Kung Pow a few times to learn the ways my son.

 

http://www.imdb.com/title/tt0240468/

Posts: 19
Registered: ‎06-28-2017

Re: EFM8BB1 Firmware Upgrade Failed: Stuck in Bootloader Mode

Hi Mon,

 

Here's the main loop, very slightly edited for public posting:

 

 

int main (void)
{
    /* Set the clock rate */
    InitClock(CLKSEL_CLKSL__HFOSC, SYS_CLOCK_DIV);

    /* Set up the GPIO system */
    SetGpioDriveStrength(true, true, false);
    GpioEnableWeakPullup(false);

    /* Initialise the I/O channels */
    InitPlatform();

    /* Need to enable the cross-bar to get the I/O working */
    EnableCrossBar(true);

    /* Set up the ADC system */
    AdcInit();

    /* Set up the timer(s) */
    InitTimers();

    /* Set up the UART */
    InitUart();

    /* Enable all interrupts */
    ENABLE_INTERRUPTS();

    /* Initialise the workflow */
    InitWorkflow();

    /* Output the version string */
    UartPuts("Ready, redacted v" VERSION_STR "\r\n");

    /* Initialise the header info */
    PrintWorkflowHeader();

    while (1)
    {
        /* Idle until the timer hits */
        IDLE();

        /* Check if it's time to do something */
        RunWorkflow();

        /* Look after the watchdog */
        PatDog();
    } // Spin forever
}   /* main */

For reference:

  • SYS_CLOCK_DIV is equal to CLKSEL_CLKDIV__SYSCLK_DIV_1, so we're initialising the system clock to the full 24.5MHz.
  • SetGpioDriveStrength() is being used to set Ports 0 and 1 to high drive strength and 2 to low.
  • GpioEnableWeakPullup() is used to turn the weak pull-ups off (XBR2 &= (uint8_t)(~XBR2_WEAKPUD__PULL_UPS_DISABLED)Robot wink
  • InitPlatform() initialises the GPIO pins that we use for LEDs (as push-pull) and sensors (as open-drain)
  • EnableCrossBar() turns on the cross-bar (XBR2 |= XBR2_XBARE__ENABLED; )
  • AdcInit() initialises the ADC, as posted in my other thread: 12-bit ADC Mode on BB1 Giving Odd Results
  • InitTimers() sets up Timer 2 for a 100us interrupt and Timer 0 to provide a suitable clock for a 115200-baud UART channel.
  • InitUart() sets up the UART channel for 115200-N-8-1 mode and enables the interrupts.
  • ENABLE_INTERRUPTS() is a macro that simply sets the EA bit (IE_EA = 1Robot wink
  • InitWorkflow() sets up a few variables in the code that actually does the work (and sets up GPIO for push-pull mode on a couple of debug pins).
  • UartPuts() copies the passed-in string to a 40-character buffer and then squirts it out through the UART port.
  • PrintWorkflowHeader() iterates through the channels and timings used for the particular workflow we're implementing and uses UartPuts() to push a bunch of strings out the UART port.
  • IDLE() sets the IDLE bit and does the dummy move as suggested (PCON0 |= PCON0_IDLE__IDLE; PCON0 = PCON0Robot wink
  • RunWorkflow() does the actual work of the product.
  • PatDog() pats the watchdog (WDTCN = 0xA5Robot wink

If you'd like my version of any of these (apart from the RunWorkflow() code, which is commercially sensitive), I'd be happy to post them.

 

Alternatively, I can zip it all up and email it to you.

 

Regards,

 

Geoff

 

Posts: 19
Registered: ‎06-28-2017

Re: EFM8BB1 Firmware Upgrade Failed: Stuck in Bootloader Mode

Automatic emojis are a pain at times:  wherever I have a ";" and a ")" together, the web interface is displaying an emoji: Robot wink

Posts: 65
Registered: ‎05-19-2016

Re: EFM8BB1 Firmware Upgrade Failed: Stuck in Bootloader Mode

Noted your post with thanks.

 

An idea for you to explore for your bricked boards...

 

1) From our understanding, the offered timing of the programming tool cannot perform its function due to the code that is loading on your target CPU.

 

2) Our initial thought was to consider a tool with faster timing for the C2 interface. From the quick review from other posts, it is possible you may still not be able to hook into this bricked CPU. Worth testing still with the official C2 USB tool which is a valuable instrument for your lab. However, suspecting the internals are a locked USB based micro with hard coded C2 transactions. Not sure how much control the host PC will have on the C2 timing but still worth testing. We wrote our own code for the C2 interface from scratch so can play with the timing.

 

3) The other thought, in between the Kung Pow jokes, was to alter the timing of your CPU. That is, from memory, believe you target board is being clocked @ 25 Mhz. However, it is permitted to clock down to DC level. Why not replace the CPU clock with something really slow like 1 Mhz or so and then test again? The intent is to allow the existing JLINK tool to interrupt the code flow which @ 25 Mhz is too fast to intersect. Was trying to locate the schematics for the EFM8 Busy Bee board via SS4 toolchain but warm up the soldering iron and see if you can locate a slower crystal locally or in your lab for testing.

 

Very curious to hear your results. In theory it should work. Either use a faster C2 tool or slow down the bricked CPU so the existing tool can do its job..good luck.

Posts: 65
Registered: ‎05-19-2016

Re: EFM8BB1 Firmware Upgrade Failed: Stuck in Bootloader Mode

Ok, just downloaded the schematics for the Busy Bee board and it appears the clock is internal to the CPU so the idea of slowing down the clock is not viable. There is an external clock for the JLINK tool @ 16 Mhz.

 

So to summarize, some users but not all, have reported higher success in using the stand alone USB C2 tool by Silabs as compared to the JLINK interface present on your kit to recover bricked devices. Will dig up our EFM8 kits at the office and give it a whirl.

Posts: 19
Registered: ‎06-28-2017

Re: EFM8BB1 Firmware Upgrade Failed: Stuck in Bootloader Mode

One of our engineers/scientists just suggested holding down the reset key while standing on my left foot.

 

I omitted the standing on my left foot bit, but held down the reset key while powering the unit on.  Lo and behold, everything came good again.

 

Thanks to all for your attention.