commit d54d2f07cf55f262267ac5bae4ff1549e315a0a6
Author: Thomas Schöpping <tschoepp@cit-ec.uni-bielefeld.de>
Date:   Fri Mar 16 11:43:09 2018 +0100

    Major overhaul (to version 1.1.0):
    - The bootloader toolchain now works with 32 bit device IDs (DiWheelDrive 1.1 = 0x01000101; PowerManagement 1.1 = 0x01010101; LightRing 1.0 = 0x017F0100).
      However, the system is still compatible to the old numbering scheme and legacy IDs for compatibility reasons.
      As a result, the new bootloader can be used with the old SerialBoot tool and vice versa.
    - In order to allow for 32 bit IDs, the CAN communication as modified.
      Packages which are larger than a single transmit are split into multiple CAN messages.
      An according handshaking mechanism (receiver acknowledges everey message) has been implemented.
      The device ID is not coded into the CAN message identifier anymore, but is transmitted as the first four bytes of the first CAN message of a XCP package transmission.
      However, the two lowermost bit of the CAN message identifier are now used as indicator flags for acknowledgment and subsequent transmission for simple filtering.
    - The bootloaders will not "double blink" the LED anymore, but indicate the XCP connection status.
    - The bootloader version has been incremented to 1.1.0.

diff --git a/Target/Modules/DiWheelDrive_1-1/Boot/blt_conf.h b/Target/Modules/DiWheelDrive_1-1/Boot/blt_conf.h
index 90e62d8..2d5f344 100644
--- a/Target/Modules/DiWheelDrive_1-1/Boot/blt_conf.h
+++ b/Target/Modules/DiWheelDrive_1-1/Boot/blt_conf.h
@@ -23,11 +23,11 @@
 * You should have received a copy of the GNU General Public License along with OpenBLT.
 * If not, see <http://www.gnu.org/licenses/>.
 *
-* A special exception to the GPL is included to allow you to distribute a combined work 
-* that includes OpenBLT without being obliged to provide the source code for any 
+* A special exception to the GPL is included to allow you to distribute a combined work
+* that includes OpenBLT without being obliged to provide the source code for any
 * proprietary components. The exception text is included at the bottom of the license
 * file <license.html>.
-* 
+*
 * \endinternal
 ****************************************************************************************/
 #ifndef BLT_CONF_H
@@ -37,17 +37,17 @@
 *   C P U   D R I V E R   C O N F I G U R A T I O N
 ****************************************************************************************/
 /* To properly initialize the baudrate clocks of the communication interface, typically
- * the speed of the crystal oscillator and/or the speed at which the system runs is 
+ * the speed of the crystal oscillator and/or the speed at which the system runs is
  * needed. Set these through configurables BOOT_CPU_XTAL_SPEED_KHZ and
  * BOOT_CPU_SYSTEM_SPEED_KHZ, respectively. To enable data exchange with the host that is
- * not dependent on the targets architecture, the byte ordering needs to be known. 
- * Setting BOOT_CPU_BYTE_ORDER_MOTOROLA to 1 selects little endian mode and 0 selects 
+ * not dependent on the targets architecture, the byte ordering needs to be known.
+ * Setting BOOT_CPU_BYTE_ORDER_MOTOROLA to 1 selects little endian mode and 0 selects
  * big endian mode.
- * 
+ *
  * Set BOOT_CPU_USER_PROGRAM_START_HOOK to 1 if you would like a hook function to be
  * called the moment the user program is about to be started. This could be used to
  * de-initialize application specific parts, for example to stop blinking an LED, etc.
- */ 
+ */
 /** \brief Frequency of the external crystal oscillator. */
 #define BOOT_CPU_XTAL_SPEED_KHZ         (8000)
 /** \brief Desired system speed. */
@@ -66,7 +66,7 @@
  * have to be controlled by this bootloader. Additionally the bootloader should be able
  * to send program code of user programs for other devices.
  * Make sure that one of the communication interfaces is the gateway!
- */ 
+ */
 /** \brief Bootloader of main device. */
 #define BOOTLOADER_OF_MAIN_DEVICE       (1)
 
@@ -74,52 +74,64 @@
 /****************************************************************************************
 *   C O M M U N I C A T I O N   I N T E R F A C E   C O N F I G U R A T I O N
 ****************************************************************************************/
