ChibiOS Free Embedded RTOS

Posted: **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)

Posted: **Tue Dec 15, 2020 11:17 am**

Hi,

Yes, it is supported.

Giovanni

Posted: **Sat Dec 19, 2020 4:14 pm**

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

Posted: **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

Posted: **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

Posted: **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

Posted: **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

Posted: **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

Posted: **Sat Feb 20, 2021 7:21 pm**

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

Giovanni

Posted: **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

ChibiOS Free Embedded RTOS

Memory-mapped flash on F7 and H7

Memory-mapped flash on F7 and H7

Re: Memory-mapped flash on F7 and H7

Re: Memory-mapped flash on F7 and H7

Re: Memory-mapped flash on F7 and H7

Re: Memory-mapped flash on F7 and H7

Re: Memory-mapped flash on F7 and H7

Re: Memory-mapped flash on F7 and H7

Re: Memory-mapped flash on F7 and H7

Re: Memory-mapped flash on F7 and H7

Re: Memory-mapped flash on F7 and H7