The supported boot modes by device hardware are:

• Flash: xSPI0, xSPI1, NOR

• Bootstrap via SCI/UART or USB

• RAM execution initiated by a connected debugger

Available Software

The Flexible Software Package with Smart Configurator supports running from RAM via debugger as well as booting from Flash.

An existing application can be switched between RAM execution mode and flash boot mode by the Smart Configurator. Linker Script and Startup Code are replaced (overwritten) accordingly by the tool chain.

Other boot modes are supported by dedicated sample applications:

• RZ/T2, RZ/N2 Group Firmware Update Sample program
  A bootloader in Flash starts either an application from flash or a flash update software that updates the application via ethernet.

• RZ/T2 and RZ/N2 Group Device Setup Guide for Flash boot Sample program
  Device setup SW is downloaded to RAM via UART or USB bootstrap. This software loads the application via ethernet and writes it to flash.

• RZ/T2M Group Example of separating loader program and application program projects / RZ/N2L Group Example of separating loader program and application program projects
  Two stage approach: A simple bootloader in flash loads the application from flash to RAM and starts it.

Hints

Some hints in case of issues, when adapting the boot mode in linker script or startup code.

Runtime issues:

• Check if code is correctly copied from flash to RAM. Use disassembly view and memory dump to verify.

• Check if .data variables are correctly initialized by the startup code.
  Check if .bss variables are correctly cleared by the startup code.

• When booting from flash, check for sufficient size of the initially loaded block (parameter LDR_SIZE_NML).

• If a raw binary becomes huge (e.g. 1 gigabyte), objects might have been located at wrong locations, and the areas in between are filled up with padding.
  Generate the application as s-record file, check the used memory areas. RAM areas might be used incorrectly as RAM areas.
  Use the map file to get the object names according to the addresses.

• Check if the linker script was not accidentally overwritten by the FSP tool chain, or if the used linker script name was replaced in the linker settings.
  As good practice a copy of the linker script should be made.

Debugging issues:

• For proper debugging the startup code in flash must contain a wait loop. See Appendix chapter in FSP Getting Started for details.