System Hardware Platform
The hardware of this firmware upgrader should own many common communication interface, meanwhile, it must own fast storage interface such as SDIO, USB HOST. In this case, the storage media will be SDHC / TF card since it is very common, and can be embedded on-board. A good product should put user experience as the most important factor, even though it may be tough for hardware and firmware design.
Based on considerations above, the core MCU / Micro-controller is chosen from ST-Cortex M4 Series, take STM32F407IGH for example, it has abundant peripheral devices, except for the common communication interface above, it owns USB-OTG (Host / Slave), FSMC (Flexible Static Memory Interface), DMA (Direct Memory Access – makes data transmission more efficient), not to mention that it also owns hardware encrypt / decrypt units which are definitely essential for firmware release. See Figure 2.1 for more information.
Note that, Ethernet is not a common firmware upgrade interface, furthermore, the Ethernet physical chip is large and expensive. From the "Cost-Effective" purpose, it is excluded from the block diagram, but it can be added at any time since STM32F4 itself owns hardware Ethernet even though it needs external PHY.
STM32F4xx Virtual USB Disk Development
With STM32 official USB library (v2.1.0) (MSC Device Class) and SDIO Hardware Interface, virtual U disk can be easily implemented. The purpose of this design is to simplify user operations, even though user can pull the SD card out of upgrader and store firmware data directly into it. Furthermore, from the purpose of product development, it is better to hide design details. What's more, in the future, we can use eMMC chip (8-bit SDIO mode) or FLASH (with FSMC) with smaller size to make it more compact.
Meanwhile, with this design, a corresponding client software can be developed to fetch the latest firmware from GIT management system. To do this, we need to change the USB-MSC name so that it can be easily identified by the client software. Specifically, the USB storage inquiry data region should be modified.
SD Card Speed Test and R/W Operation with FatFs
Currently, I used USB-FS mode which can achieve 12Mbps ( 1.5MB/s ) R/W performance. It is acceptable to store small-size firmware data. USB-HS mode can be implemented with USB3300 phy to achieve much higher performance.
Note that there exists 2 factors that may impact the firmware upgrading speed:
- How fast it can retrieve data from PC ( when connected to PC, USB FS speed and SD card RW speed can be the limitation );
- How fast it can upgrade the target device through any communication interface ( interface dependable, such as UART, I2C, CAN etc. ).
After test, it turns out that compared to USB-FS speed, SD card R/W speed is much faster ( SDIO - 4bit mode ) with FatFs. And the upgrading speed is completely dependent on interface speed.
The speed test of SD card is shown below:
If the SD card is empty, the write speed can be very high, not to mention the read speed. I added data validation process, so it is a bit slower, but it can be still up to 3MB/s.
SMART LINK Protocol Development
The communication protocol should be able to perform basic master and slave messages (functionalities) described below:
- lRequest / Response firmware upgrade
This message is used to check device connection or device status, when slave receive this message, it should response to master based on specific command.
- lRequest / Response firmware transmission
This message tells slave device that the firmware data is about to transmit, when slave receives this message, it should respond with the maximum firmware segment size (internal RAM size) it supports.
- lRequest / Response firmware raw data transmission
Master send this message to inform slave device to prepare to receive firmware data. After slave successfully receives the data and program the firmware data into flash, it should response to the master to report the programming results....