System Firmware 1,2,3

SO i was learning how the electron firmware is written and how the modular system firmware works. so far everything is good. because i find out main function which is in core_hal.c
but still didn’t understand that when bootloader jumps to CORE_FW_ADDRESS then how the system firmware jumps to other modules ?
something like i understand
bootloader -> system firmware 3 -> userapplication. but i didn’t find any clue regarding how system firmware 1 and 2 are working or called from system firmware 3. please help! to understand.
i want to port it to stm32f207 and then contribute to particle iot.

@ParticleD, or @mstanley are you able to assist?

On various devices, the system part is split into multiple parts. Two for Photon (each 256K), three for Electron (each 128K). There is only one part for Gen 3 (Argon, Boron, Xenon), but it’s big, 656K.

The issue that the system firmware requires a certain size (384K for the Electron), and it could have been one part, but then 384K of flash would need to have been set aside for OTA flashing of system firmware, to hold the whole thing while downloading. There wasn’t enough free to do that.

In order to reduce the size of the OTA buffer on the Electron, system firmware was split into three parts. (Prior to 0.6.0, it was only two parts.)

There’s various magic about how the code is divided into parts so the system can still boot and operate. When upgrading, as long as you flash in 1, 2, 3 order, the system can boot and download the next part. When downgrading, it works if you flash in the reverse order 3, 2, 1.

In any case, porting Device OS to another device is not supported so you’ll end up having to do a lot of digging as it’s not really documented. Also, when you get it fully ported, accessing the Particle cloud won’t work. The reason is that the Device ID masked into the STM32 processor has to be known to the cloud or it will be rejected. When you buy a Particle device or module (P0 or P1) from Particle, it has been added to our database. If you buy a random STM32 processor, it will not, and won’t be allowed to access the cloud.


hypothetically i guess a company like giga device could offer a gd32 as a stm32 with the 96bit device id field open or able to be rewritten. but i’d like to know in the event it was possible to create 2 devices with the same valid device id is there any other way the particle system would identify one as being invalid? meaning one is an actual particle device and the other is not.

I don’t want to use particle cloud. eith another stm32. i just eant understand. that how it splits thr firmware. it is Crystal clear that Linker files handles the different memory address. but i don’t understand how you guys build the different firmware part is there any possibility for explanation?
just interested in split part and writing at different memory address.
because you guys are awesome you have done very well job.
but if it is documented there are lots of ideas to be built in particle. and we can support you guys. but due to lack of documentation we are unable to do it. please help.
you guys are amazing.

Maybe the part you are missing is the use of dynalib. This is a set of code and macros that allows code to call across the part boundaries by using (and checking) a set of fixed addresses based on the starting address of each module. The addresses of functions in say parts 2 and 3 are forced to known locations in the linker and a table is kept in part 1 in the exact same order that allows calls to go through.

In use:


Okey so that is the functionality of dynalib. that’s a great idea to call the function from the address.
But how it compiles in 3 different binaries that’s still a mystery .

It will not be a mystery if you look in the modules directory and check the makefiles there!

1 Like

Ok thanks.
although if you have information regarding it please share. because i am kinda noob in arm industry. since i am moving from arduino stm32duino to makefile structure and have to learn a lot from industrial experts .
So thank you.