search

Sinapse-Energia / bootloader-stm32

Contains the code of the bootloader for Sinapse Devices based on stm32 chips
7 stars 5 forks source link

readme

bootloader-stm32

The repository contains the code of the bootloader for Sinapse Devices based on stm32 chips

Introduction

This project covers the development and testing of the generic bootloader for Sinapse Devices based on several chips of the STM32 family. The Readme of the project works as a technical requirements document and like a contract in case of subcontracting parts of the project.

Glossary

Development environment and needed tools

Global view

The generic bootloader for Sinapse Devices it is a little program that will be executed at the start / restart of any Sinapse device and will check if there is a new version of the Main program in a FTP server. If there is a new version, the bootloader should download the new main program, check its validity, check if there is enough space in the flash memory to install the program and then remove the current main program and install the new one and perform the execution handover to the new main program. If there is not a new version, the bootloader should realise the execution handover to the main program.

For more information about a global view of how a generic bootloader should works, it is possible to consult the following url: http://blog.atollic.com/how-to-develop-and-debug-bootloader-application-systems-on-arm-cortex-m-devices

Hardware description

FTP Client

A basic FTP client over GPRS and WIFI/ETH should be developed.

Flow diagram and use case diagram

The workflow of the bootloader should be the following one:

flowchart

Technical description

Here are explained the technical requirements that should be covered by the Sinapse Generic Bootloader. The technical requirements aims to be almost unitary and testable. Each technical requirement should be tested as OK in order to give it as a valid

The requirements are divided by flow diagram elements

Process - Start

  1. The Bootloader should be executed after each start / restart of the Sinapse Device before the main program
  2. The Bootloader should take maximum 60 seconds if there is or not a new FW to be downloaded in all posible interfaces.
  3. The Bootloader should take maximum 10 minutes for download some new update for application program.
  4. The Bootloader should start in the memory address 0x08000000 and should occupy maximum 10KB of flash memory. Anyway all reserved memory for Bootloader code goes from 0x08000000 to 0x08002800
  5. The Bootloader will be installed during the fabrication process and will not be updated during the device longlife. This fact could change in future versions but is out of the scope.

Decision - ETH / WIFI enabled

  1. Determine if exists one ETH/WIFI device connected over Sinapse device or if it is enabled.
  2. If device exists, jump to "Process - Check FTP folder connection through ETH / WIFI".
  3. If device does not exist, jump to "Decision - GPRS enabled".

Process - Check FTP folder connection through ETH / WIFI

  1. To peform all needed operations to connect with one prefixed FTP server, available in the CF.
  2. Return ETHWIFI_FTP_FOLDER_FOUND if ETH/WIFI has been able to connect with the prefixed FTP server and it has found the folder (this folder is prefixed over Sinapse device) return ERROR_ETHWIFI_NOT_FOUND , ERROR_ETHWIFI_DISABLED , ERROR_ETHWIFI_FTP_NOT_CONNECT, ERROR_ETHWIFI_FOLDER_NOT_FOUND in other cases.

Note: Each device should check 2 FTP folders.

  1. Global FW folder: All devices check the same folder. Will be used on production process to upload a general FW to all devices
  2. Device Folder: Each device has an unique Folder for device Update. FW mnay times contains device info, so the update have to be customizaed for device.

So Bootloader program have to contain Device ID. Folders routes have to be generical and easily modificable. Will be setup as described below:

ftp root/DEVICE_CODE_FW/

ftp root/DEVICE_CODE_FW/DEVICE_ID/

Decision - FTP folder connection through ETH or WIFI

  1. If answer in previous process was ETHWIFI_FTP_FOLDER_FOUND, we jump to "Process - Check availability of new FW".
  2. If answer was different we jump to "Decision - GPRS Enabled"

Decision - GPRS enabled

  1. Determine if exists one GPRS device connected on Sinapse device or if it is enabled.
  2. If device exists, jump to "Process - Check FTP folder connection through GPRS"
  3. If device does not exist, jump to "Process - Execution handover to main program"

Process - Check FTP folder connection through GPRS

  1. To peform all needed operations to connect with one prefixed FTP server, available in the CF.
  2. Return GPRS_FTP_FOLDER_FOUND if GPRS has been able to connect with the prefixed FTP server and it has found the folder (this folder is prefixed over Sinapse device) return ERROR_GPRS_NOT_FOUND , ERROR_GPRS_DISABLED , ERROR_GPRS_FTP_NOT_CONNECT, ERROR_GPRS_FOLDER_NOT_FOUND in other cases.

Decision - FTP folder connection through GPRS

  1. If answer in previous process was GPRS_FTP_FOLDER_FOUND, we jump to "Process - Check availability of new FW".
  2. If answer was different, jump to "Process - Execution handover to main program"

Process - Check availability of new FW

  1. Inside the folder there will be one .BIN file. The name describes the version of the FW, so it has to be: FW_NAME_VXpY_ddmmyy, where:

FWNAME: No limitations, end with

VxpY: FW version i.e. V1p4 = V1.4

ddmmyy: Release Date

  1. Check if VxpY and ddmmyy are higher that actual stored version and date

