Hi,
I am new (couple weeks) to crazyflie. I have a crazyflie2.1 and before I do any programming I wanna make sure I understand all the options for programming the two processors. Basically I wanna make sure I don't 'brick' anything. Is there any documentation on these different configurations?
Seems like there are a lot of different potential modes: wireless, USB, debug headers...
Wireless:
Code is downloaded over the RF link (landing on the NRF51822 first), so that implies that the NRF51822 can program the STM32F405RG, true?
I see code in https://github.com/bitcraze/crazyflie2- ... /src/swd.c that sets up P0.24/25/28 as SPI, but it doesn't look like it
is used (swdInit() isn't called), so I don't see how the NRF51822 can program the STM32F405RG.
Also, can the NRF51822 also be re-flashed wirelessly? That is... can it reprogram its own flash?
USB:
Code is downloaded over USB (landing on the STM32F405RG first), so that implies that the STM32F405RG can program the NRF51822, true?
If yes, what is the interface between STM/NRF that supports this?
Debug headers:
Looking at the Crazyflie2.1 schematic, I see two debug headers (STM & NRF debug); with only the STM header populated.
Seems I need P4 to be populated if I want to re-flash the NRF51822, true?
Most of the above questions assume that there is a hardware interface between the two processors that allows one to program the other. I guess an alternative approach would be that they simply have a communication interface between them allowing either processor to send an image and then each processor programs itself. Is that the ticket?
Sorry for all the questions and thanks in advance,
Ed
summary of different flash-update options
Re: summary of different flash-update options
Hi!
Tldr; both MCU can be flashed over radio and it is impossible (ie. very hard) to brick the Crazyflie when flashing over radio.
For more info, this is how flashing the Crazyflie works:
Wireless: Both the nRF51 and the STM32 have a radio bootloader. The nRF51 implements the radio in the bootloader, both ESB (to Crazyradio) and BLE (very slow!). It also bridge bootloader packet to the STM32 which implement a bootloader over UART.
For the boot part, the nRF51 has control on the STM32 reset pin and the UART flow control pin is used at startup to select the STM32 boot to firmware or bootloader.
Both nRF and STM bootloader implements the same protocol: https://www.bitcraze.io/documentation/w ... hitecture/.
The safety of the bootloader come from the fact that they will refuse to flash themselves. So as long as the firmware does not mess with the flash, it should be impossible to brick the Crazyflie. The nRF situation is a little bit more nuanced (see bellow), but unbrickable is a good first approximation.
USB: USB flashing is much more limited. Pressing very long the power button at start (until the blue LED flashed quick), will put the stm32 in DFU bootloader mode. This is a mode that is implemented in ROM in the STM32 and is indented as a recorery mode. One must be careful with it because this mode allows to erase the STM32 bootloader which will then have to be flashed again to re-enable the radio bootloader.
Unbrickable?: There is one nuance on the nRF side. The problem comes from the fact that the bootloader is using the Nordic's BLE stack which is a blob written at the begining of the flash and shared between bootloader and firmware. So, to allow updating the BLE stack, it is possible to upload to the nRF flash a new BLE stack, a new bootloader, a struct containing a CRC and this will trigger the nRF to reflash the bootloader and BLE stack on the next restart. This is designed to be safe as long as what is being flashed is functional: if flashing fails, the CRC will not match and flashing will be tried again on next restart. If the original upload was not correct, the CRC of the source will not match and flashing the BLE stack and bootloader is not attempted. So if one would send a bugged bootloader that way, it would essencially brick the radio bootloader.
But this is where the DFU mode and SWD enters in action: it will anyway still be possible to start the STM in DFU mode, this is implemented in a protected "Master Boot Switch", and the STM32 has access to the SWD port of the nRF so it would be able to flash it back to life. Of course no software for this side of the plan is done, but all is prepared. The nRF architecture is documented there: https://www.bitcraze.io/documentation/r ... hitecture/
Debug header: This is correct, the STM32 debug header is mounted by default while the nRF one needs to be soldered. The required part is included in the debug-adapter-kit.
This was a long answer but I hope it sheds some light on what is happening when it comes to flashing the Crazyflie.
Tldr; both MCU can be flashed over radio and it is impossible (ie. very hard) to brick the Crazyflie when flashing over radio.
For more info, this is how flashing the Crazyflie works:
Wireless: Both the nRF51 and the STM32 have a radio bootloader. The nRF51 implements the radio in the bootloader, both ESB (to Crazyradio) and BLE (very slow!). It also bridge bootloader packet to the STM32 which implement a bootloader over UART.
For the boot part, the nRF51 has control on the STM32 reset pin and the UART flow control pin is used at startup to select the STM32 boot to firmware or bootloader.
Both nRF and STM bootloader implements the same protocol: https://www.bitcraze.io/documentation/w ... hitecture/.
The safety of the bootloader come from the fact that they will refuse to flash themselves. So as long as the firmware does not mess with the flash, it should be impossible to brick the Crazyflie. The nRF situation is a little bit more nuanced (see bellow), but unbrickable is a good first approximation.
USB: USB flashing is much more limited. Pressing very long the power button at start (until the blue LED flashed quick), will put the stm32 in DFU bootloader mode. This is a mode that is implemented in ROM in the STM32 and is indented as a recorery mode. One must be careful with it because this mode allows to erase the STM32 bootloader which will then have to be flashed again to re-enable the radio bootloader.
Unbrickable?: There is one nuance on the nRF side. The problem comes from the fact that the bootloader is using the Nordic's BLE stack which is a blob written at the begining of the flash and shared between bootloader and firmware. So, to allow updating the BLE stack, it is possible to upload to the nRF flash a new BLE stack, a new bootloader, a struct containing a CRC and this will trigger the nRF to reflash the bootloader and BLE stack on the next restart. This is designed to be safe as long as what is being flashed is functional: if flashing fails, the CRC will not match and flashing will be tried again on next restart. If the original upload was not correct, the CRC of the source will not match and flashing the BLE stack and bootloader is not attempted. So if one would send a bugged bootloader that way, it would essencially brick the radio bootloader.
But this is where the DFU mode and SWD enters in action: it will anyway still be possible to start the STM in DFU mode, this is implemented in a protected "Master Boot Switch", and the STM32 has access to the SWD port of the nRF so it would be able to flash it back to life. Of course no software for this side of the plan is done, but all is prepared. The nRF architecture is documented there: https://www.bitcraze.io/documentation/r ... hitecture/
Debug header: This is correct, the STM32 debug header is mounted by default while the nRF one needs to be soldered. The required part is included in the debug-adapter-kit.
This was a long answer but I hope it sheds some light on what is happening when it comes to flashing the Crazyflie.
Re: summary of different flash-update options
Thanks very much for the detail!
I'll have to digest this, then I may have more questions...
Again, thanks alot...
Ed
I'll have to digest this, then I may have more questions...
Again, thanks alot...
Ed
Re: summary of different flash-update options
Am I correct to assume that the NRF cannot be programmed through USB?
Re: summary of different flash-update options
Pins STM_SWCLK & STM_SWIO are initialized by swdInit() which as best I can tell, is not called.
Am I correct to assume that SWD from nRF51 to STM32 using SPI is not yet implemented?
Am I correct to assume that SWD from nRF51 to STM32 using SPI is not yet implemented?
Re: summary of different flash-update options
It looks like each of the processors are wired so that either can control the other's SWD through SPI;
however, apparently in both cases swdInit() (which initializes the corresponding pins for that purpose)
is not called.
So both are wired to control each other via SWD, but this function is not implemented
on either processor in firmware, true?
however, apparently in both cases swdInit() (which initializes the corresponding pins for that purpose)
is not called.
So both are wired to control each other via SWD, but this function is not implemented
on either processor in firmware, true?
Re: summary of different flash-update options
This is correct that flashing the nRF over USB is currently not possible.
The SWD cross connection was done to allow for (at least) 2 potential functionalities:
The SWD cross connection was done to allow for (at least) 2 potential functionalities:
- Being able to flash and debug the STM32 over SWD over radio
- Being able to flash the nRF51 over SWD over USB for recovery (in theory one could build and flash a CMSIS-DAP firmware to the STM32 ....)
Re: summary of different flash-update options
Great..
This is all making sense now.
Thanks for your help.
This is all making sense now.
Thanks for your help.