STM32N6 - NUCLEO board not as 1V8 possible?

[tjaekel]

It looks like (based on PCB and schematics) - I cannot run the VDDIO (all IO pins) with 1V8.
No option on this board to jumper IO voltage as 1V8 - why not?

"rrrrrr": I was thinking to change all my projects to this great board (speed, memory size), e.g. to have an user QSPI interfaces - as 1V8...
But this board does not support 1V8 (why not?). I would need level shifters again (which I tried to avoid due to performance reasons: board should run all IOs as 1V8!).

A great MCU, a great NUCLEO board - but at the end: very complicated to make use of it (e.g. this missing 1V8 feature and the FW to flash/load and run from external QSPI flash drives me crazy right now (no idea how to bring my working FW into QSPI memory and let it boot and execute from there), FSBL works fine but how to boot from QSPI).

It is like a completely new MCU for me (even I use STM32 MCU since years...).
Did STM make it more complicated to migrate to their new products?

BTW:
Maybe, updating this board in field when delivered to my customers, with just a new FW, seems to be also a bit complicated (they need STM32CubeProgrammer, more steps to do, ...).

Let's see: just a bit frustrating that the conversion to this great MCU and board seems to be much more complicated and more time consuming as expected. Not sure if the board will work at the end for me (at least this missing 1V8 option is a major blocker, let it boot and execute from QSPI - I am struggling with it...).

[RomainR.]

Hello @tjaekel 

Indeed, if you refer to the Nucleo-N657X0-Q schematic on page 4, only VDDIO3 is powered at 1.8V. This allows you to use the OCTOFlash NOR MX25UM512 on XSPI-Port2 and the GPIO PN[11:0] at 1.8V.

In addition, you must program (definitively) bit 15 HSLV_VDDIO3 of the OTP124 HCONF1 to be able to reach the max frequency of 200MHz of the XSPI (therefore at 1.8V as required by the external memory)

The other VDDs, VDDIO2, 4 and 5 are actually fixed at 3.3V (VDDIO). On the other hand, VDDIO4 and VDDIO5 can be powered at 1.8V by CN3 by removing the solder bridges SB24 and SB23.

What is different about the STM32N6 compared to other STM32 families is that it is flashless, it has an internal ROM that is securely programmed at the factory, and several AXISRAM banks of 4.2 Mbyte-contiguous.

Therefore, there are several possible execution contexts that you can discover in the library below: STM32Cube_FW_N6_V1.0.0\Projects\NUCLEO-N657X0-Q\Templates:
Note that these examples are all linked in the following way (see the linker .ld file):

• FSBL (or Boot) binary runs in AXISRAM2 (address 0x34180400)
• Appli binary runs in AXISRAM1 (address 0x34000400)

When you are in Dev_BOOT mode (BOOT0=1, BOOT1=x) your IDE (CubeIDE, IAR or Keil) is able to load your binaries where they should be executed in AXISRAM corresponding to the linker file, after a reset the secure BootRom starts, it opens the debug access port and let you load and debug your application normally.

When you are in Flash_BOOT (BOOT0=0, BOOT1=0) if you have previously signed and programmed the FSBL in the external OCTOFlash, after a reset the secure BootRom starts, and it will read the external OCTOFlash NOR to search for a FSBL binary and copy it into the AXISRAM2 at the address 0x34180000.
As the STM32_SigningTool.exe tool previously added a header of size 0x400 to this FSBL binary, the BootROM therefore jumps to the address 0x34180400 to execute it. The BootROM leaves the hand to the execution context of the user code.
Concerning the Appli binary, when it will also be programmed in OCTO Flash, it will be the FSBL that will copy it into the AXISRAM1 including its own header (0x400). To then be executed.
The last example demonstrate execute in place (XiP), this time, after reset the FSBL is still copied and executed in AXISRAM2, then it execute Appli binary from external Flash (in place) 

I hope it will help you. Let me know?

Best regards,

Romain,