Flash Drivers

LinkServer comes with a set of Flash drivers (binaries/Flash) which are used by LinkServer debug connections and flash operations.

The LinkServer debug server uses a RAM loadable Flash driver mechanism. The Flash driver contains the knowledge required to program the internal Flash of a particular MCU (or potentially, family of MCUs). The same applies to the external Flash device present on the board. This information can be either hardwired into the driver, or it is identified when the driver starts up (typically known as a generic Flash driver).

Per-Region Flash Drivers

The devices JSON files (devices) include preconfigured flash memory regions with the appropriate Per-Region LinkServer Flash driver, covering most of the use cases without any additional setup.

In situations where a non-default Flash driver is required, the recommended approach is to extend the existing JSON file with a new device entry. Another method is to provide a separate JSON file tailored to the specific MCU/board configuration.

Advanced Flash Drivers

Most of the LinkServer supported devices are already preconfigured with an appropriate flash driver for the target flash device. However, for MCUs supporting complex flash strategies or external flash devices, the situation is more complex. This section discusses these situations but note, even in these cases, the flash driver can be automatically selected and so require no user attention.

LPC18xx / LPC43xx Internal Flash Drivers

Several LPC18/43 parts provide dual banks of internal Flash, with bank A starting at address 0x1A000000, and bank B starting at address 0x1B000000.

An appropriate per-bank flash driver is already configured for these parts. After programming the part, the selected flash driver will also configure it to boot from the corresponding bank.

Note: The selected flash driver depends on the memory region used at image build/link time.

LPC SPIFI QSPI Flash Drivers

Some parts have support for external SPIFI Flash, sometimes in addition to internal Flash. Programming these flash memories provides some challenges because the size of memory (if present) is unknown, and the actual memory device is also unknown. These issues are handled using Generic Drivers, which can interrogate the memory device to find its size and programming requirements.

During a programming operation, the Flash driver interrogates the SPIFI Flash device to identify its configuration. If the device is recognized, its size and name are reported in the debug log - as below:

...
Inspected v.2 External Flash Device on SPI using SPIFI lib LPC18_43_SPIFI_GENERIC.cfx
Image 'LPC18/43 Generic SPIFI Mar 7 2017 13:14:25'
Opening flash driver LPC18_43_SPIFI_GENERIC.cfx
flash variant 'MX25L8035E' detected (1MB = 16*64K at 0x14000000)
...

Note: Although the Flash driver reports the size and location of the SPIFI device, the memory configuration is specified in devices JSON files. The users can update these settings to match the actual device in use.

Note: Sources to generate custom flash drivers are supplied in the Examples/Flashdrivers subdirectory within the LinkServer installation directory. Users can add support for new SPIFI devices, if needed, by developing custom flash drivers starting from these examples.

i.MX RT QSPI and Hyper Flash Drivers

i.MX RT MCUs support external flash via a QSPI/Hyperbus interface. A range of LinkServer flash drivers supporting devices fitted to EVK development boards are included in LinkServer.

Note: some drivers are also supplied in source project form so they can be used as a base for development of drivers for other external flash parts. These driver projects can be found at Examples/Flashdrivers/NXP/iMXRT.

Important Note: A specific boot header MUST be programmed into the flash (as part of the Project) to boot and execute in place (XIP) an application. The SDK examples are built to include an appropriate header automatically. However, users can program projects without a boot header. In such a case, the application does not boot and the subsequent flash programming operations can be affected.

If such a problem occurs, the recommended recovery procedure is to change the boards boot strategy (via DIP switches) to prevent booting from QSPI or HyperFlash. Power cycle the board and then perform a Mass Erase of the flash. Next, reprogram with an image that has appropriate header, restore the boot strategy and power cycle again.

Tip: In addition, these drivers are complemented with a range of self-configuring drivers supporting all current i.MX RT EVK boards. See Flash Drivers using SFDP for more information on the drivers and this methodology.

Flash Drivers using SFDP (LPC, i.MX RT, MCX)

