Loading programs over wifi

Hello,

I am the author of miniwifi, a small arduino/stm32duino library and a firmware for ESP8266 devices. All communication between the two devices happens over the serial port using a custom protocol. The ESP8266 firmware has some features, but I was thinking of adding remote uploading of programs. By connecting a GPIO pin of the ESP8266 to the reset pin of the stm32 board I can reset the board and then upload the program over serial. What do you think? What is the best reference on the serial protocol and the uploading of programs?

Fotis

i think that’s interesting and feasible
http://www.st.com/content/ccc/resource/ … 264342.pdf
the other alternate ways could involve having a different program running in stm32 itself that interacts with the esp8266 to download and program the flash from within stm32

I have found this note, together with AN2606 which describes the bootloader. Is there any doc describing the exact algorithm and locations where everything should be written? The rest should be pretty easy and straight forward.

Fotis

i think different soc in the stm32 series
http://www.st.com/content/ccc/resource/ … 167594.pdf
has some (slight) differences in the boot configurations in particular the boot pins and the boot flow
for stm32f103 i think, what’s needed is to set boot0 (high) and simply reset
in an2606 12.2 p54 (the link above) there is a flowchart which shows that after reset simply send 0x7f on the uart and the bootloader/flash loader would get started

flash normally starts at 0x8000000, make room for the stm32duino boot loader and offset to 0x8002000 and for ‘stock maple’ boot loader 0x8005000.
i think the sequence would be first erase then write

I am not so sure about the exact algorithm, and if it is that simple. For example, in the stm32duino bootloader, if the altset is equal to 1 then the maple bootloader behavior is used, the program is written at 0X8005000 and the page at 0x8002000 is erased. This is a detail that must be implemented. Furthermore, the flash is unlocked. Is this the same with the write unprotect command?
I guess the sources of stm32flash is a very good resource, but I was wondering if there is a document about this.

Fotis

fotisl wrote:I am not so sure about the exact algorithm, and if it is that simple. For example, in the stm32duino bootloader, if the altset is equal to 1 then the maple bootloader behavior is used, the program is written at 0X8005000 and the page at 0x8002000 is erased. This is a detail that must be implemented. Furthermore, the flash is unlocked. Is this the same with the write unprotect command?
I guess the sources of stm32flash is a very good resource, but I was wondering if there is a document about this.

Fotis

Reflashing via the MCUs built in Serial bootloader will be the simplest option.

You will need 4 pins, Reset, Boot0, Tx and Rx.

As well as the C code for the uploader, there is also a python version which is potentially easier to port.

You could also program via SWD, but the SWD pins are disabled in some sketch builds, so you would also need to reset the processor, so youd still meed 3 pins.
There is source on the web for programming via SWD, e.g. see the Blackmagic Probe, but porting the bits of that code would probably take much more effort.

As previously noted by @victor_pv, the usb bootloader only supports loading via DFU over USB, adding additional code to also support other protocols etc would be unnecessary bloat, as 99% users would not use the additional features

Yes, I forgot about boot0, I will need to pull this high too. My bluepill doesn’t break this out, so I guess it has to be done over the jumpers.

Do you happen to know where can I find the python version?

Fotis

fotisl wrote:Yes, I forgot about boot0, I will need to pull this high too. My bluepill doesn’t break this out, so I guess it has to be done over the jumpers.

Do you happen to know where can I find the python version?

Fotis

I’m pretty close to finishing this I think. One minor note for you Roger, shouldn’t https://github.com/rogerclarkmelbourne/ … er.py#L216 be:

crc = lng

fotisl wrote:I’m pretty close to finishing this I think. One minor note for you Roger, shouldn’t https://github.com/rogerclarkmelbourne/ … er.py#L216 be:

crc = lng