Memory-mapped flash on F7 and H7

ChibiOS public support forum for topics related to the STMicroelectronics STM32 family of micro-controllers.

Moderators: RoccoMarco, barthess

andypiper
Posts: 65
Joined: Sat Oct 24, 2020 5:21 pm
Has thanked: 5 times
Been thanked: 4 times

Memory-mapped flash on F7 and H7

Postby andypiper » Tue Dec 15, 2020 9:54 am

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)

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Memory-mapped flash on F7 and H7

Postby Giovanni » Tue Dec 15, 2020 11:17 am

Hi,

Yes, it is supported.

Giovanni

andypiper
Posts: 65
Joined: Sat Oct 24, 2020 5:21 pm
Has thanked: 5 times
Been thanked: 4 times

Re: Memory-mapped flash on F7 and H7

Postby andypiper » Sat Dec 19, 2020 4:14 pm

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

andypiper
Posts: 65
Joined: Sat Oct 24, 2020 5:21 pm
Has thanked: 5 times
Been thanked: 4 times

Re: Memory-mapped flash on F7 and H7

Postby andypiper » Sat Feb 20, 2021 5:09 pm

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

Giovanni wrote:Hi,

Yes, it is supported.

Giovanni

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Memory-mapped flash on F7 and H7

Postby Giovanni » Sat Feb 20, 2021 5:30 pm

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
Posts: 65
Joined: Sat Oct 24, 2020 5:21 pm
Has thanked: 5 times
Been thanked: 4 times

Re: Memory-mapped flash on F7 and H7

Postby andypiper » Sat Feb 20, 2021 6:07 pm

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

Giovanni wrote: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

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Memory-mapped flash on F7 and H7

Postby Giovanni » Sat Feb 20, 2021 6:20 pm

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
Posts: 65
Joined: Sat Oct 24, 2020 5:21 pm
Has thanked: 5 times
Been thanked: 4 times

Re: Memory-mapped flash on F7 and H7

Postby andypiper » Sat Feb 20, 2021 6:36 pm

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?

Giovanni wrote: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

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Memory-mapped flash on F7 and H7

Postby Giovanni » Sat Feb 20, 2021 7:21 pm

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

Giovanni

andypiper
Posts: 65
Joined: Sat Oct 24, 2020 5:21 pm
Has thanked: 5 times
Been thanked: 4 times

Re: Memory-mapped flash on F7 and H7

Postby andypiper » Sat Feb 20, 2021 7:23 pm

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.*/


Giovanni wrote: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


Return to “STM32 Support”

Who is online

Users browsing this forum: No registered users and 20 guests