Replace core-firmware with RIOT-OS

I’m one of the RIOT-OS team members and I got a core in my hands recently. We are an open source IoT operating project, which has a long background in academics and is now evolving in the open source community for more than a year.

I choose to let the bootloader in place and just replace the firmware with our OS.

I think the bootloader is supervising my firmware in a way that it detects it as “dead” and performs a reset.

You can find my code here:

I tried to disable the watchdog and expose the status but it wasn’t working so far.

I hope to find documentation to make the bootloader/watchdog happy with RIOT-OS!

To replicate my setup:

  1. checkout my branch
  2. cd to examples/hello-world
  3. BOARD=spark-core make
  4. arm-none-eabi-objcopy -O binary bin/spark-core/hello-world.elf bin/spark-core/hello-world.bin
  5. dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D bin/spark-core/hello-world.bin

Thanks for this peace of hardware!


Hi @christian

You are right about the bootloader watchdog - @satishgn can comment further but there are some details in this thread on sleeping the core:

@bko thanks for the fast reply!

to clarify my question: I want to disable all the watchdogs/supervisors/timeouts/triggers started from the bootloader in a non permanent way (without deleting or touching and changing the bootloader).

I just this specific chunk of code, to hand over 100% control to the OS.


Hi @christian

I don’t think that is going to be possible but @satishgn or @zachary will have to chime in to be sure.

You can replace to bootloader with your own version that works that way for sure.

I want to find a solution for the spark community and the RIOT community, which will work for both.

So replacing the bootloader will require spark community hardware owners to have a jtag to reflash back to spark software…and I think this is not that nice. Same for RIOT users. So the bootloader with the dfu utility is a nice thing I want to preserve if possible.

Right now the led is just directly red and flashing every 4-5 sec, probably this chunk of code (from bootloader):

                // Set IWDG Timeout to 5 secs
                IWDG_Reset_Enable(5 * TIMING_IWDG_RELOAD);

perhaps we find a solution where I can set some bits to indicate my needs to the bootloader and then issue a reset. The bootloader should read that need and signal back (by setting some bits) that it accepted the request.

PS I updated by code in the RIOT repo, so you have a look at it:)

I managed to get it work:) I had to reengineer the bootloader, but it seems to work:)

code in the repo is updated, basically to signal the bootloader a successful update:

BKP->DR1 = 0xFFFF; // On successful firmware transition, BKP_DR1_Value is reset to default 0xFFFF
BKP->DR9 = 0xA << 12; // Do not enable IWDG if Stop Mode Flag is set
BKP->DR10 = 0x5000;	// 0x5000 is written to the backup register after transferring the FW from
// the external flash to the STM32's internal memory

and then start with a fresh CPU initialization…

comments and improvements are welcome!



Hi @christian,

I am guessing the above mechanism is working as you have received the latest cores with the latest bootloader or did you patched the bootloader after you got the core? patching would be necessary, else the IWDG enabled in bootloader will always reset the core when put in low power mode(necessary for older cores).

Here is the Bootloader-patch firmware which will easily enable anyone in field to update to the latest bootloader without using JTAG programmer. Here is the core-firmware branch for this:

However care should be taken not to disturb the patch update process by accidentally removing usb power or through reset.
Following is the procedure to update the bootloader-patch
1)cd core-firmware
2)git pull
3)git checkout bootloader-patch-update
4)cd build [No need to run make]
5)Enter usb dfu/bootloader mode => Yellow flashes
6) dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D core-firmware.bin
7)Upon execution, the bootloader should be updated within a second or two and normal core-firmware should start executing.
8)Congrats! your core is loaded with latest bootloader without the hassle of going through ST-Link JTAG programming

Now simply writing BKP->DR9 with 0xAFFF in your custom firmware should cause the bootloader to skip the enabling of IWDG after reset.


Hi @satishgn!

thanks for your short how to update the bootloader! With the original bootloader my core was resetting every 3-5 sec.