As discussed above, programming these flash memories presents several challenges because the size of the memory (if present), and the actual memory device are unknown. The LinkServer Generic flash drivers attempted to solve this problem by recognizing specific devices (via their JEDEC ID) and then setting their sizes and programming parameters accordingly. However, this mechanism only works if the flash driver recognizes the flash device, and in consequence it fails if any device is not recognized.

This issue, combined with the sheer volume of devices available, has forced a different approach to be taken. Fortunately, modern flash devices typically contain a data block describing their properties including device size, low-level structure, and programming details. These data blocks and their use are collectively known as Serial Flash Discovery Protocol or SFDP. JEDEC JESD216 describes the standard for these blocks.

A range of Generic flash drivers built to self-configure via SFDP data are available.

Important Note: For some parts, the JSON files/SDKs reference a device-specific flash driver rather than the SFDP version. However, if required, you can modify your JSON/project to use the SFDP version. The Flash drivers cannot detect whether QSPI or HyperFlash is fitted on a board. Therefore, it is the responsibility of the user to use the correct driver.

Note: The i.MX RT1024 and RT1064 MCUs incorporate a flash device within the MCU package itself. However, the flash driver still uses the SFDP mechanism to detect the device.

QSPI SFDP issues and Limitations

Some (older) QSPI parts do not support the SFDP mechanism and therefore cannot be programmable via this protocol. However, some basic assumptions are made for the QSPI devices fitted on NXP (LPC) manufactured development boards. In such a case, the device and its size are assumed to be 1MB, and standard programming mechanisms are used. This scheme helps to ensure that NXP LPC development boards with QSPI can be used with this driver type. Note: This information is correct at the time of writing and only applies to LPC Drivers. Future development of these drivers can change their capabilities.

Flash programming log

When programming code or data into flash, a portion of the debug log displays the flash programming operations (as below):

Log

1

Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID LPC18_43_SPIFI_SFDP.cfx

Sending VECTRESET to run flash driver

2

Opening flash driver LPC18_43_SPIFI_SFDP.cfx

Sending VECTRESET to run flash driver

3

flash variant 'JEDEC_SFDP_EF4014' detected (1MB = 16*64K at 0x14000000)

Closing flash driver LPC18_43_SPIFI_SFDP.cfx

NXP: LPC43S37

Connected: was_reset=true. was_stopped=false

Awaiting telnet connection to port 3330 ...

GDB nonstop mode enabled

4

Opening flash driver LPC18_43_SPIFI_SFDP.cfx (already resident)

Sending VECTRESET to run flash driver

5

Writing 1046900 bytes to address 0x14000000 in Flash

6

Erased/Wrote page 0-15 with 1046900 bytes in 7548msec

Closing flash driver LPC18_43_SPIFI_SFDP.cfx

Flash Write Done

7

Flash Program Summary: 1046900 bytes in 7.55 seconds (135.45 KB/sec)

Stopped: Breakpoint #1

Note: when accessing unknown flash devices, the driver is called twice. First to identify the device and second to perform the required programming. In a situation where multiple devices are being programmed, the flash driver is (re)loaded for each use.

Where:

Info

1

SFDP JEDEC ID is the method used to access the flash and LPC18_43_SPIFI_SFDP.cfx is the flash driver used.

2

The driver named above is loaded and initialised (this step will setup clocks, pin muxing, and perform some investigation of the connected device).

3

The driver returns a string JEDEC_SFDP indicating that SFDP data was found and successfully read:
- The devices JEDEC ID was read as EF4014, in this case corresponding to a Winbond 25Q80DVSIG (as fitted to the LPC-Link2 board used in Target mode).
- The devices size was read as 1MB divided up into 16 64KB Sectors/Blocks. These blocks are the erase size during programming. Any operation to program this flash must start on an address aligned to this 64KB size.

4

The driver is opened for a second time (without reloading since it remains from the previous call).

5

The project that referenced this driver requested 1046900 bytes of data to be written to 0x14000000, as set within the memory configuration of the project.

6

The write operation is performed via 16 page writes.
Note: This flash driver (like many LinkServer drivers) uses a virtual page size that is larger than the actual flash device page size to optimize driver operation.

7

Finally, a summary of the operation is printed showing the flash programming performance.

Note: If the driver fails to find SFDP data, it attempts to program the device with standard routines. If this scenario occurs, the size is assumed to be 1MB and the flash variant is reported as ID rather than SFDP as shown below:

flash variant 'JEDEC_ID_EF4014' detected (1MB = 16*64K at 0x14000000)

On occasion, some devices that report the same JEDEC ID can still be different. In this particular case, the device is a similar Winbond 25Q80BVSIG. For example, BV rather than DV.

QSPI Programming and Booting

When dealing with external flash, it is important to distinguish between the flash programming operation and the subsequent use of flash (code execution or data access). The responsibility of the flash driver ends with a successful program operation. After this point, correct operation of the MCU/SPI flash combination lies elsewhere.

Therefore, once the MCU is reset or power-cycled, the device configuration and operation lie entirely outside of the tools, as follows:

  • Development board/MCU boot settings

    • These settings can be DIP switches or Jumpers providing inputs to the MCU boot flow, or the OTP bits programmed within the MCU.

  • BootROMs ability to understand and setup the device

    • BootROMs on devices such as the LPC1800 and LPC4300 have built-in understanding of certain QSPI devices allowing them to be configured for boot. However, this boot process may fail with a certain QSPI flash, although it has been correctly programmed.

    • BootROMs on devices such as the LPC540xx and RT10xx rely on correct header (XIP) information being programmed (part of the application) into the QSPI flash itself. If this data is incorrect (or not present), the boot/reset fails.

  • Devices that incorporate both internal boot flash and external SPIFI/QSPI flash, such as the LPC546xx, typically place the responsibilities for QSPI configuration to the user application. This configuration could include:

    • Setup of pinmuxing

    • QSPI/SPIFI clock setup

    • Flash interface initialization

    • QSPI initialization (could be QSPI device specific)

      • including setup of appropriate wait states for QSPI operation at the selected QSPI clock frequency

FlexSPI Flash reset

Several i.MX RT MCUs that support external flash via the FlexSPI interface implement a flash device reset sequence.

During FlexSPI boot the boot process requires the FlexSPI Flash device to be in a certain mode, for example, 1-bit SPI compatible mode. The Flash device is naturally in this mode after a POR reset because the power up sequence resets it with the RT MCU device together. However, after a non-POR reset, the flash device could be configured in a mode (DPI/QPI/Octal) that is not compatible with the 1-bit SPI mode. The boot process requires special processing to restore the Flash device to 1-bit SPI compatible mode before continuing access to the Flash device. In general, this state can be achieved by using a GPIO to assert a reset pin on the Flash device. The bootloader can reset the Flash device to 1-bit SPI compatible mode based on fuses configuration, using the GPIO from the combination of FLEXSPI_RESET_PIN_PORT and FLEXSPI_RESET_PIN_GPIO.

When starting a flash-resident debug session, the flash driver must perform this reset sequence. The flash drivers for i.MX RT500 and RT600 MCUs implement this functionality.

Note: Custom boards can use a different pin than EVK development boards for resetting the flash device. In such cases, the preconnect script must be modified to pass the appropriate GPIO pin details for flash reset to the flash drivers.

Kinetis Flash Drivers

Kinetis MCUs use a range of generic drivers.

Kinetis Flash drivers generally follow a simple naming convention, for example FTFx_nK_xx where:

  • FTFx is the Flash module name of the MCU, where x can take the value E, A or L

  • nK represents the Flash sector size the Flash device supports, where n can take the value 1, 2, 4, 8

    • a sector size is the smallest amount of Flash that can be erased on that device

  • xx represents optional extra characters for special case drivers, for example __Tiny for parts with a small quantity of RAM

    • a further optional _D suffix is used to show the driver is written to target Data Flash rather than the more common Program Flash

For example, the K64F MCU Flash driver is named FTFE_4K because the MCU uses the FTFE flash module and supports 4KB flash sectors.

When a debug session programs data into flash memory, the debug log reports the Flash driver and the parameters read from MCU. Below we can see that the driver identified a K64 part and the size of the internal Flash available. It also reports the programming speed achieved when programming this device. These logs can be useful when problems are encountered.

Note: when the Flash driver starts up, it interrogates the MCU and reports several data items. However, due to the nature of internal registers with the MCU, these items may not exactly match the MCU being debugged.

