|
@@ -0,0 +1,128 @@
|
|
1
|
+# `picowota` - Raspberry Pi Pico W OTA bootloader
|
|
2
|
+
|
|
3
|
+> `picowota`, kinda sounds like you're speaking [Belter](https://expanse.fandom.com/wiki/Belter)
|
|
4
|
+
|
|
5
|
+This project implements a bootloader for the Raspberry Pi Pico W which allows
|
|
6
|
+upload of program code over WiFi ("Over The Air").
|
|
7
|
+
|
|
8
|
+The easiest way to use it is to include this repository as a submodule in the
|
|
9
|
+application which you want to be able to update over WiFi.
|
|
10
|
+
|
|
11
|
+There's an example project using picowota at https://github.com/usedbytes/picowota_blink
|
|
12
|
+
|
|
13
|
+## Using in your project
|
|
14
|
+
|
|
15
|
+First add `picowota` as a submodule to your project:
|
|
16
|
+```
|
|
17
|
+git submodule add https://github.com/usedbytes/picowota
|
|
18
|
+git submodule update --init picowota
|
|
19
|
+git commit -m "Add picowota submodule"
|
|
20
|
+```
|
|
21
|
+
|
|
22
|
+Then modifiy your project's CMakeLists.txt to include the `picowota` directory:
|
|
23
|
+
|
|
24
|
+```
|
|
25
|
+add_subdirectory(picowota)
|
|
26
|
+```
|
|
27
|
+
|
|
28
|
+`picowota` (currently) connects to an existing WiFi network, so you need to
|
|
29
|
+set the SSID and password for the network to connect to.
|
|
30
|
+
|
|
31
|
+You can either export the `PICOWOTA_WIFI_SSID` and `PICOWOTA_WIFI_PASS`
|
|
32
|
+environment variables, or set the CMake variables with the same name:
|
|
33
|
+
|
|
34
|
+```
|
|
35
|
+set(PICOWOTA_WIFI_SSID MyNetworkName)
|
|
36
|
+set(PICOWOTA_WIFI_PASS MyPassw0rd)
|
|
37
|
+```
|
|
38
|
+
|
|
39
|
+Then, you can either build just your standalone app binary (suitable for
|
|
40
|
+updating via `picowota` when it's already on the Pico), or a combined binary
|
|
41
|
+which contains the bootloader and the app (suitable for flashing the first
|
|
42
|
+time):
|
|
43
|
+
|
|
44
|
+```
|
|
45
|
+picowota_build_standalone(my_executable_name)
|
|
46
|
+picowota_build_combined(my_executable_name)
|
|
47
|
+```
|
|
48
|
+
|
|
49
|
+Note: The combined target will also build the standalone binary.
|
|
50
|
+
|
|
51
|
+To be able to update your app, you must provide a way to return to the
|
|
52
|
+bootloader. By default, if GPIO15 is pulled low at boot time, then `picowota`
|
|
53
|
+will stay in bootloader mode, ready to receive new app code.
|
|
54
|
+
|
|
55
|
+You can also return to the bootloader from your app code - for example when a
|
|
56
|
+button is pressed, or in response to some network request. The
|
|
57
|
+`picowota_reboot` library provides a `picowota_reboot(bool to_bootloader)`
|
|
58
|
+function, which your app can call to get back in to the bootloader.
|
|
59
|
+
|
|
60
|
+```
|
|
61
|
+CMakeLists.txt:
|
|
62
|
+
|
|
63
|
+target_link_libraries(my_executable_name picowota_reboot)
|
|
64
|
+
|
|
65
|
+your_c_code.c:
|
|
66
|
+
|
|
67
|
+#include "picowota/reboot.h"
|
|
68
|
+
|
|
69
|
+...
|
|
70
|
+
|
|
71
|
+{
|
|
72
|
+
|
|
73
|
+ ...
|
|
74
|
+
|
|
75
|
+ if (should_reboot_to_bootloader) {
|
|
76
|
+ picowota_reboot(true);
|
|
77
|
+ }
|
|
78
|
+
|
|
79
|
+ ...
|
|
80
|
+
|
|
81
|
+}
|
|
82
|
+```
|
|
83
|
+
|
|
84
|
+## Uploading code via `picowota`
|
|
85
|
+
|
|
86
|
+Once you've got the `picowota` bootloader installed on your Pico, you can use
|
|
87
|
+the https://github.com/usedbytes/serial-flash tool to upload code to it.
|
|
88
|
+
|
|
89
|
+As long as the Pico is "in" the `picowota` bootloader (i.e. because there's no
|
|
90
|
+valid app code uploaded yet, or your app called `picowota_reboot(true);`), you
|
|
91
|
+can upload an app `.elf` file which was built by `picowota_build_standalone()`:
|
|
92
|
+
|
|
93
|
+(Assuming your Pico's IP address is 192.168.1.123):
|
|
94
|
+```
|
|
95
|
+serial-flash tcp:192.168.1.123:4242 my_executable_name.elf
|
|
96
|
+```
|
|
97
|
+
|
|
98
|
+After uploading the code, if successful, the Pico will jump to the newly
|
|
99
|
+uploaded app.
|
|
100
|
+
|
|
101
|
+## How it works
|
|
102
|
+
|
|
103
|
+This is derived from my Pico non-W bootloader, https://github.com/usedbytes/rp2040-serial-bootloader, which I wrote about in a blog post: https://blog.usedbytes.com/2021/12/pico-serial-bootloader/
|
|
104
|
+
|
|
105
|
+The bootloader code attempts to avoid "bricking" by storing a CRC of the app
|
|
106
|
+code which gets uploaded. If the CRC doesn't match, then the app won't get run
|
|
107
|
+and the Pico will stay in `picowota` bootloader mode. This should make it fairly
|
|
108
|
+robust against errors in transfers etc.
|
|
109
|
+
|
|
110
|
+## Known issues
|
|
111
|
+
|
|
112
|
+### Bootloader/app size and `cyw43` firmware
|
|
113
|
+
|
|
114
|
+The WiFi chip on a Pico W needs firmware, which gets built in to any program
|
|
115
|
+you build with the Pico SDK. This is relatively large - 300-400 kB, which is why
|
|
116
|
+this bootloader is so large.
|
|
117
|
+
|
|
118
|
+This gets duplicated in the `picowota` bootloader binary and _also_ the app
|
|
119
|
+binary, which obviously uses up a significant chunk of the Pico's 2 MB flash.
|
|
120
|
+
|
|
121
|
+It would be nice to be able to avoid this duplication, but the Pico SDK
|
|
122
|
+libraries don't give a mechanism to do so.
|
|
123
|
+
|
|
124
|
+### Expose and access point, rather than connecting to one
|
|
125
|
+
|
|
126
|
+It would perhaps be better if the bootloader set up an access point, rather than
|
|
127
|
+trying to connect to an existing network - or even better, provide the option.
|
|
128
|
+I expect that wouldn't be too hard to do.
|