Bootloader/Self write updates via WiFi
Posted: Mon Apr 17, 2017 12:14 pm
Hi
I would like to perform over-the-air updates of my various home automation boards via WiFi. The boards run on 18F26K22 and connect to my Wifi SSID using ESP8266 modules. It all works well.
Before the bootloader can start, I need to establish the TCP connection via WiFi link, then connect to the PC, whereafter data will become available via the PIC's USART2 using some handshaking protocol between the PC and the PIC.
So, the PC will be ready, connected to the LAN, with an application open, waiting to start downloading the latest version via WiFi. The PIC starts, connects to the WiFi, opens the port on the PC, send a handshaking signal, which then trigger the download process in the PC application.
I have done a lot of reading on this topic. I can't get my head around how to first connect to the WiFi, then only perform the self-write flash updates.
The way I see it is that this is more of a self write function than a bootloader because the system has already ran a lot of code to get the WiFi connection going before the flash updates can start - maybe I am wrong.
What I am asking:
1) How do I prevent the bootloader/self write routine (somewhere in memory) to be overwritten by the flash update process? I need some way to force the position of the bootloader/self write routine to a specific location. How do I do that?
2) Would it be better and even possible to position the self write function in upper memory? If so, again, how do I force that routine to a specific address?
3) If the self write routine is in lower memory, how do I know its upper memory limit to ensure the self write updates do not overwrite the upper parts of the self write routine?
Regards
Bernard
I would like to perform over-the-air updates of my various home automation boards via WiFi. The boards run on 18F26K22 and connect to my Wifi SSID using ESP8266 modules. It all works well.
Before the bootloader can start, I need to establish the TCP connection via WiFi link, then connect to the PC, whereafter data will become available via the PIC's USART2 using some handshaking protocol between the PC and the PIC.
So, the PC will be ready, connected to the LAN, with an application open, waiting to start downloading the latest version via WiFi. The PIC starts, connects to the WiFi, opens the port on the PC, send a handshaking signal, which then trigger the download process in the PC application.
I have done a lot of reading on this topic. I can't get my head around how to first connect to the WiFi, then only perform the self-write flash updates.
The way I see it is that this is more of a self write function than a bootloader because the system has already ran a lot of code to get the WiFi connection going before the flash updates can start - maybe I am wrong.
What I am asking:
1) How do I prevent the bootloader/self write routine (somewhere in memory) to be overwritten by the flash update process? I need some way to force the position of the bootloader/self write routine to a specific location. How do I do that?
2) Would it be better and even possible to position the self write function in upper memory? If so, again, how do I force that routine to a specific address?
3) If the self write routine is in lower memory, how do I know its upper memory limit to ensure the self write updates do not overwrite the upper parts of the self write routine?
Regards
Bernard