Memory-mapped flash on F7 and H7
Moderators: RoccoMarco, barthess
Memory-mapped flash on F7 and H7
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
- 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
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
Many thanks, Andy
Giovanni wrote:Hi,
Yes, it is supported.
Giovanni
- 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
Hi,
It is in main.c of the WSPI demo:
if you break after snorMemoryMap() you can see the memory @addr
Giovanni
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
Re: Memory-mapped flash on F7 and H7
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
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
- 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
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.
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
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
Re: Memory-mapped flash on F7 and H7
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
- 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
That would be cleaner, probably QSPI would survive a reinitialization anyway.
Giovanni
Giovanni
Re: Memory-mapped flash on F7 and H7
Also this code does not look like this in the H7 lld - is that because initialisation is slightly different?
So something like this
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
Who is online
Users browsing this forum: No registered users and 16 guests