A computer monitor and speakers on top of a desk.

BootLOADING FLASH based MCU

The term BootLOADING for a FLASH based MCU is subjective why, the application resides and executes in on-board FLASH, therefore does not require loading into RAM or other memory to run.  Our definition for BootLOADING FLASH based MCUs is strictly related to a platform application firmware update.  The “BootLOADING” application is normally independent of the platform application, however in the case when an MCU has limited resources an “in-application Bootloader” is required (the loading application is stored in the same FLASH as the application).

FLASH based MCU

Our definition of a FLASH based MCU is a VLSI device that contains; CPU(s), GPIO, embedded peripherals, FLASH ROM, RAM and on-chip debug support. Access to internal memory is optimized and no externals memories are required, this applies to MCUs with the ability to configure GPIO pins as an external bus unit.

A close up of the electronic circuit board
A person holding a computer chip on top of a circuit board.

Generic BootLOADING

The first questions related to BootLOADING is, “can you provide a generic BootLOADER?”  We do not offer an off the shelf generic bootLOADER due to the required physical connection (between CLIENT and SERVER), MCU resources, available communication peripherals and desired communication protocol.  We do provide a basic bootLOADER targeting a specific MCU, communication interface and protocol, however these must be defined.  Once defined, we can deliver a “minimal” system.

Basic LOADER

This type of bootLOADER demo is a great start for a team and has proven successful with past delivers.  We provide a state based bare metal bootLOADER application, C source code, best fit MCU vendor EVAL BOARD, Windows CLIENT, communication IF hardware (when necessary), “Hello World/Blinky programming file” and complete documentation.  Dependent on system requirements and hardware availability, delivery time is within eight (8) weeks.

Delivery:

  • The function of this bootLOADER is limited to; ERASE FLASH/ WRITE FLASH / VERIFY FLASH Content
  • API to enter bootLOADER from application C source code.
  • FLASH sector configurable for bootLOADER and application address spaces
  • Physical communication interface limited to one of; TTL UART, Ethernet or CAN/CANFD
  • Internal shell application, supports debug output and diagnostics (CLI), TTL UART
  • Windows CLIENT utilities to convert application hex/sre to transportable protocol format
  • Hardware (MCU EVAL board)  

Tools:

  • TASKING VX-Tool set for Tricore (AURIX™ GEN1 and GEN2)
  • TASKING VX-Tool set for ARM® Cortex™ M
  • TASKING VX-Tool set for Tricore (AURIX™ GEN1 and GEN2)
  • Debug perspective w/ Segger J-LINK
  • iSYSTEM winIDEA/IC5700 hardware debugger
  • ARM GNU Toolchain /w Eclipse IDE (Free toolchain)
  • Segger J-LINK hardware debugger
  • iSYSTEM winIDEA/IC5700 hardware debugger
A diagram of the system and its instructions.
A woman sitting at her desk with two monitors.

Evaluation System

WTD can provide our LOADER application for evaluation. We do charge for hardware, the evaluation is shipped with our loader application ready for use. CLIENT <> SREVER connection limited to 100 BASE-TX physical interface. Delivery is dependent on hardware availability. Listed below are evaluation systems we have ported our evaluation application into. We are happy to port our LOADER application into other evaluation boards or custom platforms upon request.

Hardware Platforms:

  • Neutron Controls REDline
  • AURIX™ TC277/TC297/TC299
  • AURIX™ TC377/TC397
  • Infineon
  • AURIX™ TC277/TC297/TC299 TriBoards
  • AURIX™ TC277/TC297 Application Kits
  • AURIX™ TC375/TC397/TC399 TriBoards
  • NXP
  • MIMXRT1170-EVK
  • FRDM-K64F

Includes:

  • LOADER binary
  • Bare Metal state machine.
  • Demo application .SRE
  • FreeRTOS and LwIP
  • Application LINKER script for TASKING (PFLASH sections for application)
  • CLIENT GUI for 64-BIT Windows
  • FTDI TTL-232R-3V3 adapter (for CLI debug shell)
  • User Manual

For more information and DEMO, select the link below.

Platform Specific LOADER

A FLASH based MCU LOADER provides a means for a CLIENT (LOADER is the SERVER side) to update the platform application (at a minimum).  Additionally, the LOADER application can provide diagnostic services or be a function of a diagnostic service.  LOADER applications architecture varies from being a light weight bare metal design to tasks running under a RTOS. Regardless, LOADER applications are independent of the platform application, each limited to their predefine FLASH memory address ranges where the LOADER application is protected from platform applications interference. It is important to note that when the LOADER application is executing, it is responsible to ensure the platform hardware is in a “limp mode” operation (platform functions held in a safe IDLE state).

A diagram of the layers of an ocean floor.
A person working on a computer board

WTD Base Loader

Our approach to a LOADER application is to keep it light weigh, supporting only the service required when required. WTD base LOADER application is architected as a bare metal state machine supporting the key states to VERIFY application integrity, AUTHENTICATE CLIENT, ERASE and WRITE to FLASH.

We Simplify Our Process Below

Upon reset our LOADERS is first to execute, set the system clock then verifies the platform application's integrity if it passes will immediately jump to the application. The platform application can cleanly take control of the machine resources as if the reset vector pointed to its start address. If the verify state fails, the bootloader will then load all required resources and ensure the platform hardware is in an idle state and inform the CLIENT of the failure.

Once the CLIENT passes authentication, the CLIENT can erase application FLASH, load the new application. When completed, verifies the application integrity loads the jump directly to app post reset. The CLIENT will issue a machine reset, the process starts over again.

Two people working on electronics in a lab.
A diagram of the state of a house

Protocol

Our base loader PROTOCOL uses a proprietary Key, Length, Value frame structure, designed around the eight (8) data byte maximum limitation of Classic CAN with 11-bit identifier. The LOADERs message router manages these incoming frames, passed up by the physical interface driver. The only limitation is the LOADER application architecture has beed designed to support only physical interface per distribution instance (we provide CAN / CANFD, TTL UART and ETHERNET drives with the delivery).

For the automotive market, we provide loading applications compliant to UDS (ISO 14229-1) session layer services for; ISO 15765-2 DoCAN, ISO 13400-2 DoIP and ISO 17987-2 LIN.

We deliver LOADER applications based on customer requirements.

Hardware Design Services

WTD offers hardware design support and solutions. The head of hardware engineering is an industry leader in; SBC, SoC platforms and Ethernet communications.

  • Industrial and automotive networking solutions
  • Microchip
  • Marvell
  • FPGA IP based
  • "Flashless" MPU for Linux
  • NXP
  • QOrIQ, PowerPC, ARM Cortex Layerscape
  • TI
  • AM335x Sitara
  • Soft core CPU
  • NIOS
  • MicroBlaze
  • Wireless networking
  • Wi-Fi
  • Zigbee
  • Wi-SUN
  • Proprietary secure, 303MHz/433MHz
A computer screen with some programming code on it

Get in Touch

Our main business is LOADERS for FLASH based MCU and BootLOADERS for “flash-less” MPU systems. For more information, please contact us.

"*" indicates required fields

Name*
This field is for validation purposes and should be left unchanged.