AMiRo-BLT¶
The documentation of the AMiRo-BLT project is split up into several parts:- control signals available on the AMiRo platform and which are used during startup and shutdown
- low-power modes AMiRo can enter
- bootloader software for the microcontrollers of AMiRo
- SerialBoot flashing tool to update the software (operating system) on the microcontrollers via the bootloader
For information about how to setup your environment and to compile/flash the software, please refer to the README.txt file provided in the repository.
System Signals¶
The electrical interface of AMiRo, which connects all AMiRo Modules (AMs), defines six control- and status signals:
Signals¶
- SYS_COLDRST_N
Resets the whole system the hard way. Whenever the signal is active (low), all microcontrollers (MCUs) are reset and power is completely turned off. As soon as the signal turns inactive (high) again, the MCUs restart. - SYS_PD_N
This signal is usually set inactive (high) and not used during operation. Any AM can activate it (pull it low) to initiate a system shutdown or restart. - SYS_REG_EN
When set active (high), this signal indicates that it is safe to activate any voltage converters that use the system power supply (VSYS) to generate custom voltage. Whenever it is inactive (low), such converters must be turned off. - SYS_SYNC_N (aka SYS_INT_N)
Originally meant for system wide interrupts, this signal is now used to synchronize the AMs during startup, shutdown and operation (cf. SSSP). - SYS_UART_UP/DN
A neighbor signal, which can be used to communicate between neighboring AMs. Except for the DiWheelDrive and the LightRing, which are the top- and lowermost modules, each AM must provide both signals.
(Note: despite the naming, these signals are not used for UART communication.) - SYS_WARMRST_N
Resets all slave modules the hard way. Only the PowerManagement and the DiWheelDrive are not defined as slave modules.
Pull-up/down Configuration¶
All control signals are designed for open-drain access and thus are passively pulled up or down to a specific voltage:
| signal | pull-up/down voltage | logically 'active' | default state |
|---|---|---|---|
| SYS_COLDRST_N | VDD (3.3V) | low | inactive (high) |
| SYS_PD_N | VIO3.3 (3.3V) | low | inactive (high) |
| SYS_REG_EN | GND (0V) | high | inactive (low) |
| SYS_SYNC_N | VIO3.3 (3.3V) | low | inactive (high) |
| SYS_UART_UP/DN | VDD (3.3V) | low | inactive (high) |
| SYS_WARMRST_N | VIO3.3 (3.3V) | low | inactive (high) |
This design allows to use the active state of each signal as logical OR (one or more AMs have activated the signal), and the inactive state as logical AND (no AM has activated the signal).
It is very important to note the different pull-up voltages. While VDD is available at any time (even when the system is turned off), VIO3.3 is enabled/disabled via SYS_REG_EN. Consequently, the signals SYS_PD_N, SYS_SYNC_N, and SYS_WARMRST_N can only be low (or undefined) as long as SYS_REG_EN is inactive. When activated, SYS_REG_EN is pushed to VDD (3.3V).
Read/Write Permissions¶
Whereas some signals are bus-like and can be read and written from any AM, others are read only except for a single master node:
| SYS_COLDRST_N | SYS_PD_N | SYS_REG_EN | SYS_SYNC_N | SYS_UART_UP/DN | SYS_WARMRST | |
| LightRing | read only | read & write | read only | read & write | read & write | read only |
| extension modules | read only | read & write | read only | read & write | read & write | read only |
| PowerManagement | read & write | read & write | read & write | read & write | read & write | read & write |
| DiWheelDrive | read only | read & write | read only | read & write | read & write | read only |
Low-Power Modes¶
Three low-power modes that can be entered after system shutdown have been defined for the AMiRo system so far.
Hibernate¶
Most of the time the system will stay in standby and thus draw as little power as possible.
It wakes up periodically, though, and measures the system supply voltage.
If it is found to be too low to charge the batteries, the system will enter standby again, or enable charging otherwise.
The main feature of this low-power mode is the capability to charge via the charging pins of the DiWheelDrive using a station.
The drawback is, that both modules, PowerManagement and DiWheelDrive, need to start up and stay awake for about 50-100 milliseconds for each voltage measurement.
Even though the rest of the robot is still turned off, this periodical power draw massively reduces the time the system can be stored without charging.
DeepSleep¶
When the system entered DeepSleep mode, it will only wake up if one of the following events occurs:
- A power plug is inserted to the PowerManagement.
- The touch sensor fires an interrupt event.
- The acceleration sensor fires an interrupt event.
- Any RTC (real-time clock) event occurs on the PowerManagement or the DiWheelDrive.
- An independent watchdog reset event occurs on one of the PowerManagement or the DiWheelDrive.
In most cases the system will react by completely starting up, except when a power plug is detected, which makes it switch to hibernate mode.
This way the system usually draws as little power as possible and can still be charged using a power cord.
The worst case would be when a plug is detected but not powered, so that the system will wake up periodically (see hibernate mode) and draw energy.
Transportation¶
Very similar to DeepSleep mode, the system enters standby for maximum power saving.
However, the before mentioned events, which were used to wake the system again, are completely deactivated in this mode.
This is particularly useful during transportation of the robot, so shaking for instance will not wake the system.
The drawbacks, however, are the missing possibility to charge the system and that the only way to wake it again is by activating the SYS_COLDRST_N signal via a programming cable.
Bootloader¶
The bootloaders for all microcontroller based AMiRo Modules (sometimes referred to as 'target software') are part of the AMiRo-BLT software.
They implement the Startup Shutdown Synchronization Protocol (SSSP) and any further particularities (e.g. for the PowerManagement to be the master node), which are described in detail on two separate wiki pages for startup and shutdown.
Furthermore, the bootloaders offer an interface for the operating system to read information like version number and callback function pointers.
The former can be used for sanity checks or to set according compatibility modes if required.
The latter are primarily provided to shutdown or restart the system, since these callback functions already implement all signal handling as defined by SSSP.
SerialBoot¶
As another part of the AMiRo-BLT software, the SerialBoot flashing tool (sometimes referred to as 'host software') in combination with the bootloaders provide the ability to update the operating system of any microcontroller based module in the system.
Since the programming connector of DiWheelDrive is the only one accessible when the robot is fully set up (all others are hidden behind the tube body), SerialBoot can configure its bootloader to propagate the binary data to any specified target module via CAN.
During development, the same procedure is possible when connecting to the PowerManagement as well, but no other AM.
Note that SerialBoot can not be used to update the bootloaders of the modules.
For that purpose another tool (stm32flash) is used.
See the README.txt file provided in the repository for details.