M-Boot ROM Description
598
SPRUHE8E – October 2012 – Revised November 2019
Copyright © 2012–2019, Texas Instruments Incorporated
ROM Code and Peripheral Booting
The device communicating with the bootloader is responsible for driving the SSI0_RX, SSI0_CLK, and
SSI0_CS pins, while the Concerto microcontroller drives the SSI0_TX pin.
The serial data format is fixed to the Motorola format with SPH set to 1 and SPO set to 1 (see the
applicable Concerto family data sheet for more information on this format).
When an application calls back to the ROM-based bootloader to start an update over the SSI port, the SSI
configuration and pin configuration is bypassed. Therefore, the SSI port must be configured and the SSI
pins switched to their hardware function before calling the bootloader.
6.5.15.1.3 I2C Interface
The I2C0 interface bootloader uses the below GPIO pins for I2C communications.
I2C0_CLK
PB2_GPIO10, peripheral MODE -1
I2C0_DATA
PB3_GPIO11, peripheral MODE -1
The device communicating with the bootloader must operate as the I2C master and provide the I2C0_CLK
signal. The I2C0_DATA pin is open-drain and can be driven by either the master or the slave I2C device.
The I2C interface can run at up to 400 KHz, the maximum rate supported by the I2C protocol. The
bootloader uses an I2C slave address of 0x42.
When an application calls back to the ROM-based bootloader to start an update over the I2C port, the I2C
configuration and pin configuration is bypassed. Therefore, the I2C port must be configured, the I2C slave
address set, and the I2C pins switched to their hardware function before calling the bootloader.
Additionally, the I2C master must be enabled since it is used to detect start and stop conditions on the I2C
bus.
6.5.15.1.4 M-Boot ROM Serial Boot Protocol
The bootloader uses well-defined packets on the serial interfaces to ensure reliable communications with
the update program. The packets are always acknowledged or not acknowledged by the communicating
devices. The packets use the same format for receiving and sending packets. This includes the method
used to acknowledge successful or unsuccessful reception of a packet. While the actual signaling on the
serial ports is different, the packet format remains independent of the method of transporting the data.
The following steps must be performed to successfully send a packet:
1. Send the size of the packet that will be sent to the device. The size is always the number of bytes of
data + 2 bytes.
2. Send the checksum of the data buffer to help ensure proper transmission of the command. The
checksum is simply a sum of the data bytes.
3. Send the actual data bytes.
4. Wait for a single-byte acknowledgment from the device that it either properly received the data or that it
detected an error in the transmission.
The following steps must be performed to successfully receive a packet:
1. Wait for non-zero data to be returned from the device. This is important as the device may send zero
bytes between a sent and received data packet. The first non-zero byte received will be the size of the
packet that is being received.
2. Read the next byte which will be the checksum for the packet.
3. Read the data bytes from the device. There will be packet size - 2 bytes of data sent during the data
phase. For example, if the packet size was 3, then there is only 1 byte of data to be received.
4. Calculate the checksum of the data bytes and ensure that it matches the checksum received in the
packet.
5. Send an acknowledge (ACK) or not-acknowledge (NAK) to the device to indicate the successful or
unsuccessful reception of the packet. An acknowledge packet is sent whenever a packet is
successfully received and verified by the bootloader. A not-acknowledge packet is sent whenever a
sent packet is detected to have an error, usually as a result of a checksum error or just malformed data
in the packet. This allows the sender to re-transmit the previous packet.