*Note The actual stored version and date are saved in the first positions of the first page of the flash memory. The bootloader from fabric has these values set to: "last_update = date_installation" and "version = Vp, for example 14 -> V1p4"

  1. If yes, jump to "Process - Download new FW", returning NEW_AVAILABLE_FIRMWARE
  2. If answer was different we jump to "Process - Execution handover to main program", returning NO_NEW_FIRMWARE

Decision - New FW available

  1. If answer in previous process was NEW_AVAILABLE_FIRMWARE, jump to Download new FW

  2. Check if VxpY and ddmmyy are higher that actual stored version and date

  3. If yes, jump to "Process - Download new FW".

  4. If answer was different we jump to "Process - Execution handover to main program"

Process - Download new FW

  1. If file is downloaded, it must to be saved beginning in position 0x08002800+MAX_SIZE_APPLICATION_PROGRAM. ( We have then three sections of different programs in Flash):

1) From 0x08000000 - 0x80027FF BOOTLOADER 2) From 0x08002800 - (0x8002800+MAX_SIZE_APPLICATION_PROGRAM-1) APPLICATION PROGRAM 3) From (0x8002800+MAX_SIZE_APPLICATION_PROGRAM) - (0x8002800+2 *(MAX_SIZE_APPLICATION_PROGRAM)-1) UPGRADE PROGRAM

IMPORTANT NOTE It is supposed that three sections are completely independent into FLASH. It means that one erase operation in one section DO NOT erase another sector. It must been verified in three microcontrollers: STM32F030CC, STM32F405VG STM32F030K6T6 processor. If not possible three sections must be separate minimal enough space to became in different sectors.

Decision - Download correct

  1. The .HEX files will have in last 4 bytes of file one CRC32 of all previous data
  2. The process of download of UPGRADE PROGRAM in section 3 is correct if the calculate CRC32 from position:
    • 0x8002800+MAX_SIZE_APPLICATION_PROGRAM to (0x8002800+2 * (MAX_SIZE_APPLICATION_PROGRAM)-5) matchs with last 4 bytes of UPGRADE PROGRAM
  3. Return DOWNLOAD_CORRECT if calculated CRC32 matchs with CRC32 of 4-last-bytes saved in UPGRADE PROGRAM and jump to "Process - Stop previous FW and install the new one".
  4. If download is incorrect, it will return DOWNLOAD_INCORRECT and jump to "Process - Execution handover to main program".

Process - Stop previous FW and install the new one

  1. If download was correct, then we ERASE all flash memory from section 2) APPLICATION PROGRAM and save all data from section 3) UPGRADE PROGRAM to section 2) APPLICATION PROGRAM. 2) Section 3 is erased completely. 3) It is needed to update the flash memory with the last_update and version variables. These information is used to decide if a new version should be installed. 3) Return PROCESS_OK 3) Jump to "Process - Execution Handover to main program".

Process - Execution Handover to main program

  1. A new CRC32 calculation must be done over section 2) APPLICATION PROGRAM and the CRC must matchs with 4-last-bytes saved in APPLICATION PROGRAM.
  2. If CRC32 matchs with 4-last-bytes then we load APPLICATION IRQ VECTORS on MAIN VECTORS and load program counter of microcontroller with first entry for APPLICATION PROGRAM. (We launch application program)
  3. If CRC32 DOES NOT match with 4-last-bytes, then the APPLICATION PROGRAM is corrupt, we must continue in BOOTLOADER mode, jump to " Decision - ETH / WIFI enabled"
  4. If any new firmware was downloaded, the bootloader should perform the handover to the main program without the CRC32 calculations

Process - END

  1. The bootloader finish when the "Process - Execution Handover to main program" is correctly done
  2. If the bootloader was not correctly done, then try again until a main program is correctly installed

Some interesting points to define:

1) Is good idea to inform FTP server in some file status of all process? - > RAE : I think YES, TODO 2) Is good idea to do retries?. In this flowchart there is not specification of some retrie if something goes wrong. -> ALREADY Explained

Testing

Unit tests - Designed and developed by the Developers

Each function should contains a unit test verifying the correct behavior of each use case

Integration tests - Designed and developed by Sinapse

Several integration tests should be performed in order to verify the correct behaviour of the Bootloader in the most common situations. These tests should be executed in ALL the available Sinapse Devices

Sinapse Device Empty - ETH/WIFI Connection - LED Main Program OK & LED Main Program KO

Test 1 : Ideal situation

Test 2 : The connection is before the program is downloaded

Test 3 : The device is restarted before the application is installed

Test 4 : The device is restarted after the application is installed but the handover is not done (if possible)

Sinapse Device Empty - GPRS Connection - LED Main Program OK & LED Main Program KO

Test 5 : Ideal situation

Test 6 : The connection is before the program is downloaded

Test 7 : The device is restarted before the application is installed

Test 8 : The device is restarted after the application is installed but the handover is not done (if possible)

Sinapse Device with Main Program - ETH/WIFI Connection - New Main Program OK & New Main Program KO

TODO

Sinapse Device with Main Program - ETH/WIFI Connection - New Main Program OK & New Main Program KO

TODO

Validation and closing

To validate and close the project it is necessary to provide the following documentation and results, as well as the code:

  1. Documentation of structure and behaviour of the code, including interaction diagrams
  2. Unit tests and its results
  3. Results of the integration tests, all of then should be passed