Application Startup Flow

SF32LB58x uses a tri‑core architecture (high‑performance big core + low‑power small core + coprocessor core) with multiple internal and external memory interfaces. MPI1, MPI2, MPI3 and MPI4 are in HPSYS and can send requests to DMAC1; MPI5 is in LPSYS and can send requests to DMAC3. MPI1 I/O connects to IO(SA) to access the on‑chip SiP 8‑line/16‑line pSRAM or 4‑line NOR Flash. MPI2 I/O connects to IO(SB) to access another on‑chip SiP 8‑line/16‑line pSRAM. MPI3 and MPI4 I/O connect to IO(PA) to access external NOR/NAND Flash. MPI5 I/O connects to IO(SC) to access the on‑chip SiP 4‑line NOR Flash.

The application startup on the big core consists of three stages:

  1. First‑stage Bootloader: Burned in the SF32LB58X internal ROM; loads the second‑stage bootloader from Flash to RAM and jumps to run it

  2. Second‑stage Bootloader: Loads the application from Flash and jumps to execute it

  3. Application: User program

First‑stage Bootloader

The first‑stage bootloader is burned in the chip ROM with the interrupt vector table address at 0. After power‑on, the first‑stage bootloader runs first. The Flash partition table is placed on Flash5 connected via MPI5 (“Flash5” usually refers to the external Flash storage device connected through MPI5). According to the second‑stage bootloader address indicated by the partition table (must be on the boot Flash), it copies the second‑stage bootloader code to RAM and jumps to run it.

During the first‑stage bootloader, the big core runs at the default clock frequency after power‑up and initializes the boot Flash IO configuration.

Second‑stage Bootloader

The second‑stage bootloader loads the application and jumps to execute it according to the package type and the Flash partition table. Depending on the package type, applications support the following boot modes. Execution modes include XIP (execute directly at a NOR Flash address; code storage address equals execution address) and non‑XIP (copy code from Flash into RAM for execution; the storage address differs from the execution address):

  1. On‑chip NOR Flash (MPI5): Boot Flash is on‑chip NOR, used to store the Flash partition table and the second‑stage bootloader.

  2. External NOR Flash (MPI3/4): External NOR is connected via MPI3/4; the application is stored on external NOR and runs in XIP mode.

  3. On‑chip PSRAM (MPI1/2), external NAND Flash (MPI3/4): The application is stored on external NAND and runs in non‑XIP mode, i.e., code is copied to on‑chip PSRAM for execution.

  4. On‑chip PSRAM (MPI1/2), external SD Flash (SDIO): Same as item 2.

Application

ResetHandler

The application entry function is ResetHandler (in drivers\cmsis\sf32lb58x\Templates\arm\startup_bf0_hcpu.S). Its flow is shown below. The user main function is called by the main thread created in rt_application_init. See main_thread_entry flow.

reset_handler_flow

SystemInit

SystemInit (in drivers/cmsis/sf32lb58x/Templates/system_bf0_ap.c) runs before variable initialization (therefore do not use variables with initial values during this period, and avoid relying on the zero‑initialized section being 0). It updates the VTOR register to redirect the interrupt vector table, and calls mpu_config and cache_enable to initialize the MPU and enable Cache. These two functions are weak symbols, so applications can override them.

system_init_flow

rt_hw_board_init

rt_hw_board_init performs low‑level hardware initialization such as clock and IO configuration, PSRAM and NOR Flash initialization, heap and serial console initialization. rt_components_board_init is an application‑defined initialization hook and calls different functions depending on the application configuration.

rt_hw_board_init

HAL_Init

HAL_Init completes HAL initialization: it loads PMU calibration parameters, updates clock and IO settings, and initializes PSRAM and NOR Flash (according to the new clock configuration). In the diagram, green functions are board‑level driver functions with board‑specific implementations (HAL_PreInit, BSP_IO_Init, BSP_PIN_Init, BSP_Power_Up, etc.). Gray functions are virtual hooks implemented by the application (or not), independent of the board, so different applications on the same board can customize behavior (e.g., different IO configurations). Horizontally, the flow shows nested calls inside functions (e.g., HAL_PreInit calls clock‑configuration helpers; HAL_MspInit calls BSP_IO_Init). Vertically, it shows serially executed functions (e.g., after HAL_PreInit finishes, HAL_PostMspInit runs).

hal_init_flow

Config Clock adjusts:

  • Start GTimer

  • If external XT32K is not used, switch RTC to RC10K

  • If external XT32K is used, switch RTC to XT32K

  • Set system clock to 240 MHz (DLL1)

  • Set DLL2 to 288 MHz

rt_application_init

rt_application_init creates the main thread with entry main_thread_entry. After thread scheduling is enabled (i.e., after rt_system_scheduler_start), the main thread is scheduled and enters main_thread_entry, first calling rt_components_init to initialize components, then calling main (implemented by the application). User code starts from main. For example, the rt_driver sample’s main function is in example/rt_driver/src/main.c.

main_thread_entry_flow

Board‑level Driver Interfaces

Each board needs to implement the following board‑level driver functions. Refer to files under customer/boards/ec-lb58x.

Function

Required

Description

HAL_PreInit

YES

Recommend referencing a board with similar hardware form

BSP_Power_Up

NO

Called after cold boot and wake‑up

BSP_IO_Power_Down

NO

Called before sleep

BSP_LCD_Reset

NO

BSP_LCD_PowerUp

NO

Called when powering the display on

BSP_LCD_PowerDown

NO

Called when powering the display off

BSP_TP_Reset

NO

BSP_TP_PowerUp

NO

Called when powering touch on

BSP_TP_PowerDown

NO

Called when powering touch off

HAL_MspInit

NO

Called by HAL_PreInit; virtual default calls BSP_IO_Init

HAL_PostMspInit

NO

BSP_IO_Init

NO

Called by HAL_MspInit by default

BSP_PIN_Init

NO

Called by BSP_IO_Init; IO configuration function

Application‑defined Driver Interfaces

If different applications on the same board need different HAL_MspInit behavior, you can implement HAL_MspInit under the application directory; otherwise, it can reside under the board directory.

Function

Required

Description

HAL_MspInit

NO

HAL_PostMspInit

NO