STM32H7B0: Is there anything wrong with my mboot configuration?

[nspsck]

Hi, I am trying to create a port for the STM32H7B0 series MCU, they have a 128KB internal storage and mine is equipped with 8MB SPI Flash. I want to use the mboot and load the firmware to the SPI Flash. Currently, I am failing on mboot.

To build the bootload, I did the following:

cd mboot
make BOARD=STM32H7B0

The firmware succussfully built but after the flashing, I could see no led lighting up, even holding the key for a long time. The only thing I got was a stm32-bootloader showing up in the windows device tree. I have also tried with the H750 with the same board layout (keys, leds would be the same), and it worked like a charm.
Due to my knowledge limitations.. I am stuck here, can anyone help? Than you very much!

I have modified the mpconfigboard.h, .mk and the .ld file. As well as some register names according to the official ST library.

/******************************************************************************/
// Bootloader configuration

//#define MBOOT_USB_AUTODETECT_PORT   (1)
#define MBOOT_FSLOAD                (1)
#define MBOOT_VFS_FAT               (1)

#define MBOOT_I2C_PERIPH_ID         2
#define MBOOT_I2C_SCL               (pin_B10)
#define MBOOT_I2C_SDA               (pin_B11)
#define MBOOT_I2C_ALTFUNC           (4)

#define MBOOT_SPIFLASH_ADDR        (0x90000000)
#define MBOOT_SPIFLASH_BYTE_SIZE   (64 * 128 * 1024)
#define MBOOT_SPIFLASH_LAYOUT      "/0x90000000/64*128Kg"
#define MBOOT_SPIFLASH_ERASE_BLOCKS_PER_PAGE (128 / 4)
#define MBOOT_SPIFLASH_SPIFLASH    (&spi_bdev.spiflash)
#define MBOOT_SPIFLASH_CONFIG      (&spiflash_config)

#define MBOOT_BOOTPIN_PIN           (pin_C13)
#define MBOOT_BOOTPIN_PULL          (MP_HAL_PIN_PULL_DOWN)
#define MBOOT_BOOTPIN_ACTIVE        (1)

/*************************************REGISTER MOD********************************/
/*

*/
#define RCC_D1CFGR_D1CPRE_Pos       RCC_CDCFGR1_CDCPRE_Pos
#define D1CFGR                      CDCFGR1
#define D2CFGR                      CDCFGR2
#define D3CFGR                      SRDCFGR
#define D1CCIPR                     CDCCIPR
#define D2CCIP1R                    CDCCIP1R
#define D2CCIP2R                    CDCCIP2R
#define D3CCIPR                     SRDCCIPR
#define RCC_D2CCIP2R_USBSEL         RCC_CDCCIP2R_USBSEL
#define RCC_D2CCIP2R_USBSEL_1       RCC_CDCCIP2R_USBSEL_1

#define FLASH_LAYOUT_STR "@Internal Flash  /0x08000000/16*8Kg" MBOOT_SPIFLASH_LAYOUT MBOOT_SPIFLASH2_LAYOUT

The .mk file:

# MCU settings
MCU_SERIES = h7
CMSIS_MCU = STM32H7B3xxQ
MICROPY_FLOAT_IMPL = double
AF_FILE = boards/STM32H7B0/stm32h7b3_af.csv
LD_FILES = boards/STM32H7B0/stm32h7b3.ld

TEXT0_ADDR = 0x90000000
TEXT0_SECTIONS = .isr_vector .text .data

# MicroPython settings
MICROPY_PY_LWIP = 1
MICROPY_PY_SSL = 1
MICROPY_SSL_MBEDTLS = 1

The .ld file:

/*
    GNU linker script for STM32H7B0
*/

/* Specify the memory areas */
MEMORY
{
    FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 128K
    FLASH_EXT (rx)  : ORIGIN = 0x90000000, LENGTH = 8192K   /* external QSPI */
    DTCM (xrw)      : ORIGIN = 0x20000000, LENGTH = 128K    /* Used for storage cache */
    RAM (xrw)       : ORIGIN = 0x24000000, LENGTH = 768K    /* AXI SRAM */    
    RAM_D2 (xrw)    : ORIGIN = 0x30000000, LENGTH = 128K
}

/* produce a link error if there is not this amount of RAM for these sections */
_minimum_stack_size = 2K;
_minimum_heap_size = 16K;

/* Define the stack.  The stack is full descending so begins just above last byte
   of RAM.  Note that EABI requires the stack to be 8-byte aligned for a call. */
_estack = ORIGIN(RAM) + LENGTH(RAM) - _estack_reserve;
_sstack = _estack - 16K; /* tunable */

/* RAM extents for the garbage collector */
_ram_start = ORIGIN(RAM);
_ram_end = ORIGIN(RAM) + LENGTH(RAM);
_heap_start = _ebss; /* heap starts just after statically allocated memory */
_heap_end = _sstack;

ENTRY(Reset_Handler)

