This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
doc:lighthouse:bootloader [2019-02-26 17:22] arnaud |
doc:lighthouse:bootloader [2020-05-12 14:36] kimberly |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Lighthouse deck bootloader ====== | + | <WRAP center round important 60%> |
+ | This page is deprecated and is moved to the main Bitcraze website. Please go to: | ||
+ | |||
+ | [[ | ||
+ | https:// | ||
+ | ]] | ||
- | <WRAP center round important 70%> | ||
- | **Warning**: | ||
</ | </ | ||
+ | |||
+ | |||
+ | ====== Lighthouse deck bootloader ====== | ||
The [[projects: | The [[projects: | ||
Line 13: | Line 19: | ||
==== Uart protocol ==== | ==== Uart protocol ==== | ||
- | There is two UARTs on the deck, UART0 on the Crazyflie deck interface and UART1 on 2.54mm soldering pads available for external communication. The bootloader is available on both UARTs. The UARTs are setup with a baudrate of 115200. | + | There is two UARTs on the deck, UART0 on the Crazyflie deck interface and UART1 on 2.54mm soldering pads available for external communication. The bootloader is available on both UARTs. The UARTs are setup with a baudrate |
+ | |||
+ | <WRAP center round important> | ||
+ | **Warning**: | ||
+ | </ | ||
When using the UART, commands are sent on the RX line and answer will be sent back by the bootloader on the TX line. Since the bootloader and the Flash SPI bus are working much faster than the UART, there is no need for flow control. | When using the UART, commands are sent on the RX line and answer will be sent back by the bootloader on the TX line. Since the bootloader and the Flash SPI bus are working much faster than the UART, there is no need for flow control. | ||
Line 40: | Line 51: | ||
===== Bootloader protocol ===== | ===== Bootloader protocol ===== | ||
- | All numbers are expressed | + | All numbers are encoded |
==== Boot ==== | ==== Boot ==== | ||
Line 67: | Line 78: | ||
^ Byte # ^ Value ^ Note ^ | ^ Byte # ^ Value ^ Note ^ | ||
| 0-(RLEN-1) | | 0-(RLEN-1) | ||
+ | |||
+ | ==== Get version ==== | ||
+ | |||
+ | Returns the bootloader version. Can be useful to identify that the firmware currently running is the bootloader. | ||
+ | currently only version 1 exists | ||
+ | |||
+ | Sent to the bootloader: | ||
+ | |||
+ | ^ Byte # ^ Value ^ Note ^ | ||
+ | | 0 | 0x02 | Get version command | | ||
+ | |||
+ | Received from the bootloader: | ||
+ | |||
+ | ^ Byte # ^ Value ^ Note ^ | ||
+ | | 0 | 0x01 | Bootloader version | | ||
Line 97: | Line 123: | ||
===== Firmware versioning ===== | ===== Firmware versioning ===== | ||
- | The firmware is an iCE40 bitstream ((The bitstream format has been [[http:// | + | The firmware is an iCE40 bitstream ((The bitstream format has been [[http:// |
- | The version string format is a base 10 integer number in ascii indicating the version. For example " | + | The version string format is a base 10 integer number in ascii indicating the version. For example " |
In the context of the lighthouse firmware, versions >= 1 are released version and should be in parity (or handled) by the client connecting the board in order to boot the firmware. Versions <= 0 are development version and the intention is that the client will then boot it without further check. | In the context of the lighthouse firmware, versions >= 1 are released version and should be in parity (or handled) by the client connecting the board in order to boot the firmware. Versions <= 0 are development version and the intention is that the client will then boot it without further check. |