Memory-mapped flash on F7 and H7

[andypiper]

F7 and H7 have support for memory-mapped flash over QSPI - does ChibiOS have support for this (I know it has support for QSPI but I think the STM32 support goes deeper than that)

[Giovanni]

Hi,

Yes, it is supported.

Giovanni

[andypiper]

Thanks - found it - will play with it once I have a board that supports QSPI

[andypiper]

HJ, I have a board and I have upgraded to 20.3.3 but I am missing an example of how to use this - Ithought there was an example originally - can you point me at one?

Many thanks, Andy

Hi,

Yes, it is supported.

Giovanni

[Giovanni]

Hi,

It is in main.c of the WSPI demo:

Code: Select all

  /* Testing memory mapped mode.*/
  {
    uint8_t *addr;

    snorMemoryMap(&snor1, &addr);
    chThdSleepMilliseconds(50);
    snorMemoryUnmap(&snor1);
  }

if you break after snorMemoryMap() you can see the memory @addr

Giovanni

[andypiper]

Ah got it - thanks.

So the board I am testing with apparently puts the MCU into QSPI mode before starting at the mapped address (which is 0x09010000) which contains all of the executable code (so its all in external flash). Is it going to be possible to bootstrap ChibiOS like this or will I have to write some kind of memory resident bootloader? I'm just wondering what kind of reset is done by chinos starting - not sure how I can initialise ChibiOS without messing up the QSPI mapping it is booting from or whether I need to initialise QSPI at all.

Regards

andy

Hi,

It is in main.c of the WSPI demo:

Code: Select all

  /* Testing memory mapped mode.*/
  {
    uint8_t *addr;

    snorMemoryMap(&snor1, &addr);
    chThdSleepMilliseconds(50);
    snorMemoryUnmap(&snor1);
  }

if you break after snorMemoryMap() you can see the memory @addr

Giovanni

[Giovanni]

If QSPI is initialized by your bootloader then there is a problem, the HAL resets all peripherals on halInit(), you need to remove the reset of QSPI from the initialization code.

Code: Select all

void hal_lld_init(void) {

  /* Reset of all peripherals. AHB3 is not reseted because it could have
     been initialized in the board initialization file (board.c).
     Note, GPIOs are not reset because initialized before this point in
     board files.*/
  rccResetAHB1(~STM32_GPIO_EN_MASK);
  rccResetAHB2(~0);
  rccResetAPB1(~RCC_APB1RSTR_PWRRST);
  rccResetAPB2(~0);

Note how in the above code GPIOs and PWR are not reset, do the same for QSPI.

GPIOs and clocks re-initialization could also be a problem, make sure to setup QSPI pins correctly so it does not change while running. I am not sure this can work without glitches.

Giovanni

[andypiper]

Ok, thanks - I'll try this. Presumably another approach would be to use the linker to put the initialisation code in RAM and then bootstrap from there into the QSPI initialised flash?

If QSPI is initialized by your bootloader then there is a problem, the HAL resets all peripherals on halInit(), you need to remove the reset of QSPI from the initialization code.

Code: Select all

void hal_lld_init(void) {

  /* Reset of all peripherals. AHB3 is not reseted because it could have
     been initialized in the board initialization file (board.c).
     Note, GPIOs are not reset because initialized before this point in
     board files.*/
  rccResetAHB1(~STM32_GPIO_EN_MASK);
  rccResetAHB2(~0);
  rccResetAPB1(~RCC_APB1RSTR_PWRRST);
  rccResetAPB2(~0);

Note how in the above code GPIOs and PWR are not reset, do the same for QSPI.

GPIOs and clocks re-initialization could also be a problem, make sure to setup QSPI pins correctly so it does not change while running. I am not sure this can work without glitches.

Giovanni

[Giovanni]

That would be cleaner, probably QSPI would survive a reinitialization anyway.

Giovanni

[andypiper]

Also this code does not look like this in the H7 lld - is that because initialisation is slightly different?

So something like this

Code: Select all

  rccResetAHB3(~(RCC_AHB3RSTR_FMCRST | RCC_AHB3ENR_QSPIEN | RCC_AHB3RSTR_QSPIRST
                 0x80000000U));     /* Was RCC_AHB3RSTR_CPURST in Rev-V.*/

If QSPI is initialized by your bootloader then there is a problem, the HAL resets all peripherals on halInit(), you need to remove the reset of QSPI from the initialization code.

Code: Select all

void hal_lld_init(void) {

  /* Reset of all peripherals. AHB3 is not reseted because it could have
     been initialized in the board initialization file (board.c).
     Note, GPIOs are not reset because initialized before this point in
     board files.*/
  rccResetAHB1(~STM32_GPIO_EN_MASK);
  rccResetAHB2(~0);
  rccResetAPB1(~RCC_APB1RSTR_PWRRST);
  rccResetAPB2(~0);

Note how in the above code GPIOs and PWR are not reset, do the same for QSPI.

GPIOs and clocks re-initialization could also be a problem, make sure to setup QSPI pins correctly so it does not change while running. I am not sure this can work without glitches.

Giovanni