St-link & programmer shield only! - So, you've decided you want to update your bootloader and everything

Continuing the discussion from Won’t connect to internet - rapid green flashing:

This maybe goes without saying, but I’ll say it anyway: These instructions (*which you probably don’t need to try, and maybe shouldn’t do unless you are okay breaking things *) tell you how to remove and replace the bootloader on your core. This is pretty safe and easy if you have the right tools, but really please don’t do it unless you have a ST-Link programmer and a programmer shield, and you can confidently recover from an erased bootloader (a “bricked core”).

#So you’ve decided to reflash everything anyway,
##despite what @Dave literally just warned me about a second ago:

###Let’s do this:
1.) Really make sure you have a working programmer shield and an ST-link programmer.

2.) Is this a brand new core from scratch (that you made? nice!) goto 3, or is it this a core that came from Spark - goto “unlocking your bootloader”

##Unlocking your bootloader

Welcome! The bootloader on the stm32 is protected by a “write protect” flag that helps prevent accidental “bricking” of a core for those without a programmer shield / st-link programmer. But that’s not you, you want to fully erase your core, or re-write your bootloader, and you’re not scared of “bricking” anything.

A.) Grab the "unlocker" from here: (https://github.com/spark/bootloader/tree/master/tools (use "raw")
B.) dfu that with a:  dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D unlocker-firmware.bin
C.) your core should restart, flash some lights, and end with a 'green' flash before wiping saved wifi profiles and resetting
D.) your bootloader is unlocked!

3.) Make sure you have st-flash installed, or have a copy of the ST-Link Utility software

If you’re on mac / linux grab “st-flash” you can grab and build a tool yourself:

git clone git@github.com:texane/stlink.git
cd stlink
./autogen.sh
./configure
make
make install

4.) Grab a copy of the latest bootloader from here: https://github.com/spark/bootloader/blob/master/build/bootloader.bin?raw=true
5.) With your core in your programmer shield / st-link connected, lets re-flash some stuff!

A.) In the windows utility set device -> settings to "connect under reset" true! (if you can't find this that's okay)
B.) do a full erase of your core, do this a few times, if you're in the windows utility, view the memory and make sure it's zero-ed out.
C.) write your bootloader.bin back to 0x08000000
D.) congrats, you re-wrote your bootloader!

6.) Lock your bootloader back up! (Optional, but recommended)

A.) grab the locking firmware here:  (https://github.com/spark/bootloader/tree/master/tools (use "raw")
B.) dfu that to dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D locker-firmware.bin
C.) your core should reset, flash some lights, and flash 'red' when locked.

Okay, lets keep going and update the radio driver on the CC3000

1.) Grab the patch programmer from here: https://github.com/spark/cc3000-patch-programmer/blob/master/build/cc3000-patch-programmer.bin?raw=true

2.) dfu it with: dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D cc3000-patch-programmer.bin

3.) hold down the mode button for 3+ seconds until the light starts blinking, let your core sit for 20-60 seconds after the light stops blinking.

4.) At this point you can erase your core with the st-link programmer (did you lock your bootloader?), to get it back into dfu mode

It’s time to write some stuff to external flash!

1.) Lets make some keys (optional step if your keys have been fine):

openssl genrsa -out core.pem 1024
openssl rsa -in core.pem -pubout -out core_public.pem
openssl rsa -in core.pem -outform DER -out core_private.der

2.) Flash your new private key:

dfu-util -d 1d50:607f -a 1 -s 0x00002000 -v -D core_private.der

3.) Grab the server public key, and flash it:

https://s3.amazonaws.com/spark-website/cloud_public.der
dfu-util -d 1d50:607f -a 1 -s 0x00001000 -v -D cloud_public.der

4.) Grab the latest firmware and flash it

https://github.com/spark/core-firmware/blob/spark_4/build/core-firmware.bin?raw=true

## to the factory reset spot 
dfu-util -a 1 -s 0x00020000 -v -D core-firmware.bin

## to the main firmware spot
dfu-util -a 0 -s 0x08005000:leave -D core-firmware.bin

5.) If you made new keys, be sure to send someone at Spark your new public key, along with your core id, otherwise your core won’t connect to the cloud again!

I think that’s it!

Thanks,
David

4 Likes

I had a core with a GFOYNSINCTT (green flash of your network sucks I’m not connecting to that) … no matter what I tried it would just not show networks love anymore. So I’m happy to say that it’s back online! :smiley:

I have some notes that jotted down as I was going through your instructions Dave… only one show stopper, but for others they may freak a bit if they don’t see exactly what you say they should see.


You need to power your core from micro usb when in the programmer shield. The STLink does not supply power.

After unlocking, my core flashes green, then back in DFU mode (flashing yellow)

When you erase the chip, it shows “FFFFFFFF” not zeros, but that’s “zero-ed out” aka the erased state of flash memory.

After re-locking, my core flashes blue, red, then back to dfu mode (flashing yellow)

After programming the cc3000 patch, and erasing with STLink, I got a message “Some flash pages are write protected!”. (Yes I had re-locked!!) The magenta light turned off. It was not erasing the flash. So I tried “Erase Sectors” under the Target menu, and selected everything from 0x8005000 and up (higher addresses):

Hit apply and it erased each sector. Then I disconnected the STLink and pressed reset on the core, and it was back in DFU mode (flashing yellow).