-/* The CAN communication interface is selected by setting the BOOT_COM_CAN_ENABLE 
+/* The CAN communication interface is selected by setting the BOOT_COM_CAN_ENABLE
  * configurable to 1. Configurable BOOT_COM_CAN_BAUDRATE selects the communication speed
- * in bits/second. Two CAN messages are reserved for communication with the host. The 
+ * in bits/second. Two CAN messages are reserved for communication with the host. The
  * message identifier for sending data from the target to the host is configured with
  * BOOT_COM_CAN_TXMSG_ID. The one for receiving data from the host is configured with
- * BOOT_COM_CAN_RXMSG_ID. The maximum amount of data bytes in a message for data 
- * transmission and reception is set through BOOT_COM_CAN_TX_MAX_DATA and 
+ * BOOT_COM_CAN_RXMSG_ID. The maximum amount of data bytes in a message for data
+ * transmission and reception is set through BOOT_COM_CAN_TX_MAX_DATA and
  * BOOT_COM_CAN_RX_MAX_DATA, respectively. It is common for a microcontroller to have more
  * than 1 CAN controller on board. The zero-based BOOT_COM_CAN_CHANNEL_INDEX selects the
  * CAN controller channel.
- * 
+ *
  */
 /** \brief Enable/disable CAN transport layer. */
 #define BOOT_GATE_CAN_ENABLE            (1)
 /** \brief Configure the desired CAN baudrate. */
-#define BOOT_COM_CAN_BAUDRATE           (500000)
+#define BOOT_COM_CAN_BAUDRATE           (1000000)
 /** \brief Configure CAN message ID target->host. */
-#define BOOT_COM_CAN_TX_MSG_ID          (0x700) //(0x7E1)
+#define BOOT_COM_CAN_TX_MSG_ID          (0x700)
 /** \brief Configure number of bytes in the target->host CAN message. */
 #define BOOT_COM_CAN_TX_MAX_DATA        (255)
 /** \brief Configure CAN message ID host->target. */
-#define BOOT_COM_CAN_RX_MSG_ID          (0x600) //(0x667)
+#define BOOT_COM_CAN_RX_MSG_ID          (0x600)
 /** \brief Configure number of bytes in the host->target CAN message. */
 #define BOOT_COM_CAN_RX_MAX_DATA        (255)
 /** \brief Select the desired CAN peripheral as a zero based index. */
 #define BOOT_COM_CAN_CHANNEL_INDEX      (0)
+/** \brief Configure CAN message acknowledgement ID addition (ORed with original ID). */
+#define BOOT_COM_CAN_MSG_ACK            (0x001)
+/** \brief Configure CAN message ID addition for continuous messages (ORed with original ID). */
+#define BOOT_COM_CAN_MSG_SUBSEQUENT     (0x002)
 
-/** \brief Configure device ID for communication (start with 1). */
-#define BOOT_COM_DEVICE_ID              (0x1)
+/**
+ * \brief Configure device ID for communication (start with 1).
+ * \details The device ID is a 32 bit integer, which can be interpreted bytewise:
+ *            <AMiRo_revision>:<moduleID>:<moduleVersion_major>:<moduleVersion_minor>
+ *          For this module the according values are
+ *            1:0:1:1 = 0x01000101
+ */
+#define BOOT_COM_DEVICE_ID              (0x01000101)
+/** \brief Configure legacy device ID. */
+#define BOOT_COM_DEVICE_LEGACY_ID       (0x1)
 
-/* The UART communication interface is selected by setting the BOOT_COM_UART_ENABLE 
+/* The UART communication interface is selected by setting the BOOT_COM_UART_ENABLE
  * configurable to 1. Configurable BOOT_COM_UART_BAUDRATE selects the communication speed
- * in bits/second. The maximum amount of data bytes in a message for data transmission 
- * and reception is set through BOOT_COM_UART_TX_MAX_DATA and BOOT_COM_UART_RX_MAX_DATA, 
+ * in bits/second. The maximum amount of data bytes in a message for data transmission
+ * and reception is set through BOOT_COM_UART_TX_MAX_DATA and BOOT_COM_UART_RX_MAX_DATA,
  * respectively. It is common for a microcontroller to have more than 1 UART interface
  * on board. The zero-based BOOT_COM_UART_CHANNEL_INDEX selects the UART interface.
- * 
+ *
  */
 /** \brief Enable/disable UART transport layer. */
 #define BOOT_COM_UART_ENABLE            (1)
 /** \brief Configure the desired communication speed. */
-#define BOOT_COM_UART_BAUDRATE          (115200) //(57600)
+#define BOOT_COM_UART_BAUDRATE          (115200)
 /** \brief Configure number of bytes in the target->host data packet. */
-#define BOOT_COM_UART_TX_MAX_DATA       (255) //(64)
+#define BOOT_COM_UART_TX_MAX_DATA       (255)
 /** \brief Configure number of bytes in the host->target data packet. */
