Tonight we made some tests! We looked where are connected BOOT0 and boot1 (PB2) on sphero. In order to make sphero boot via the internal bootloader of the stm32 BOOT0 must be to 1 and BOOT1 must be to 0. This makes the stm32 boot on system memory.
With the bipper we looked the connection of BOOT0 and it appears that it’s connected to VCC via a resistor of 380 ohms. It is confirm when we plug the board, we measure 3.3v. So that’s a good news. After we checked PB2, it’s hard to tell where it is connected. But when we plug the board it’s to gnd.
Basically the good config is already there, but that’s strange, why sphero is on the internal bootloader by default? Maybe we missed something which externally triggers boot0.
Logically it means we already can talk to the bootloader. I tried with the smt32loader.py to read the memory: “sudo stm32loader.py -r -p /dev/ttyUS0” and put sphero in reset when release it.
It doesn’t work. The bootloader is unable to talk via the uart. But when we use our remote in python via the uart we can talk to sphero. But it appears that we need to previously connect to the bluetooth with a smartphone. Maybe that’s why the uart is not free in reset. Even with the resistors we found between bluetooth RX ,TX and the STM32 rx,tx.
The next step we want to do is to sniff with two probes in RX what is happening between the stm32 and bluetooth chip at reset. There maybe some commands in the AT mode of the bluetooth at initialization time.
In summary: we weren’t able to set the sphero in bootloader mode for now but we have still more investigations to do before.