To enter our bootloader.

Do you want to have the OPENMV_N6 board definition included in MicroPython's stm32 port (like with the OPENMV_AE3)? If so, it should work with mboot. But probably also a good idea to work with the OpenMV bootloader, which means adding this code.

Related: how did you choose address 0x3401FFFC? That's part way through SRAM1, in the FLEXRAM area. You'd need to make sure that isn't cleared on reset like the rest of SRAM1/2, and also make sure it's not overwritten by the bootloader.

Do you want to have the OPENMV_N6 board definition included in MicroPython's stm32 port (like with the OPENMV_AE3)? If so, it should work with mboot. But probably also a good idea to work with the OpenMV bootloader, which means adding this code.

Either way is fine with me. If mboot support is kept, I can always use MP_CONFIGFILE to override and not build mboot when building our firmware.

Related: how did you choose address 0x3401FFFC? That's part way through SRAM1, in the FLEXRAM area. You'd need to make sure that isn't cleared on reset like the rest of SRAM1/2, and also make sure it's not overwritten by the bootloader.

Good point. The bootloader uses the 128K (or 64K) DTCM for its memory (heap, stack etc..), so this address is typically 0x2001FFFCU (last word of bootloader's memory) and it's the same for almost all boards. However, for some reason, this doesn't work on the N6, so I just used SRAM1. Note that SRAM1 and SRAM2 don't seem to get erased on reset, otherwise this wouldn't work, but it would still be better to use DTCM for this, but it's not working.

Oh I think I just needed a DSB, seems the write might be buffered. The following works too:

#define OMV_BOOT_MAGIC_ADDR   (0x3001FFFCU)
#define OMV_BOOT_MAGIC_VALUE  (0xB00710ADU)

void board_enter_bootloader(void) {
    *((uint32_t *) OMV_BOOT_MAGIC_ADDR) = OMV_BOOT_MAGIC_VALUE;
    __DSB();
    NVIC_SystemReset();
}

@dpgeorge There seems to be some issue with DTCM, I can't access any address above ~0x1000. This causes a fault on boot when it tries accesses the magic number address (oddly enough, it doesn't always happen). Perhaps it has something to do with security config, flexram, clocks or something else that gets enabled by the main firmware, but even from the main firmware I still can't access this memory from gdb. Anyway let's please keep the original boot address (with cache clean).

I need to be able to disable mboot USE_MBOOT ?= 1 and also we never use LFS2, just fat.

I've made all these options use ?=.

But note that the way it's configured you'll probably want to enable USE_MBOOT because that puts the firmware in external flash. Otherwise MicroPython runs from RAM.

Is there any way to build a flash-based image just without mboot? Like an option to do so, that gets forced to one if mboot is enabled, otherwise is user-defined?

I think that's just USE_MBOOT=1. I guess it should be called USE_BOOTLOADER=1 but for consistency it's the mboot option.

That option is anyway local to the board (nothing outside the board uses this config option, except mboot itself). The option controls:

1. which ld scripts to use
2. location of .text

But what if you don't want to build mboot, yet still want a flash-based image? Can USE_MBOOT=1 define something like MICROPY_FLASH_BASED=1? For example:

USE_MBOOT ?= 1
MICROPY_FLASH_BASED ?= $(USE_MBOOT)

This way I can define USE_MBOOT=0 MICROPY_FLASH_BASED=1 to get a flash-based image without mboot.

Mboot is not built unless you explicitly do make in the ports/stm32/mboot directory.

But, I can do what you suggest, it makes sense.

For our bootloader, we need the following:

#define MICROPY_HW_ENTER_BOOTLOADER_VIA_RESET   (0)

extern void board_early_init(void);
#define MICROPY_BOARD_EARLY_INIT    board_early_init

extern void board_enter_bootloader(void);
#define MICROPY_BOARD_ENTER_BOOTLOADER(nargs, args) board_enter_bootloader()

With the following code in board.c (which could be gated if mboot is enabled):

#include STM32_HAL_H
#include "py/mphal.h"