-#define BOOT_COM_UART_RX_MAX_DATA       (255) //(64)
+#define BOOT_COM_UART_RX_MAX_DATA       (255)
 /** \brief Select the desired UART peripheral as a zero based index. */
 #define BOOT_COM_UART_CHANNEL_INDEX     (0)
 /* Activate debugging with UART2 */
@@ -130,8 +142,8 @@
 *   F I L E   S Y S T E M   I N T E R F A C E   C O N F I G U R A T I O N
 ****************************************************************************************/
 /* The file system interface is selected by setting the BOOT_FILE_SYS_ENABLE configurable
- * to 1. This enables support for firmware updates from a file stored on a locally 
- * attached file system such as an SD-card. Note that this interface can be enabled 
+ * to 1. This enables support for firmware updates from a file stored on a locally
+ * attached file system such as an SD-card. Note that this interface can be enabled
  * together with one of the remote communication interfaces such as UART, CAN or USB.
  *
  * Set BOOT_FILE_LOGGING_ENABLE to 1 if you would like log messages to be created during
@@ -145,29 +157,29 @@
  * additional information on the error cause.
  *
  * Set BOOT_FILE_STARTED_HOOK_ENABLE to 1 if you would like to be informed when a new
- * firmware update is started by the bootloader. 
+ * firmware update is started by the bootloader.
  *
  * Set BOOT_FILE_COMPLETED_HOOK_ENABLE to 1 if you would like to be informed when a
- * firmware update is completed by the bootloader. 
+ * firmware update is completed by the bootloader.
  */
 /** \brief Enable/disable support for firmware updates from a locally attached storage.*/
 #define BOOT_FILE_SYS_ENABLE            (0)
 /** \brief Enable/disable logging messages during firmware updates. */
 #define BOOT_FILE_LOGGING_ENABLE        (1)
 /** \brief Enable/disable a hook function that is called upon detection of an error. */
-#define BOOT_FILE_ERROR_HOOK_ENABLE     (1)   
+#define BOOT_FILE_ERROR_HOOK_ENABLE     (1)
 /** \brief Enable/disable a hook function that is called at the start of the update. */
-#define BOOT_FILE_STARTED_HOOK_ENABLE   (1)   
+#define BOOT_FILE_STARTED_HOOK_ENABLE   (1)
 /** \brief Enable/disable a hook function that is called at the end of the update. */
-#define BOOT_FILE_COMPLETED_HOOK_ENABLE (1)   
+#define BOOT_FILE_COMPLETED_HOOK_ENABLE (1)
+
 
-   
 /****************************************************************************************
 *   B A C K D O O R   E N T R Y   C O N F I G U R A T I O N
 ****************************************************************************************/
 /* It is possible to implement an application specific method to force the bootloader to
  * stay active after a reset. Such a backdoor entry into the bootloader is desired in
- * situations where the user program does not run properly and therefore cannot 
+ * situations where the user program does not run properly and therefore cannot
  * reactivate the bootloader. By enabling these hook functions, the application can
  * implement the backdoor, which overrides the default backdoor entry that is programmed
  * into the bootloader. When desired for security purposes, these hook functions can
@@ -213,15 +225,15 @@
 *   S E E D / K E Y   S E C U R I T Y   C O N F I G U R A T I O N
 ****************************************************************************************/
 /* A security mechanism can be enabled in the bootloader's XCP module by setting configu-
- * rable BOOT_XCP_SEED_KEY_ENABLE to 1. Before any memory erase or programming 
- * operations can be performed, access to this resource need to be unlocked. 
- * In the Microboot settings on tab "XCP Protection" you need to specify a DLL that 
- * implements the unlocking algorithm. The demo programs are configured for the (simple) 
- * algorithm in "FeaserKey.dll". The source code for this DLL is available so it can be 
- * customized to your needs. 
+ * rable BOOT_XCP_SEED_KEY_ENABLE to 1. Before any memory erase or programming
+ * operations can be performed, access to this resource need to be unlocked.
+ * In the Microboot settings on tab "XCP Protection" you need to specify a DLL that
+ * implements the unlocking algorithm. The demo programs are configured for the (simple)
+ * algorithm in "FeaserKey.dll". The source code for this DLL is available so it can be
+ * customized to your needs.
  * During the unlock sequence, Microboot requests a seed from the bootloader, which is in
- * the format of a byte array. Using this seed the unlock algorithm in the DLL computes 
- * a key, which is also a byte array, and sends this back to the bootloader. The 
+ * the format of a byte array. Using this seed the unlock algorithm in the DLL computes
+ * a key, which is also a byte array, and sends this back to the bootloader. The
  * bootloader then verifies this key to determine if programming and erase operations are
  * permitted.
  * After enabling this feature the hook functions XcpGetSeedHook() and XcpVerifyKeyHook()
