Commit ecf850c4 authored by Thomas Schöpping's avatar Thomas Schöpping
Browse files

documentation revised

parent 29dbcd7c
......@@ -41,43 +41,57 @@ References
Contents
--------
1. Required Software
1. Introduction
2. Required Software
1. Git
2. GNU Make
3. GCC
4. stm32flash
5. GNU ARM Embedded Toolchain
6. CMake
2. Recommended Software
3. Recommended Software
1. PlantUML
2. QtCreator IDE
3. Compiling the Source Code
4. Compiling the Source Code
1. Host Software
2. Target Software
---
1 - Required Software
1 - Introduction
================
AMiRo-BLT is the bootloader and flashing toolchain for the base version of the Autonomous Mini Robot (AMiRo) [1].
It is based on OpenBLT developed by Feaser (see <http://feaser.com/en/openblt.php>) and implemements the [Startup Shutdown Synchronization Protocol (SSSP)](https://gitlab.ub.uni-bielefeld.de/AMiRo/sssp).
While this file provides information for end users of AMiRo-BLT, developers can refer to the [`./docs/`](./docs/) folder for further readings:
- [AMiRo system signals](./docs/system_signals.md)
- [low-power modes](./docs/low_power_modes.md)
- [OS interface](./docs/os_interface.md)
2 - Required Software
=====================
In order to compile and flash the AMiRo bootloader, some additional software is required, all of which are described in detail in the following.
1.1 - Git
2.1 - Git
---------
Since all main- and subprojects are available as Git repositories, installing a recent version of the tool is mandatory.
Most Linux distributions like Ubuntu provide a sufficient version in their software repositories.
1.2 - GNU Make
2.2 - GNU Make
---------------
GNU Make usually comes as preinstalled tool on Ubuntu based operating systems.
If your system is missing GNU Make, it is recommended to install it from the standard repositories since no special requirements (i.e. features of a very recent version) are required.
1.3 - GCC
2.3 - GCC
---------
In order to build some required tools from source, GCC is required.
......@@ -85,7 +99,7 @@ It usually comes as preinstalled tool on Ubuntu based operating systems.
If your system is missing GCC, it is recommended to install it from the standard repositories since no special requirements (e.g. features of a very recent version) are required.
1.4 - stm32flash
2.4 - stm32flash
-----------------
This tool is required to flash the bootloader binaries to the microcontrollers of the AMiRo base modules.
......@@ -108,7 +122,7 @@ If you do have root permissions on your system, you can install the tool this wa
However, the scripts will always check for a "local" installation in [`./Host/Source/stm32flash/`](./Host/Source/stm32flash/) first and only try a system-wide installation afterwards.
1.5 - GNU ARM Embedded Toolchain
2.5 - GNU ARM Embedded Toolchain
--------------------------------
Various versions of the GCC for ARM embedded devices can be found at <https://developer.arm.com/open-source/gnu-toolchain/gnu-rm> (old versions are available at <https://launchpad.net/gcc-arm-embedded>).
......@@ -125,7 +139,7 @@ sudo apt-get update
sudo apt-get install libc6:i386 libstdc++6:i386 libncurses5:i386
```
1.6 - CMake
2.6 - CMake
-----------
In order to build the SerialBoot host application, CMake version 2.8 or later is required.
......@@ -133,13 +147,13 @@ If possible, it is recommended to instal it from the standard repositories of yo
2 - Recommended Software
3 - Recommended Software
========================
The software tools named in this section are not essential for simply using or further development of AMiRo-BLT, but are useful in both scenarios.
2.1 - PlantUML
3.1 - PlantUML
--------------
PlantUML is a free and open source Java tool to generate UML diagrams via scrips (see <https://plantuml.com>).
......@@ -147,7 +161,7 @@ AMiRo-BLT provides according scripts in the [`./Target/docs/`](./Target/docs/) d
Please refer to the PlantUML documentation for how to generate figures from these script files.
2.2 - QtCreator IDE
3.2 - QtCreator IDE
-------------------
AMiRo-BLT provides support for the QtCreator IDE.
......@@ -156,7 +170,7 @@ It will automatically generate the required files and you can import the project
Please note that you will need to recompile the AMiRo-BLT source code after each project generation, since the generator executes a compiler call.
3 - Compiling the Source Code
4 - Compiling the Source Code
-----------------------------
The AMiRo-BLT project is separated into two major parts: target- and host-related software.
......@@ -165,7 +179,7 @@ The latter are the stm32flash tool as already mentioned above and the SerialBoot
Since the programming connector of the lowermost AMiRo module (_DiWheelDrive_) is the only one accessible when the robot is fully set up, this enables to update the firmware even for other modules.
3.1 - Host Software
4.1 - Host Software
-------------------
The stm32flash tool is requried to flash bootloader binaries to the MCUs.
......@@ -177,7 +191,7 @@ To ensure compatibility with other software (e.g. [AMiRo-OS](https://gitlab.ub.u
In the end, the binary path should be `./Host/Source/SerialBoot/build/SerialBoot`, which is the default for any scripts and tools that use SerialBoot.
3.2 - Target Software
4.2 - Target Software
---------------------
Module specific code for the several AMiRo base modules is located in the individual subfolders in the [`./Target/Modules/`](./Target/Modules/) directory.
......
AMiRo-BLT
=========
The documentation of the AMiRo-BLT project is split up into several parts:
1. [System Signals](#system-signals) available on the AMiRo platform and which
are used during startup and shutdown
2. [Low-Power Modes](#low-power-modes) AMiRo can enter
3. [Bootloader](#bootloader) software for the microcontrollers of AMiRo
4. [SerialBoot](#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.md 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<br/>
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<br/>
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<br/>
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)<br/>
Originally meant for system wide interrupts, this signal is now used to
synchronize the AMs during startup, shutdown and operation (cf.
[SSSP](https://gitlab.ub.uni-bielefeld.de/AMiRo/sssp)).
- SYS\_UART\_UP/DN<br/>
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<br/>
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\_COLDRST\_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)](https://gitlab.ub.uni-bielefeld.de/AMiRo/sssp) and any further
particularities (e.g. for the PowerManagement to be the master node), which are
described in detail on two separate documentation pages for
[startup](startup.md) and [shutdown](shutdown.md).
Furthermore, the bootloaders offer an [interface](interface.md) 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](https://gitlab.ub.uni-bielefeld.de/AMiRo/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](https://sourceforge.net/projects/stm32flash/)) is used. See the
README.md file provided in the repository for details.
OS Interface
============
The bootloader provides an interface for the operating system providing various
information. Most importantly, these include the definition of the CallbackTable
and its memory address as well as the definition of the contents of the backup
register for the PowerManagement module.
The 64 byte CallbackTable contains information about the AMiRo-BLT version and
several function pointers. The former can be used to detect whether the
installed bootloader corresponds to the interface or if a legacy version is
installed (or none at all). The latter shall be used as callbacks for restarting
the system or shut down. This way, the operating system is freed from most
aspects of the [Startup Shutdown Synchronization Protocol
(SSSP)](https://gitlab.ub.uni-bielefeld.de/AMiRo/sssp).
About & License
===============
AMiRo-BLT is the bootloader and flashing toolchain for the base version of the
Autonomous Mini Robot (AMiRo) [1]. It is based on OpenBLT developed by Feaser
(see <http://feaser.com/en/openblt.php>).
Copyright (C) 2016..2020 Thomas Schöpping et al. (a complete list of all authors
is given below)
This program is free software: you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation, either version 3 of the License, or (at your option) any later
version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with
this program. If not, see <http://www.gnu.org/licenses/>.
This research/work was supported by the Cluster of Excellence Cognitive
Interaction Technology 'CITEC' (EXC 277) at Bielefeld University, which is
funded by the German Research Foundation (DFG).
Authors
-------
- Thomas Schöpping (tschoepp[at]cit-ec.uni-bielefeld.de)
- Stefan Herbrechtsmeier
- Marvin Barther
References
----------
**[1]** S. Herbrechtsmeier, T. Korthals, T. Schopping and U. Rückert, "AMiRo: A modular & customizable open-source mini robot platform," 2016 20th International Conference on System Theory, Control and Computing (ICSTCC), Sinaia, 2016, pp. 687-692.
---
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 to 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 aforementioned 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 up again is by activating the `SYS_COLDRST_N` signal (see [signals documentation](./system_signals.md)) via a programming cable.
About & License
===============
AMiRo-BLT is the bootloader and flashing toolchain for the base version of the
Autonomous Mini Robot (AMiRo) [1]. It is based on OpenBLT developed by Feaser
(see <http://feaser.com/en/openblt.php>).
Copyright (C) 2016..2020 Thomas Schöpping et al. (a complete list of all authors
is given below)
This program is free software: you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation, either version 3 of the License, or (at your option) any later
version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with
this program. If not, see <http://www.gnu.org/licenses/>.
This research/work was supported by the Cluster of Excellence Cognitive
Interaction Technology 'CITEC' (EXC 277) at Bielefeld University, which is
funded by the German Research Foundation (DFG).
Authors
-------
- Thomas Schöpping (tschoepp[at]cit-ec.uni-bielefeld.de)
- Stefan Herbrechtsmeier
- Marvin Barther
References
----------
**[1]** S. Herbrechtsmeier, T. Korthals, T. Schopping and U. Rückert, "AMiRo: A modular & customizable open-source mini robot platform," 2016 20th International Conference on System Theory, Control and Computing (ICSTCC), Sinaia, 2016, pp. 687-692.
---
OS Interface
============
The bootloader provides an interface (cf. [`amiroblt.h`](../Target/Source/AMiRo/amiroblt.h)) for the operating system providing various information.
Most importantly, these include the definition of the "callback table" and its memory address as well as the definition of the contents of the backup register for the _PowerManagement_ module.
The 64 byte callback table contains information about the AMiRo-BLT version and several function pointers.
The former can be used to detect whether the installed bootloader corresponds to the interface or if a legacy version is installed (or none at all).
The latter shall be used as callbacks for restarting the system or shutdown.
This way, the operating system is freed from most aspects of the [Startup Shutdown Synchronization Protocol (SSSP)](https://gitlab.ub.uni-bielefeld.de/AMiRo/sssp).
Callback Table
--------------
| bytes | content | description |
|:-----:|:--------------------------|:--------------------------------------------------------------------------------------------------------------------------|
| 1-4 | magic number | Can be used to check whether is is valid to interprete the data at this address as callback table . |
| 5-8 | bootloader version | Version information about the installed bootloader. |
| 9-12 | SSSP version | Information about the implemented version of [SSSP](https://gitlab.ub.uni-bielefeld.de/AMiRo/sssp). |
| 13-16 | compiler version | Version information about the used compiler to build the bootloader. |
| 17-20 | hibernate callback | Pointer to a function that shuts the system down to Hibernate mode (cf. [low-power modes](./low_power_modes.md)). |
| 21-24 | deepsleep callback | Pointer to a function that shuts the system down to DeepSleep mode (cf. [low-power modes](./low_power_modes.md)). |
| 25-28 | transportation callback | Pointer to a function that shuts the system down to Transportation mode (cf. [low-power modes](./low_power_modes.md)). |
| 29-32 | restart callback | Pointer to a function that restarts the system. |
| 33-36 | shutdown request callback | Pointer to a function that handles passive shutdown requests (cf. [SSSP](https://gitlab.ub.uni-bielefeld.de/AMiRo/sssp)). |
| 37-40 | n/a | Yet unused slot in the callback table. |
| 41-44 | n/a | Yet unused slot in the callback table. |
| 45-48 | n/a | Yet unused slot in the callback table. |
| 49-52 | n/a | Yet unused slot in the callback table. |
| 53-56 | n/a | Yet unused slot in the callback table. |
| 57-60 | n/a | Yet unused slot in the callback table. |
| 61-64 | n/a | Yet unused slot in the callback table. |
Shutdown Procedure
==================
Currently, four different shutdown procedures are implemented to enter the
various [low-power modes](index.md#low-power-modes). They are all very similar,
but differentiate in some details and between the AMiRo Modules (AMs). The basic
procedure is defined as follows:
1. The signals SYS\_SYNC\_N and SYS\_PD\_N are both set active.
2. *first custom operation*
3. Some GPIO pins are reconfigured as inputs. This is required, because
otherwise a high output could unintentionally power periphery hardware, which
is intended to be turned off. More specifically, these are all signals, which
are inputs of hardware that is powered by a regulated power supply voltage.
Whenever the supply is disabled, these elements should be turned off, but if
the MCU then drives an input high, it might power up again.
4. *second custom operation*
5. SYS\_SYNC\_N is deactivated and each module waits until it is deactivated by
all other AMs as well.
6. *third custom operation*
7. The board LED (if available) signals "OK" in Morse code (--- -·-).
8. All modules enter low-power mode or reset.
As defined in
[SSSP](https://gitlab.ub.uni-bielefeld.de/AMiRo/sssp/-/blob/master/version_1.x/SSSP_1-2.md#shutdown-phase),
the state of SYS\_PD\_N in the moment when SYS\_SYNC\_N becomes inactive
specifies whether the system will shutdown or restart.
In the following, the four procedures with their particularities for each board
are described one by one. As a matter of fact, the custom operation steps are
empty for most AMs. The only modules, that act somewhat differently are the
PowerManagement and the DiWheelDrive. Hence, only these two are addressed in the
following.
Transportation
--------------
### PowerManagement
1. *first custom operation*<br/>
nothing (just proceeding to the next step)
2. *second custom operation*<br/>
nothing (just proceeding to the next step)
3. *third custom operation*
1. cutting power
1. deactivation of SYS_WARMRST_N
2. deactivation of SYS_REG_EN
3. deactivation of POWER_EN
4. Waits ten milliseconds to make sure, everything is shut down.
2. disables all wakeup sources
1. disables the WKUP pin
2. disables any RTC events
3. disables the independent watchdog
3. writing information to the backup register (see
[startup](startup.md#startup-procedure))
At the end of the shutdown procedure, the module enters standby mode.
### DiWheelDrive
1. *first custom operation*<br/>
nothing (just proceeding to the next step)
2. *second custom operation*
1. cutting power of the motors by setting POWER\_EN inactive
2. deactivation of all wakeup sources
1. deactivation of the WKUP pin
2. deactivation of any RTC events
3. deactivation of the independent watchdog
3. *third custom operation*<br/>
nothing (just proceeding to the next step)
At the end of the shutdown procedure, the module enters standby mode.
DeepSleep
---------
### PowerManagement
1. *first custom operation*<br/>
nothing (just proceeding to the next step)
2. *second custom operation*<br/>
nothing (just proceeding to the next step)
3. *third custom operation*
1. cutting power
1. deactivation of SYS_WARMRST_N
2. deactivation of SYS_REG_EN
3. deactivation of POWER_EN
4. Waits ten milliseconds to make sure, everything is shut down.
2. configuration of wakeup sources<br/>
Whilst the WKUP pin is enabled explicitly, RTC and independent watchdog
are not configured and thus can be initialized by other means.
3. writing information to the backup register (see
[startup](startup.md#startup-procedure))
At the end of the shutdown procedure, the module tests whether a power plug is
attached. If so, it restarts and will enter Hibernate mode on startup, else the
MCU enters standby mode.
### DiWheelDrive
1. *first custom operation*<br/>
nothing (just proceeding to the next step)
2. *second custom operation*
1. cutting power of the motors by setting POWER\_EN inactive
2. configuration of wakeup sources<br/>
Whilst the WKUP pin is enabled explicitly, RTC and independent watchdog
are not configured and thus can be initialized by other means.
3. *third custom operation*<br/>
nothing (just proceeding to the next step)
At the end of the shutdown procedure, the module enters standby mode.
Hibernate
---------
### PowerManagement
1. *first custom operation*<br/>
nothing (just proceeding to the next step)
2. *second custom operation*<br/>
nothing (just proceeding to the next step)
3. *third custom operation*
1. cutting power
1. deactivation of SYS_WARMRST_N
2. deactivation of SYS_REG_EN
3. deactivation of POWER_EN
4. Waits ten milliseconds to make sure, everything is shut down.
2. writing information to the backup register (see
[startup](startup.md#startup-procedure))
At the end of the shutdown procedure, the MCU resets and will enter Hibernate
mode on startup.
### DiWheelDrive
Since the DiWheelDrive can not initiate Hibernate mode (only the PowerManagement
can do that), there is no special shutdown sequence for this case. All
particularities for Hibernate mode are handled during
[startup](startup.md#startup-procedure).
Restart
-------
### PowerManagement
1. *first custom operation*
1. Waits one millisecond to ensure, all modules could detect the state of
SYS\_PD\_N.
2. setting SYS\_PD\_N inactive
3. Waits another millisecond for the same reason.
2. *second custom operation*<br/>
nothing (just proceeding to the next step)
3. *third custom operation*
1. cutting power
1. deactivation of SYS_WARMRST_N
2. deactivation of SYS_REG_EN
3. deactivation of POWER_EN
4. Waits ten milliseconds to make sure, everything is shut down.
2. writing information to the backup register (see
[startup](startup.md#startup-procedure))
At the end of the shutdown procedure, the MCU will either enter the default
low-power mode (DeepSleep) or reset, depending on the state of SYS\_PD\_N.
### DiWheelDrive
1. *first custom operation*
1. Waits one millisecond to ensure, all modules could detect the state of SYS\_PD\_N.