Segger Flash Lite
Nhyiraba Valentin
All results were taken from the J-Link Commander output. Tests started with the flash either empty or erased, as flash erase times depend very much on the selected device. Sector sizes may grow for large devices. Please refer to the chip manual of the appropriate device to get information about erase times.
J-Link supports the programming of memory-mapped QSPI NOR flash via the standard methods described above.
In the beginning, SPI NOR flash was usually a custom connection and not standardized, with advanced MCUs and QSPI flash memory-mapped made visible in the MCU address space. However, it eventually became a full replacement and even successor of parallel NOR flash. With J-Link, all features known from internal flash are also available in memory-mapped QSPI flash:
Note: Hardware breakpoints are not usable in QSPI flash on many Cortex-M based devices. This makes J-Link + flash breakpoints the only real option to debug in QSPI flash on these devices.
A customized flash algorithm is needed to program these devices. Customers can do this themselves using J-Link Device Support Kit, or SEGGER can help. Please contact sa...@segger.com to request a quotation.
SEGGER engineers have written, validated, and optimized the flash loaders, making sure they work reliably and deliver the best possible performance. SEGGER has hardware in-house for all supported devices and can re-test and give support to users.
SEGGER's Embedded Experts can add support for new or custom devices by drawing on their extensive experience. In many cases, this is done by SEGGER free of charge. However, in urgent cases, or for devices which are not designed for the mass market, or devices that are highly complex, or for other reasons, there may be a charge.
All tests were performed by placing a 512 KB program into the flash memory of a blank STM32F417IG microcontroller connected via SWD interface. The SWD speed was selected at the maximum possible for each debug probe.
The J-Link also has the option of further software enhancements with the production flash programming utility (J-Flash). The ability to take full advantage of the development environment using the Unlimited Flash Breakpoint module also means you free your development from the hardware breakpoint restriction. In this test, J-Link is the clear winner.
We do not recommend or support the following programming methods via J-Link Commander or J-Flash Lite for production purposes. Regarding production programming, only production grade programming tools should be used.
Production grade programming tools typically feature a more sophisticated, multi-step verification process. Many applications also require customization / patching of variable data such as serial number(s), MAC addresses and similar.
J-Flash Lite is a free, simple graphical user interface which allows downloading into flash memory of target systems. J-Flash Lite is part of the J-Link Software and Documentation package, available for download here.
How to perform downloading into flash via J-Flash Lite:
Flasher is a programming tool for all common devices with internal or external flash memory. For a list of all supported devices click here. Flasher ARM is designed for programming flash targets with the J-Flash software or stand-alone.
J-Flash is an application that can program internal and external flash on ARM/Cortex devices. J-Flash can be used as a GUI-based application or in batch mode. It is available for Windows, Linux and macOS.
Architectures / cores not listed here must be assumed as being not supported.
While they may work by chance, no support is provided for problems in regards to getting SEGGER Flash Loaders running on non-listed architectures.
Because a SEGGER Flash Loader programs the flash via the MCU it runs on, basically any flash (or other non-volatile memories) can be supported.
This applies to flash that is memory mapped accessible by the MCU (internal flash, external QSPI NOR flash, ...) as well as to non-memory mapped flashes (external I2C EEPROM, external NAND flash, ...)
Function description
Mandatory function. Must be present to make SFL detected as valid.
Prepares SFL for further usage. Very first function of SFL to be called.
Can rely on not being called multiple times in a row without a SEGGER_FL_Restore() in between.
This function may be used for example to initialize the PLL of the device before flash programming starts, to improve flash programming performance.
The following is a valid series of calls:
Function description
Mandatory function. Must be present to make SFL detected as valid.
Restores SFL after work is done. Very last function of SFL to be called.
This function may be used for example to restore the PLL settings of the device after flash programming is done.
This is for example needed when using the unlimited number of breakpoints in flash feature of J-Link.
Function description
Mandatory function. Must be present to make SFL detected as valid.
Programs flash. The block passed to this function is always a multiple of what is indicated as page size by FlashDevice.PageSize.
This function can rely on only being called with destination addresses and NumBytes that are aligned to FlashDevice.PageSize.
Function description
Mandatory function. Must be present to make SFL detected as valid.
Erases flash. For one-time programmable memories (OTP), this function may check if the passed sector is still erased/not programmed and throw an error in case it already is programmed.
Function description
Optional function. May not be present. Not present for most memory-mapped accessible flash memories.
Verifies a given range by comparing the provided data versus the data in the flash.
Mainly used for non-memory mapped flashes in case flash is not simply read-accissble for the core at a certain address.
Function description
Optional function. May not be present.
Not needed for memory-mapped flashes that can be just read by the MCU core as RAM or other memories. Mainly used for non-memory mapped flashes where a virtual addres has been assigned to make J-Link flash download work.
If this function is present, J-Link will call it to read flash memory instead of reading it directly via the core.
Function description
Optional function, may not be present.
If present, J-Link may call this function to speed up the verification because not all data must be read + transferred back to the host but instead only the CRC (calculated by the SFL) is transferred to the host.
Function description
Optional function, may not be present.
If present and target architecture supports turbo mode, J-Link will use this entry function to start turbo mode which will lead to a big performance gain in flash programming.
If an SFL implements this function, it should simply call SEGGER_OFL_Lib_StartTurbo() from the SEGGER_SFL_Lib.a library. The exact operation of SEGGER_OFL_Lib_StartTurbo() is not disclosed.
Function description
Optional function. May not be present.
Only needed for flash loaders where the exact sectorization is determined at runtime.
This is for example the case for some loaders for external QSPI NOR flash, where different users may have different QSPI flashes connected to their hardware.
This allows to have only 1 loader to serve many different setups.
The FlashDevice structure variable contains all the static information about the flash algorithm like sectorization of the flash, programming chunk size, ...
In the following, the structure elements are explained in detail to give a good idea about what needs to be filled in for a new flash loader.
This element is actually a list of different sector sizes present on target flash.
Having a flash with uniform sectors will result in only SectorInfo[0] being used for sectorization information.
In case the initial number of [4] regions is not sufficient, the array may be expanded up to [8] by the user when writing the flash algorithm.
For more information, see the example below.
J-Link reserves 512 bytes stack for the SEGGER Flash Loader. This value is fixed and cannot be changed. If 512 bytes cannot be allocated (e.g. for devices with small RAM areas), 256 bytes are used as fallback.
The J-Link software expects a special layout when it comes to RO code, RO data, RW data placement in the SFL binary.
The reference algorithms and templates provided with the J-Link DSK already take care of that layout, so there is nothing special to be considered by the user.
External flash pin init
The SEGGER_FL_Prepare() code has to make sure that the (QSPI) pins as well as the (QSPI) controller are configured so that the flash is memory-mapped read-accessible.
This is necessary as the J-Link software by default compares flash contents before starting the flash programming, to save time in case large portions of the flash are already identical to the programming data.
This can be validated by setting the compare method in J-Link Commander to "skip" (exec SetCompareMode 0). Now start flash download.
J-Link Commander should report a verify error but the flash should be memmory mapped accessible from now. If not, check the Init() code.
I get build errors in release build config
If you get build errors when switching from "Debug" to "Release" build in the template project the main cause is that third party libraries are used.
The SEGGER Flash Loader interface expects all program parts to be linked to sections PrgCode and PrgData.
Third party libraries often use statically linked program parts which will not be put in the aforementioned sections which will cause a build or linker error.
Generally we recommend not using any third party libraries when creating Flash loaders as they will increase the Flash loader size drastically while usually slowing down the maximum possible Flash loader speed.
If you happen to have to use an external library in your project it is user responsibility to make sure this external library is linked to the aforementioned sections for all application parts.