STM32N6570-DK: No expected BootFailed UART output on PG10 / UART5_TX, instead ~4.3 MHz square wave

[Eugen]

Title:
 

Hello,

I am investigating BootROM behavior on an STM32N6570-DK.

My expectation is based on the STM32N6 BootROM documentation and errata:
- PG10 is used as BootFailedn in blocking failure conditions.<sup class="chatgpt-doc-sup"><span title="ES0620-STM32N6_Rev4.pdf, page 7" /></sup>
- There is a known erratum: “PG10 (BootFailedn) signal not maintained at 1 during blocking failure”, with no workaround listed.<sup class="chatgpt-doc-sup"><span title="ES0620-STM32N6_Rev4.pdf, page 7" /></sup>

Observed behavior on my board:
- If the content of the OctaFlash is erased, I do not receive the expected serial BootFail-related output on PG10 / USART5_TX.
- Measuring PG10 with an oscilloscope, I see a ~4.3 MHz square wave instead.
- I observe the same square wave again after setting BOOT1=1 and BOOT0=0 and then resetting the board.

Additional context:
- I found guidance that Development Boot mode can be relevant for programming/erasing external flash on STM32N6570-DK.<sup class="chatgpt-doc-sup"><span title="STCommunityTopic#stm32n6570-dk-unable-to-erase-external-flash" /></sup>
- I also found discussion that for STM32N6 boot/debug connection issues, boot-pin configuration matters and dev-boot mode may help during investigation.<sup class="chatgpt-doc-sup"><span title="STCommunityTopic#unable-to-connect-stm32n657z0h3q" /></sup>

My questions:
1. Is the ~4.3 MHz square wave on PG10 a known BootROM behavior during blocking failure?
2. Can the PG10 erratum explain that no valid UART output is observable on this pin?
3. Has anyone from ST seen this exact behavior on STM32N6570-DK?

Any confirmation from ST or from users who measured PG10 directly with an oscilloscope would be very helpful.

Best regards

[ethonbrooks0707]

A 4.3 MHz square wave on the UART TX pin instead of the expected boot message suggests the MCU may not be reaching the boot code at all, or that the UART pin is being driven by another peripheral or incorrect clock configuration. I'd verify the BOOT switch settings, confirm the UART5 pin multiplexing matches the board schematic, and test with a known ST example that outputs over UART. It would also help to know whether you're using the factory firmware or a custom build, and whether the ST-LINK debugger can halt the CPU after reset.

[Eugen]

I erased the OctaFlash of the DK using BOOT1=1, then switched to BOOT0=0 and BOOT1=0, and then pressed the reset button.

[Eugen]

The problem still exists

[RomainR.]

Hi ​@Eugen 

This is the Dev_Boot mode of the STM32N6, which allows the programming and erasing of the Serial Flash (BOOT1/PA6 = 1 and BOOT0 = X).

This mode primarily allows the user to load and debug code from internal SRAM using an IDE, since the JTAG/SWD debug port remains open.

The 4.3 MHz square wave signal you observe on PG10 is generated by the BootROM when the N6 is in Dev_Boot mode. It has nothing to do with a boot failure in the BootROM. It is not generated in Flash or Serial Boot modes.

The boot failure and the appearance of the UART5_TX trace on PG10 should occur in the boot use cases described in Figure 2, “Boot ROM code flow diagram,” and in Section 3.10, “Error and trace logging,” of UM3234.

Please note that in the event of a boot failure, the traces are written by the BootROM into AXI-SRAM2 memory at the address TRACE_BUFFER_SEC_BASE_ADDR (0x341037F0).
 

Best regards,
Romain