You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a docker-based interactive development environment using VS Code and Docker Dev Containers removing the need to install any tools locally*
3
-
4
2
3
+
This is a docker-based interactive development environment using VS Code and Docker Dev Containers removing the need to install any tools locally\*
5
4
6
5
## Requirements
7
6
@@ -16,45 +15,41 @@ This is a docker-based interactive development environment using VS Code and Doc
16
15
17
16
1. Clone InfiniTime and update submodules
18
17
2. Launch VS Code
19
-
3. Open InfiniTime directory,
20
-
4. Allow VS Code to open folder with devcontainer.
18
+
3. Open InfiniTime directory,
19
+
4. Allow VS Code to open folder with devcontainer.
21
20
22
-
After this the environment will be built if you do not currently have a container setup, it will install all the necessary tools and extra VSCode extensions.
21
+
After this the environment will be built if you do not currently have a container setup, it will install all the necessary tools and extra VSCode extensions.
23
22
24
23
In order to build InfiniTime we need to run the initial submodule init and CMake commands.
25
24
26
-
#### Manually
25
+
#### Manually
27
26
28
-
You can use the VS Code terminal to run the CMake commands as outlined in the [build instructions](blob/develop/doc/buildAndProgram.md)
27
+
You can use the VS Code terminal to run the CMake commands as outlined in the [build instructions](blob/develop/doc/buildAndProgram.md)
29
28
30
29
#### Script
31
30
32
31
The dev environment comes with some scripts to make this easier, They are located in /opt/.
33
32
34
-
There are also VS Code tasks provided should you desire to use those.
33
+
There are also VS Code tasks provided should you desire to use those.
35
34
36
35
The task "update submodules" will update the git submodules
37
36
38
-
39
-
40
37
### Build
41
38
42
39
You can use the build.sh script located in /opt/
43
40
44
41
CMake is also configured and controls for the CMake plugin are available in VS Code
45
42
46
-
47
-
48
43
### Debugging
49
44
50
45
Docker on windows does not support passing USB devices to the underlying WSL2 subsystem, To get around this we use OpenOCD in server mode running on the host.
This will launch OpenOCD in server mode and attach it to the MCU.
49
+
This will launch OpenOCD in server mode and attach it to the MCU.
55
50
56
51
The default launch.json file expects OpenOCD to be listening on port 3333, edit if needed
57
52
58
-
59
53
## Current Issues
60
-
Currently WSL2 Has some real performance issues with IO on a windows host. Accessing files on the virtualized filesystem is much faster. Using VS Codes "clone in container" feature of the Remote - Containers will get around this. After the container is built you will need to update the submodules and follow the build instructions like normal
54
+
55
+
Currently WSL2 Has some real performance issues with IO on a windows host. Accessing files on the virtualized filesystem is much faster. Using VS Codes "clone in container" feature of the Remote - Containers will get around this. After the container is built you will need to update the submodules and follow the build instructions like normal
-[Build the project with Docker](doc/buildWithDocker.md)
45
+
-[Build the project with VSCode](doc/buildWithVScode.md)
46
+
-[Flash the firmware using OpenOCD and STLinkV2](doc/openOCD.md)
47
+
-[Flash the firmware using SWD interface](doc/SWD.md)
48
+
-[Flash the firmware using JLink](doc/jlink.md)
49
+
-[Flash the firmware using GDB](doc/gdb.md)
50
+
-[Stub using NRF52-DK](doc/PinetimeStubWithNrf52DK.md)
51
51
52
52
### API
53
53
54
-
-[BLE implementation and API](doc/ble.md)
54
+
-[BLE implementation and API](doc/ble.md)
55
55
56
56
### Architecture and technical topics
57
57
58
-
-[Memory analysis](doc/MemoryAnalysis.md)
58
+
-[Memory analysis](doc/MemoryAnalysis.md)
59
59
60
60
## Licenses
61
61
62
62
This project is released under the GNU General Public License version 3 or, at your option, any later version.
63
63
64
64
It integrates the following projects:
65
-
- RTOS : **[FreeRTOS](https://freertos.org)** under the MIT license
66
-
- UI : **[LittleVGL/LVGL](https://lvgl.io/)** under the MIT license
67
-
- BLE stack : **[NimBLE](https://github.com/apache/mynewt-nimble)** under the Apache 2.0 license
68
-
- Font : **[Jetbrains Mono](https://www.jetbrains.com/fr-fr/lp/mono/)** under the Apache 2.0 license
65
+
66
+
- RTOS : **[FreeRTOS](https://freertos.org)** under the MIT license
67
+
- UI : **[LittleVGL/LVGL](https://lvgl.io/)** under the MIT license
68
+
- BLE stack : **[NimBLE](https://github.com/apache/mynewt-nimble)** under the Apache 2.0 license
69
+
- Font : **[Jetbrains Mono](https://www.jetbrains.com/fr-fr/lp/mono/)** under the Apache 2.0 license
69
70
70
71
## Credits
71
72
72
73
I’m not working alone on this project. First, many people create PR for this projects. Then, there is the whole #pinetime community : a lot of people all around the world who are hacking, searching, experimenting and programming the Pinetime. We exchange our ideas, experiments and code in the chat rooms and forums.
73
74
74
75
Here are some people I would like to highlight:
75
76
76
-
-[Atc1441](https://github.com/atc1441/) : He works on an Arduino based firmware for the Pinetime and many other smartwatches based on similar hardware. He was of great help when I was implementing support for the BMA421 motion sensor and I²C driver.
77
-
-[Koen](https://github.com/bosmoment) : He’s working on a firmware based on RiotOS. He integrated similar libs as me : NimBLE, LittleVGL,… His help was invaluable too!
78
-
-[Lup Yuen Lee](https://github.com/lupyuen) : He is everywhere: he works on a Rust firmware, builds a MCUBoot based bootloader for the Pinetime, designs a Flutter based companion app for smartphones and writes a lot of articles about the Pinetime!
77
+
-[Atc1441](https://github.com/atc1441/) : He works on an Arduino based firmware for the Pinetime and many other smartwatches based on similar hardware. He was of great help when I was implementing support for the BMA421 motion sensor and I²C driver.
78
+
-[Koen](https://github.com/bosmoment) : He’s working on a firmware based on RiotOS. He integrated similar libs as me : NimBLE, LittleVGL,… His help was invaluable too!
79
+
-[Lup Yuen Lee](https://github.com/lupyuen) : He is everywhere: he works on a Rust firmware, builds a MCUBoot based bootloader for the Pinetime, designs a Flutter based companion app for smartphones and writes a lot of articles about the Pinetime!
Copy file name to clipboardexpand all lines: bootloader/README.md
+28-23
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,5 @@
1
1
# About this bootloader
2
+
2
3
The [bootloader](https://github.com/lupyuen/pinetime-rust-mynewt/tree/master/libs/pinetime_boot/src) is mostly developed by [Lup Yuen](https://github.com/lupyuen). It is based on [MCUBoot](https://www.mcuboot.com) and [Mynewt](https://mynewt.apache.org/).
3
4
4
5
The goal of this project is to provide a common bootloader for multiple (all?) Pinetime projects. It allows to upgrade the current bootloader and even replace the current application by another one that supports the same bootloader.
@@ -12,15 +13,17 @@ When it is run, this bootloader looks in the SPI flash memory if a new firmware
12
13
As this bootloader does not provide any OTA capability, it is not able to actually download a new version of the application. Providing OTA functionality is thus the responsibility of the application firmware.
13
14
14
15
# About MCUBoot
16
+
15
17
MCUBoot is run at boot time. In normal operation, it just jumps to the reset handler of the application firmware to run it. Once the application firmware is running, MCUBoot does not run at all.
But MCUBoot does much more than that : it can upgrade the firmware that is currently running by a new one, and it is also able to revert to the previous version of the firmware in case the new one does not run properly.
20
22
21
23
To do this, it uses 2 memory 'slots' :
22
-
-**The primary slot** : it contains the current firmware, the one that will be executed by MCUBoot
23
-
-**The secondary slot** : it is used to store the upgraded version of the firmware, when available.
24
+
25
+
-**The primary slot** : it contains the current firmware, the one that will be executed by MCUBoot
26
+
-**The secondary slot** : it is used to store the upgraded version of the firmware, when available.
24
27
25
28
At boot time, MCUBoot detects that a new version of the firmware is available in the secondary slot and swaps them : the current version of the firmware is copied from the primary to the secondary slot and vice-versa.
26
29
@@ -35,6 +38,7 @@ The next time MCUBoot will be run (after a MCU reset), MCUBoot will check if the
35
38
Note than MCUBoot **does not** provide any means to download and store the new version of the firmware into the secondary slot. This must be implemented by the application firmware.
36
39
37
40
# Degraded cases
41
+
38
42
This chapter describes degraded cases that are handled by our bootloader and those that are not supported.
39
43
40
44
Case | Current bootloader | Solution
@@ -50,72 +54,73 @@ New firmware does not run properly but sets the valid bit and refreshes the watc
50
54
# Using the bootloader
51
55
52
56
## Bootloader graphic
57
+
53
58
The bootloader loads a graphic (Pinetime logo) from the SPI Flash memory. If this graphic is not loaded in the memory, the LCD will display garbage (the content of the SPI flash memory).
54
59
55
60
The SPI Flash memory is not accessible via the SWD debugger. Use the firmware 'pinetime-graphics' to load the graphic into memory. All you have to do is build it and program it at address 0x00 :
56
61
57
-
- Build:
58
-
```
59
-
$ make pinetime-graphics
62
+
- Build:
63
+
64
+
```sh
65
+
make pinetime-graphics
60
66
```
61
67
62
-
- Program (using OpenOCD for example) :
68
+
- Program (using OpenOCD for example) :
69
+
63
70
```
64
71
program pinetime-graphics.bin 0
65
72
```
66
73
67
-
- Let it run for ~10s (it does nothing for 5 seconds, then write the logo into the SPI memory, then (slowly) displays it on the LCD).
74
+
- Let it run for ~10s (it does nothing for 5 seconds, then write the logo into the SPI memory, then (slowly) displays it on the LCD).
68
75
69
76
## Bootloader binary
77
+
70
78
The binary comes from https://github.com/lupyuen/pinetime-rust-mynewt/releases/tag/v5.0.4
71
79
72
80
It must be flash at address **0x00** in the internal flash memory.
73
81
74
82
Using OpenOCD:
75
83
76
-
`
77
-
program bootloader-5.0.4.bin 0
78
-
`
84
+
`program bootloader-5.0.4.bin 0`
79
85
80
86
## Application firmware image
87
+
81
88
Build the binary compatible with the booloader:
82
89
83
-
`
84
-
make pinetime-mcuboot-app
85
-
`
90
+
`make pinetime-mcuboot-app`
86
91
87
92
The binary is located in *<builddirectory>/src/pinetime-mcuboot-app.bin*.
88
93
89
94
It must me converted into a MCUBoot image using *imgtool.py* from [MCUBoot](https://github.com/mcu-tools/mcuboot/tree/master/scripts). Simply checkout the project and run the script <mcubootroot>/scripts/imgtool.py with the following command line:
Use NRFConnect or dfu.py (in <projectroot>/bootloader/ota-dfu-python) to upload the zip file to the device:
111
115
112
-
`
116
+
```sh
113
117
sudo dfu.py -z /home/jf/nrf52/bootloader/dfu.zip -a <pinetime MAC address> --legacy
114
-
`
118
+
```
115
119
116
120
**Note** : dfu.py is a slightly modified version of [this repo](https://github.com/daniel-thompson/ota-dfu-python).
117
121
118
122
### Firmware validation
123
+
119
124
Once the OTA is done, InfiniTime will reset the watch to apply the update. When the watch reboots, the new firmware is running.
120
125
121
126
One last step is needed to finalize the upgrade : the new firmware must be manually validated. If the watch resets while the image is not validated, the bootloader will automatically revert to the previous version of the firmware.
@@ -17,24 +17,24 @@ This is a Python program that uses `gatttool` (provided with the Linux BlueZ dri
17
17
18
18
### Main features:
19
19
20
-
* Perform OTA DFU to an nRF5 peripheral without an external USB BLE dongle.
21
-
* Ability to detect if the peripheral is running in application mode or bootloader, and automatically switch if needed (buttonless).
22
-
* Support for both Legacy (SDK <= 11) and Secure (SDK >= 12) bootloader.
20
+
- Perform OTA DFU to an nRF5 peripheral without an external USB BLE dongle.
21
+
- Ability to detect if the peripheral is running in application mode or bootloader, and automatically switch if needed (buttonless).
22
+
- Support for both Legacy (SDK <= 11) and Secure (SDK >= 12) bootloader.
23
23
24
24
Before using this utility the nRF5 peripheral device needs to be programmed with a DFU bootloader (see Nordic Semiconductor documentation/examples for instructions on that).
25
25
26
26
## Prerequisites
27
27
28
-
* BlueZ 5.4 or above
29
-
* Python 3.6
30
-
* Python `pexpect` module (available via pip)
31
-
* Python `intelhex` module (available via pip)
28
+
- BlueZ 5.4 or above
29
+
- Python 3.6
30
+
- Python `pexpect` module (available via pip)
31
+
- Python `intelhex` module (available via pip)
32
32
33
33
## Firmware Build Requirement
34
34
35
-
* Your nRF5 peripheral firmware build method will produce a firmware file ending with either `*.hex` or `*.bin`.
36
-
* Your nRF5 firmware build method will produce an Init file ending with `.dat`.
37
-
* The typical naming convention is `application.bin` and `application.dat`, but this utility will accept other names.
35
+
- Your nRF5 peripheral firmware build method will produce a firmware file ending with either `*.hex` or `*.bin`.
36
+
- Your nRF5 firmware build method will produce an Init file ending with `.dat`.
37
+
- The typical naming convention is `application.bin` and `application.dat`, but this utility will accept other names.
38
38
39
39
## Generating init files
40
40
@@ -75,14 +75,13 @@ You can use the `hcitool lescan` to figure out the address of a DFU target, for
75
75
CD:E3:4A:47:1C:E4 <TARGET_NAME>
76
76
CD:E3:4A:47:1C:E4 (unknown)
77
77
78
-
79
78
## Example Output
80
79
81
80
================================
82
81
== ==
83
82
== DFU Server ==
84
83
== ==
85
-
================================
84
+
================================
86
85
87
86
Sending file application.bin to CD:E3:4A:47:1C:E4
88
87
bin array size: 60788
@@ -105,14 +104,14 @@ You can use the `hcitool lescan` to figure out the address of a DFU target, for
105
104
106
105
## TODO:
107
106
108
-
* Implement link-loss procedure for Legacy Controller.
109
-
* Update example output in readme.
110
-
* Add makefile examples.
111
-
* More code cleanup.
107
+
- Implement link-loss procedure for Legacy Controller.
0 commit comments