Wiki » AMiRo-BLT »

Startup Procedure

As defined in stage 1 of the SSSP startup phase, the very basic initialization of any system is hardware specific.
Thus, the AMiRo-BLT bootloaders implement the following further features:

  • Safe initialization of voltage regulated power supply lines.
  • Charging with minimal power draw without the need to load the operating system.
  • Detection of the wakeup reason and according reaction.

These tasks are handled by the PowerManagent and the DiWheelDrive only, so all other modules of a robot benefit of these features without needing to support them explicitly.

Used Signals and Registers

Besides the two mandatory system signals SYS_PD_N and SYS_SYNC_N, three additional system signals are used for this:

  • SYS_REG_EN - inactive (low) on initialization
  • SYS_UART_UP/DN - inactive (high) on initialization
  • SYS_WARMRST_N - active (low) on initialization

For some features it is required to know the reason for the last shutdown in order to react accordingly on startup.
This is achieved by using one of the permanent backup registers of the STM32F4 MCU of the PowerManagement.
As long as the MCU is attached to a power source, its content is preserved and not cleared on reset.
The content of the 32 bit backup register is divided into four 8 bit parts:

  1. primary reason for the last shutdown
  2. secondary reason for the last shutdown
  3. primary reason for the last wakeup
  4. secondary reason for the last wakeup

Implementation for AMiRo

Only the very first step of the SSSP startup phase needs to be extended for any hardware specific features.
The following steps are thus merely sub-steps that are executed right after the system signals have been initialized.

  1. detection of startup reason
    The PowerManagement as well as the DiWheelDrive evaluate the reason, why they have been woken up.
    In total there are twelve options:
    • low-power reset
    • window-watchdog reset
    • independent watchdog reset
    • software reset
    • power-on/power-down reset
    • pin reset
    • brownout reset
    • wakeup reset, caused by
      • SYS_UART_UP/DN signal
      • power plug attached (PowerManagement only)
      • touch sensor interrupt (PowerManagement only)
      • acceleration sensor interrupt (DiWheelDrive only)
  2. reaction according to the startup reason
    Depending on the detected reason for the startup and the information about the last shutdown (stored in the backup register), the system reacts in different ways:
    • software reset
      The reaction in this case depends on the last shutdown.
      • Hibernate
        The system was reset only to enter Hibernate mode.
        Thus, the independent watchdog is configured and the system enters standby mode.
      • Restart
        This case is handled like a pin reset.
      • DeepSleep
        This case only occurs if the system was shut down to DeepSleep mode, a power plug was detected, but no power is supplied through the plug.
        Similar to the Hibernate case, the independent watchdog is configured and the system enters DeepSleep mode again.
    • wakeup reset
      Several signals are combined (logical OR) and connected to the wakeup pin of the MCUs.
      • SYS_UART_DN signal (PowerManagement)
        This case is handled like a pin reset.
      • power plug attached (PowerManagement)
        This case is handled like a pin reset.
      • touch sensor interrupt (PowerManagement)
        This case is hanlded like a pin reset.
      • SYS_UART_UP signal (DiWheelDrive)
        This case is handled like a pin reset.
      • acceleration sensor interrupt (DiWheelDrive)
        In this case, the DiWheelDrive activates the SYS_UART_UP/DN signal for one millisecond, which will trigger the PowerManagement to wake up (see above).
        After inactivation of the signal, the same procedure as after a pin reset is executed.
    • independent watchdog reset (PowerManagement only)
      Depending on the original reason for shutdown, this case is handled differently.
      • DeepSleep
        The system voltage is measured once in order to detect whether the batteries can be charged.
        If voltage is too low, the system restarts the independent watchdog and enters low-power mode again.
        Otherwise the chargers are enabled and the system enters sleep-mode until one of the following events occurs:
        • touch sensor interrupt
          In this case, the system acts as if woken up by the touch sensors (wakeup reset).
        • SYS_UART_DN signal active (falling edge)
          In this case, the system acts as if woken up by the SYS_UART_DN signal (wakeup reset).
        • analog watchdog event
          In this case, the system voltage dropped and the batteries can not be charged anymore.
          After disabling the chargers, the system enters the previous low-power mode again.
        • power plug removed
          This case is only activated when the system was originally shut down to DeepSleep mode and a power plug was attached.
          Thus, as soon as the power plug is removed again, charging is disabled and the system enters DeepSleep mode again.
      • Hibernate
        This case is identical to DeepSleep with a minor exception.
        At the very beginning, the PowerManagement activates SYS_UART_DN to indicate the DiWheelDrive (which was just woken up by a pin reset) to enter Hibernate mode as well.
        After ten milliseconds the PowerManagement deactivates the signal and waits for the DiWheeöDrive to deactivate it as well.
        This way, both modules can handle any required initialization for the Hibernate mode before proceeding.
      • all others
        Even though this case will never occur as long as the bootloader callback functions for shutdown are used, it is handled the same way as a pin reset.
    • pin reset
      In this case, some additional preparations are made before the first synchronization in SSSP.
      These preparations further differ between the PowerManagement and the DiwheelDrive.
      • PowerManagement
        1. The 4.2V system supply voltage is enabled by setting the local POWER_EN signal active.
          A ten millisecond delay ensures stability of the voltage.
        2. The other regulated system supplies are enabled as well by setting SYS_REG_EN active.
          Another ten millisecond delay ensures stability of these voltages.
        3. All slave modules are woken up by deactivating SYS_WARMRST_N.
          Since these will now start to initialize their signals and SSSP specifies at least one millisecond for that, the PowerManagement waits a further millisecond before it proceeds.
        4. A loop is entered, which repeatedly checks whether a flash request was received via the serial interface and a new version of the operating system shall be written to the ROM.
          After a 500 milliseconds timeout, the SYS_SYNC_N signal is deactivated and the module has reached the second step of the SSSP startup phase.
          Note that the loop is still executed and SYS_SNC_N is evaluated with each iteration.
          If SYS_PD_N is activated by another AM, the PowerManagement initiates a Restart, which may also result in a shutdown.
      • DiWheelDrive
        An infinite loop is executed until one of the following events occurs:
        • SYS_WARMRST_N was deactivated.
          In this case, the same loop is entered as was described for the PowerManagement.
        • SYS_UART_UP was activated.
          In this case, the PowerManagement indicated the DiWheelDrive to stay in Hibernate mode.
          1. SYS_UART_UP is activated to act as busy flag, and the charging pins are enabled by activating PATH_DCEN.
          2. The DiWheelDrive waits ten milliseconds for the system supply voltage to become stable before disabling SYS_UART_UP again.
          3. The module enters sleep mode until it is reset externally (e.g. by the PowerManagement), or an interrupt from the acceleration sensor is received.
            In the latter case, the module acts as if the sensor woke it from standby mode.
        • A 100 millisecond timeout was reached.
          In this case, the module enters DeepSleep mode again.
    • all others
      In this case, the LED blinks "SOS" in Morse code (··· --- ···) and proceeds as after a pin reset.