I skipped the keys part as I didn’t think I should have to add new keys.

Overwriting the Factory Reset firmware scared me for a second because it was scrolling a bunch of stuff I couldn’t read…

But everything turned out ok!

Now I have to see if this other core with a dim blue D7 led has a chance of revival.

2 Likes

Second core with dim blue D7 led is also back up online now! This one turned out to be simpler.

Backstory… I had been using this core, blocked the main loop with some code and it wouldn’t reflash OTA, so I did a factory reset and after it reflashed it came back up with the dim D7 led.

At first I was like… I can’t DFU since it’s stuck in this state of ONLY blue D7 led… nothing worked… not even the reset button. So I thought first step is trying to get that unlocker-firmware.bin on there so I can erase the whole thing. I knew I could use the STLink to do this, you just have to load the BIN, click program, and then change the address offset to 0x8005000 before you hit Program. When I did, the RGB started flashing yellow, and it unlocked to my surprise.

Because then it appeared the firmware might have just been jammed up, I DFU’d the locker-firmware.bin and core-firmware.bin and I was back up and running. I’m thinking I probably just could have used the STLink to program the core-firmware.bin at 0x8005000 and it would have been the same outcome without the unlocking/locking process.

I not sure how the factory reset failed and corrupted the core firmware, but I would also think through a power cycle that the bootloader should always be able to get the core back into DFU mode or do another factory reset. Not sure how this got locked up like it did. Hopefully this is helpful info.

@Dave Is there anything stopping me from compiling my own firmware and putting it in the Factory Restore spot?

I’d love to whip up a quick firmware that defaulted to auto-configuring my WiFi credentials. That way I don’t have to take the extra time to pull my phone out and go through the SmartConfig rigamarole.

Hi @timb,

You can definitely do that, sounds like a nice time saver. :smile:

Hi @BDub,

Awesome, so glad you were able to rescue your cores. I’m really curious about this sequence of events, ideally the bootloader should protect you from needing to use the st-link / programmer shield under normal circumstances. I’ve been seeing some users report cores that go from working into not connecting, so if they are indeed rescuable this way, then I suspect we should be looking to make firmware / bootloader fixes. What are your thoughts @zachary?

Thanks!
David

If we can get a clear way to reproduce the failure, then yeah, we would definitely want to debug.

Looks like ST-LINK V2 sends power to the board ~3.2V (between ST-LINK VCC and GND). When I click connect to target the leds on the core are powered on but the connection fails. When I connect the core to the USB I can connect to the target, Why is this happening? The debugger is not giving enough power to the core?

Hi @robertdolca,

You’re absolutely right, the ST-Link programmer / programmer shield won’t power the core on its own. You’d need to supply power by plugging it in via USB, or by providing power through the pins.

Thanks,
David

I understand that but I don`t understand why because ST-LINK gives 3.2V on VCC.

Hi @robertdolca,

I’m not exactly sure about that one, I’d need to defer to our hardware guy @mohit, but I can tell you that powering over jtag alone isn’t sufficient.

Thanks,
David

It’s most likely just not enough current. The CC3000 pulls a ton of power at startup.

I concur with what @timb has to say here. We have not been able to source enough current out of the ST Link to power up the :spark: Core.

My guess is that the ST-Link is not supplying power via Vcc and that the power is actually coming from the logic signal outputs, back through the IO protection (clamping) Schottky diodes on the 'core, hence the 0.1V drop to 3.2V. There’s obviously enough, “back-current” to light some LEDs, but there’s actually no power on Vcc, in the right direction. (Just guessing. Seen this sort of thing on my own hardware designs, many times.)

That’s still a little bit odd. Ideally, the ST-Link would not to provide any power at all through its IO outputs, if there’s no reference voltage on its JTAG Vcc input. But maybe there’s just enough there begin with, to get a kind of loop going, thus providing enough reference current to set things off. It only takes microamps on the JTAG Vcc input to result in powering up the JTAG IO outputs. (JTAG Vcc is a reference input to a level-shifter, to allow the JTAG IO to operate at ~1.5 through ~5V, without messing about with jumpers or configuration, you see.)

EDIT: Confirmed. That is what is happening – especially if the St-Link has already just been used and already has IO changes present on its JTAG outputs. That is, it doesn’t seem to happen when you first plug the USB connector into the St-Link but haven’t connected to it yet (via software, I mean.)

Dang – English is so ambiguous! :stuck_out_tongue:

1 Like

I’m trying to update the bootloader on my kickstarter core and at the same time learn how to use the STlink v2 and programmer shield on my mac. :smile:

How can i flash the updated bootloader using the st-flash tool mentioned in the steps for mac?

Its now possible with dfu-util! and OTA!!!

1 Like

Just thought i should learn how to use the STlink v2 since Spark team was kind enough to hand me one during our US trip!

How can i do it? :slight_smile:

Hey @kennethlimcp,

^^^ :slight_smile: Instructions on getting the st-link going on linux and mac are at the top, no? :slight_smile:

Thanks,
David

1 Like

I installed the st-flash but how do i flash the binary file via the utility? :slight_smile:

Can’t seem to see the command to use the st-flash or am i missing something? :wink:

Huh, weird, here ya go:

sudo st-flash write bootloader_latest.bin 0x08000000

Thanks,
David

1 Like