With the new one there is no reset anymore, GREAT!

LED and UART are running so far, a problem on thread scheduling is still there. svc interrupt is not firing.

I’ll keep you updated! perhaps you guys at spark are interested in link to RIOT-OS when we got the core running. We will link from our supported platforms page to you.

I’m also open to discuss a possible cooperation!


PS: I’ll update by RIOT branch in the next minutes


@satishgn how does the core-firmare manages to overwrite the interrupt table of the bootloader?

RIOT is doing almost the same:

why is the startup folder gone in master branch?


startup is now under src/

I think this is really exciting - can’t wait to take it for a spin once it’s working!

@mdma thanks :smile:

I think the only missing part to call this board initially ported is the threading, for which I need working interrupts (with the jump targets in RIOT).

to make this second “operating system” interrupt table work I miss a piece of understanding how this might work at all…

the embedded LED and the UART are working so far via RIOT! (someone else is working on the CC3000 driver for RIOT)


Hi @christian, Either I didn’t understand your question correctly or you are mistaken/confused.

Both the bootloader and core-firmware interrupt vector table are located in Flash at different vector table base offset.

In bootloader code, the offset is set default to "0x0000"
In core-firmware, the offset is set to “0x5000” via the following call at the start of the program in SparkCoreConfig() called in the startup assembly code.
NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x5000);

Both the bootloader and core-firmware has its own interrupt handler code implemented/defined in stm32_it file found in the respective repos. The handler declaration is weak in the startup code.

If you are using a different startup file as in RIOT-OS, then be sure to rename/update the interrupt handler definitions in stm32_it appropriately else the code won’t link properly.

@christian, there’s absolutely no reason why you can’t use the spark bootloader to load any subsequent app/OS. I’m glad to see that you’re up and running. I think @satishgn has given you the hint you need to switch over to your own vector table.

Please keep updating us here, this is exciting stuff.
If you can publish notes on your journey that would be an enormous help - the spark firmware & bootloader were developed in tandem, and so there are going to be hidden assumptions that as an outsider you are in a unique position to uncover and document.

@satishgn NVIC_SetVectorTable was the missing hint for me…now the RIOT interrupt table is used and the threading is working! thanks a lot.

No one I asked so far was aware of this functionality, probably because we usually replace all the code on the chip, so it seems the spark core is the first RIOT device with a software bootloader:)

@AndyW I’ll update the RIOT wiki to reflect all my findings so far! perhaps you can fill it with nice information and links to represent your hardware. You can send updates for the wiki to my private mail address (have a look at github) or as pull request. Currently it’s not finished in any way (incomplete and unchecked information).

@all RIOT status so far: RGB working, UART working, threading working…“user led” not working so far, I’ll look in this later. After updating the RIOT wiki (@AndyW just send me stuff:) to integrate. I’ll make a pull request to bring spark support in RIOT master.

  1. my code:
  2. the RIOT-wiki spark page:
  3. to get in contact to the RIOT team:
1 Like

@christian you are most welcome!. Glad that I could help you :smile:

This is supersweet!

When you add threading, will shared resources be protected with a mutex to prevent concurrent access? E.g. two threads accessing external flash - one reading while the other writes. Does the system take care of that or is user code expected to deal with the multi-threading and serialize access to shared state?

1 Like

@mdma yes we have mutexes, an message based ipc and priority based scheduling (and a pthread abstraction layer).

so far we have no support for external flash. In case you want to contribute a file system abstraction to RIOT you are very welcome.

1 Like

I updated the RIOT wiki (not finished yet) and the RIOT pull request to bring the spark core to the master branch!

RIOT is running well on the hardware and you can easily switch back to the spark firmware!

1 Like

@christian, I’m a total newbie to RTOS stuf and wondering if the COAP is the one on RIOT-OS or the native core-communication library? :smiley:

@kennethlimcp in case you have questions about RIOT-OS better use our mailing list or the IRC:

this thread is here to connect the two communities :slight_smile:

1 Like