Inspected v.2 On chip Kinetis Flash memory module FTFE_4K.cfx
Image 'Kinetis SemiGeneric Feb 17 2017 17:24:02'
Opening flash driver FTFE_4K.cfx
Sending VECTRESET to run flash driver
Flash variant 'K 64 FTFE Generic 4K' detected (1MB = 256*4K at 0x0)
Closing flash driver FTFE_4K.cfx
Connected: was_reset=true. was_stopped=true
Awaiting telnet connection to port 3330 ...
GDB nonstop mode enabled
Opening flash driver FTFE_4K.cfx (already resident)
Sending VECTRESET to run flash driver
Flash variant 'K 64 FTFE Generic 4K' detected (1MB = 256*4K at 0x0)
Writing 25856 bytes to address 0x00000000 in Flash
00001000 done 15% (4096 out of 25856)
00002000 done 31% (8192 out of 25856)
00003000 done 47% (12288 out of 25856)
00004000 done 63% (16384 out of 25856)
00005000 done 79% (20480 out of 25856)
00006000 done 95% (24576 out of 25856)
00007000 done 100% (28672 out of 25856)
Erased/Wrote sector 0-6 with 25856 bytes in 301msec
Closing flash driver FTFE_4K.cfx
Flash Write Done
Flash Program Summary: 25856 bytes in 0.30 seconds (83.89 KB/sec)

Flash drivers for various Kinetis MCUs are listed below:

K64F FTFE_4K (1MB)
K22F FTFA_2K (512KB)
KL43 FTFA_1K (256KB)
KL27 FTFA_1K (64KB)
K40 FTFL_2K (256KB)

Command-Line Flash Programmer

One of the main functionalities available within LinkServer are the Flash operations (for example erase, load, verify).

For details, refer to the Readme file, Flash paragraph.

Examples of Flash operations from the command line

  • Flash load: ./LinkServer flash MK64FN1M0xxx12:FRDM-K64F load frdmk64f_led_blinky.axf

  • Flash verify: ./LinkServer flash MK64FN1M0xxx12:FRDM-K64F verify frdmk64f_led_blinky.axf

  • Flash erase: ./LinkServer flash MK64FN1M0xxx12:FRDM-K64F erase

  • Flash blank check: ./LinkServer flash MK64FN1M0xxx12:FRDM-K64F blank -a 0x1000 -s 1024

Note: LinkServer flash operations are using the Flash drivers preconfigured within the built-in devices JSON files. Refer to the Per-Region Flash Drivers and Advanced Flash Drivers paragraphs when a different configuration is needed.

WARNING: When LinkServer Flash drivers detect the start of an execute-in-place image, they locate its vector table. Then, a checksum of the initial few vectors is automatically inserted, as required in many LPC parts. This value might not be the value held in that location by the file from which the Flash was programmed. This means that if the content of the Flash is compared against the file, a difference at that specific location is found.

WARNING: Flash is programmed in sectors. The sizes and distributions of Flash sectors depend on the Flash device used. Data is programmed in separate contiguous blocks. There may be many contiguous blocks of data specified in an ELF (.AXF) file but there is only one in a binary file. When a contiguous data block is programmed into Flash data preceding the block start in its Flash sector is preserved. Data following data in the block in the final sector, however is erased.

Dealing with Errors during Flash operations

On some boards, it is possible to run an image that is incompatible with the Flash driver. This incompatibility is likely to show in the form of programming errors signaled as the operation progresses. Often they are due to unmaskable exceptions (such as watchdog timers) being used by the previous image that interfere with a Flash driver operation.

There are various ways to address this situation:

  • Does your board support In System Processing (ISP) Reset? Using it typically resets the hardware and halts execution in the boot ROM ensuring a stable environment for the Flash drivers. If present, it can generally be enabled using one or more on-board switches. Refer to the board documentation if needed.

  • Erase the contents of Flash or program a small image that ensures no nonmaskable exceptions are involved. Naturally these solutions have the problem that they are likely to fail (and for the same reason) as the programming operation. Sometimes, an incompatible image enables short-term operation of the Flash drivers, allowing one of these solutions to be used.