#define OMV_BOOT_MAGIC_ADDR   (0x3401FFFCU)
#define OMV_BOOT_MAGIC_VALUE  (0xB00710ADU)

void board_early_init(void) {

}

void board_enter_bootloader(void) {
    *((uint32_t *) OMV_BOOT_MAGIC_ADDR) = OMV_BOOT_MAGIC_VALUE;
    SCB_CleanDCache();
    NVIC_SystemReset();
}

I've now made the board work with both the OpenMV bootloader and mboot.

There's a proper init sequence for this in the examples in the HAL, if you want to take a look. I think it's more or less the same, but there were some delays, more force_reset/release etc...

Also, could you please add this? I use it in HS mode.

diff --git a/ports/stm32/usbdev/class/inc/usbd_cdc_msc_hid.h b/ports/stm32/usbdev/class/inc/usbd_cdc_msc_hid.h
index 3a87896b4..5906f95e0 100644
--- a/ports/stm32/usbdev/class/inc/usbd_cdc_msc_hid.h
+++ b/ports/stm32/usbdev/class/inc/usbd_cdc_msc_hid.h
@@ -11,7 +11,7 @@
 
 // Work out if we should support USB high-speed device mode
 #if MICROPY_HW_USB_HS \
-    && (!MICROPY_HW_USB_HS_IN_FS || defined(STM32F723xx) || defined(STM32F733xx))
+    && (!MICROPY_HW_USB_HS_IN_FS || defined(STM32F723xx) || defined(STM32F733xx) || defined(STM32N6))
 #define USBD_SUPPORT_HS_MODE (1)
 #else
 #define USBD_SUPPORT_HS_MODE (0)

I've added the USBD_SUPPORT_HS_MODE option as above.

But testing it with #15909 shows that there is data corruption when HS is enabled. That needs investigation.

Can we use function attributes to put these in a ram_func section instead? There's an example for this in mimxrt, and then we just need to add asm code to copy this section to where it needs to go (also an example in mimxrt's startup code). This is much cleaner and will not need the code in main.c.

There are quite a few functions that need to go in RAM, and even some HAL functions (which are inline... but the compiler still makes them non-inline). So I think it's simpler to configure that in a linker script.

There's already asm code in resethandler_m3_iram.s that does the copy. The code in main.c that copies to RAM was already there before N6 support.

even some HAL functions (which are inline... but the compiler still makes them non-inline).

Could it be the -Os ?

There's already asm code in resethandler_m3_iram.s that does the copy. The code in main.c that copies to RAM was already there before N6 support.

So code in main is not really needed? Just for my own understanding, why do we need so much code (including HAL GPIO functions) in RAM? Is it needed when waking up from STOP mode? I assume standby doesn't really need that because it resets on wakeup.

I've now cleaned this IRAM stuff up, and there's now only a single RAM section that needs to be copied. That copy is done in asm in resethandler_m3_iram.s.

Just for my own understanding, why do we need so much code (including HAL GPIO functions) in RAM? Is it needed when waking up from STOP mode? I assume standby doesn't really need that because it resets on wakeup.

Code in RAM is needed for two things:

• Writing to flash, which needs all the SPI flash logic from drivers/memory/spiflash.o and XSPI code
• Waking from standby! The N6 has SRAM1 retention during standby and a special SYSCFG register that you can set to tell the MCU where to resume when waking from standby. This allows it to wake up much faster from standby by executing code straightaway from SRAM1, instead of going through the bootloaders. So there needs to be enough code in RAM to be able to act like a mini bootloader that can do just enough to enable XSPI memory mapped mode.

@dpgeorge - This is for light sleep or deepsleep? Deepsleep should always result in a reboot after waking up. Awesome for light sleep though.

https://www.st.com/resource/en/application_note/an5946-how-to-optimize-lowpower-modes-on-stm32n6-mcus-stmicroelectronics.pdf

Damien, did you see this doc?

@dpgeorge @kwagyeman Thanks for explaining and for the app note! The app note seems to imply that this is optional, so if not retained it should NVIC reset. Perhaps this is worth a support question? My goal here is to minimize the RAM code to just xspi.c, to eventually use gcc section attribute on all functions and data that file, and then all we need in our firmware is a ram_func section and copy code to the startup code.