/* define output sections */
SECTIONS
{
    /* The startup code goes first into FLASH */
    .isr_vector :
    {
        . = ALIGN(4);
        KEEP(*(.isr_vector)) /* Startup code */
        . = ALIGN(4);
    } >FLASH_EXT

    /* The program code and other data goes into FLASH */
    .text :
    {
        . = ALIGN(4);
        *(.text*)          /* .text* sections (code) */
        *(.rodata*)        /* .rodata* sections (constants, strings, etc.) */
    /*  *(.glue_7)   */    /* glue arm to thumb code */
    /*  *(.glue_7t)  */    /* glue thumb to arm code */
        . = ALIGN(4);
        _etext = .;        /* define a global symbol at end of code */
    } >FLASH_EXT

    /* For C++ exception handling */
/*
    .ARM :
    {
        __exidx_start = .;
        *(.ARM.exidx*)
        __exidx_end = .;
    } >FLASH
*/

    /* Used by the start-up code to initialise data */
    _sidata = LOADADDR(.data);

    /* Initialised data section, start-up code will copy it from flash to RAM */
    .data :
    {
        . = ALIGN(4);
        _sdata = .;
        *(.data*)
        . = ALIGN(4);
        _edata = .;
    } >RAM AT> FLASH_EXT

    INCLUDE common_bss_heap_stack.ld
}

[andrewleech]

Is this regular spiflash, not qspi flash? qspi suppors xip (execute in place) by setting the qspi peripheral to work in memory mapped mode. The micropython qspi sets this mode automatically so I suspect it should work for application booting from mboot.

I believe the regular spi peripheral does not have this function though. I think the only way to make use of spi flash is as an external filesystem, not for frozen / compiled firmware.

When you say you saw

stm32-bootloader showing up in the windows device tree

Did you try dfu programming to it? What happened?

[nspsck]

Hi! Thank you for responding! And I am sorry for haven't stated it clearly. It is an W25Q64JVSSIQ soldered on the OCTOSPI1 line of the H7B0VB using the quad line protocol.

I am not totally sure if mpy supports booting app from this configuration, and I am not so sure if the octo-spi is related to the current problem I am facing. But thanks for opening that perspective! I'll dig on that later!

Currently, I can't even get to load the actual mpy firmware on the board because I can't enter DFU mode with mboot. It just registered as a DFU device but it's not recognized by any dfu-utilities I've got. And the LED doesn't blink as on the H750VB.

[andrewleech]

Ah, I presume you're using your changes for ospi then? #12523
I see it hasn't had any of the memory_map stuff ported over from the qspi driver, that would be needed for booting from it.

The stm32-bootloader you're seeing in device manager, if it's the ROM built in dfu bootloader then check if it's a boot0 switch being pressed? That shouldn't come up otherwise. Else it could be mboot running and just looking the same in device manager? Maybe double check the vid/pid of the device that's coming up.

I would suggest disabling MBOOT_FSLOAD for now as it possibly means mboot will try to configure / read the filesystem (on flash it doesn't know how to access).

[nspsck]

Ah, I presume you're using your changes for ospi then? #12523
I see it hasn't had any of the memory_map stuff ported over from the qspi driver, that would be needed for booting from it.

No, I just made it as a QSPI flash because when I were trying to use OSPI, the compiler keeps telling me:

/home/bla/mpy/micropython/ports/stm32/boards/WEACTH7B0VB/bdev.c:14:26: error: 'quadspi_proto' undeclared here (not in a function); did you mean 'qspi_proto'?
   14 |     .bus.u_qspi.proto = &quadspi_proto,
      |                          ^~~~~~~~~~~~~
      |                          qspi_proto
make: *** [Makefile:279: build-WEACTH7B0VB//bla/mpy/micropython/ports/stm32/boards/WEACTH7B0VB/bdev.o] Error 1

To keep it shut (ye, ... I know.. that's a terrible approach...). But now from this conversation, I've got a feeling, that the mboot bootloader tries to connect to the external flash and if it fails, it will put itself into a error state and hence the LED won't blink. Could the be correct?

The stm32-bootloader you're seeing in device manager, if it's the ROM built in dfu bootloader then check if it's a boot0 switch being pressed? That shouldn't come up otherwise. Else it could be mboot running and just looking the same in device manager? Maybe double check the vid/pid of the device that's coming up.

It looks something like this:

And now I read the error message (for the first time.. ye.. I really have to start reading those...), it says something in translation like:

The device cannot be started. (Code 10)

{Device Timeout}
The specified I/O operation on %hs reached the time limit before the I/O operation could be completed.

I would suggest disabling MBOOT_FSLOAD for now as it possibly means mboot will try to configure / read the filesystem (on flash it doesn't know how to access).

That's probably the cause! I read these lines in the main.c. It looks like the miss configured OSPI surely will cause some serious issue!

    #if defined(MBOOT_SPIFLASH_ADDR)
    MBOOT_SPIFLASH_SPIFLASH->config = MBOOT_SPIFLASH_CONFIG;
    mp_spiflash_init(MBOOT_SPIFLASH_SPIFLASH);
    #endif
}

Thank you for your time and effort! I'll start solving that OSPI problem first!