Writing to flash, which needs all the SPI flash logic from drivers/memory/spiflash.o and XSPI code

Is spiflah.o really needed in RAM or is it a speed optimization? Could we get away with just the XSPI code as it does the actual erase/write?

Is spiflah.o really needed in RAM or is it a speed optimization? Could we get away with just the XSPI code as it does the actual erase/write?

Yes it's needed. That code has all the logic to set WREN and wait for the erase to complete, for example.

Also, as mentioned, if the SPI flash is in DTR mode then it won't work with the ST ROM bootloader if the SPI flash is not fully reset upon waking from standby/deepsleep. And I don't think it is fully reset when waking from standby. If so, that would need code in SRAM1 in retention mode to reset it, before doing an NVIC reset (if that even works, I couldn't get it to bounce into the ST ROM bootloader).

It's only using about 4k of SRAM1 at the moment. Is that really such an issue? We could try to optimise that down a bit. Eg maybe it doesn't need the app ISR moved there (although I'd suggest doing that regardless, for IRQ performance reasons.)

if the SPI flash is in DTR mode then it won't work with the ST ROM bootloader if the SPI flash is not fully reset upon waking from standby/deepsleep

The boards are designed such that they reset the flash on NVIC reset (same should apply for devkits, we're following the reference design here), so it should fully reset the flash if an NVIC reset occurs. This feature is crucial for them to function, otherwise machine.reset() wouldn't work. So normally you just need to ensure an NVIC reset occurs somehow. How about using the address of something like this instead? Would this simplify things a bit?

__attribute__((noreturn, section(".ram_function"))) void board_reset(void) {
    // NVIC_SystemReset doesn't get inlined here.
    SCB->AIRCR  = (uint32_t)((0x5FAUL << SCB_AIRCR_VECTKEY_Pos) |
                             (SCB->AIRCR & SCB_AIRCR_PRIGROUP_Msk) |
                             SCB_AIRCR_SYSRESETREQ_Msk);
    __DSB();
    for (;;) {
        __NOP();
    }
}

Is that really such an issue? We could try to optimise that down a bit. Eg maybe it doesn't need the app ISR moved there (although I'd suggest doing that regardless, for IRQ performance reasons.)

Probably not, it's not the memory size I'm concerned about, in fact I put all of that code in ITCM which is not used at all, it's just that I use a shared linker script so I'm trying to figure out the bare minimum customization needed for the N6.

I assume this is because IRQs are being disabled for too long? If that’s the case, would it help to re-enable IRQs after each block erase/write operation, rather than keeping them disabled across all blocks? If I’m not wrong, this is how it's done in the mimxrt and rp2 ports, and it might help avoid the need to move all those functions and their data to RAM.

Actually, the UART functions don't need to go in RAM anymore. I've fully disabled IRQs during XSPI flash erase/write. It didn't seem to work if I just raised the IRQ priority level.

And the code in spibdev.c does enable IRQs after each block erase.

Make larger? We have 1GB/s Ethernet onboard.

I prefer if we use the config I made for mimxrt and alif, back then I checked it against the docs and every option is carefully calculated and it performs very well:

#define MEM_SIZE                        (16 * 1024)
#define TCP_MSS                         (1460)
#define TCP_OVERSIZE                    (TCP_MSS)
#define TCP_WND                         (8 * TCP_MSS)
#define TCP_SND_BUF                     (8 * TCP_MSS)
#define TCP_SND_QUEUELEN                (2 * (TCP_SND_BUF / TCP_MSS))
#define TCP_QUEUE_OOSEQ                 (1)
#define MEMP_NUM_TCP_SEG                (2 * TCP_SND_QUEUELEN)

Could increase the MEM_SIZE if you like.

Probably wait till performance testing things with ipref3 when ethernet is working.

I prefer if we use the config I made for mimxrt and alif,

When I updated this I checked that all options I left out here take their defaults and the defaults match that your configuration. So these settings do match what you have.