STM32H7A3AII6Q Internal bootloader boot for firmware update.

[shubhenduatadben]

Hello,

    I'm working into writing firmware image to a STM32H7A3AII6Q via internal boot-loader. I'm using AN2606 and AN3155 as reference documents. 
    The boot-loader entry sequence I'm using:
State 1: BOOT0: high

              RST: low

State 2: Wait 200 ms

State 3: BOOT0: high

              RST: high

Then I'm sending 0x7F over USART2 but, getting no response(0x79).

Can you please help me what might be wrong here?

[mƎALLEm]

Hello,

You didn't tell what IOs you have used for USART2? PA2 and PA3?

If yes check your wiring (continuity test). Use an oscilloscope to check what happens on Tx and Rx.

[shubhenduatadben]

The board uses USART2: PA2,PA3. The USART is working well when connected to other boards and running application firmware. But, when isolated and tested by serial, there is no activity on USART: TX in the oscilloscope. 

The USB serial parameters:

BAUD: 115200

PARITY: EVEN

STOP: 1

[mƎALLEm]

---

@shubhenduatadben wrote:

The USB serial parameters:

BAUD: 115200

PARITY: EVEN

STOP: 1

---

You need to check that USB to UART bridge..connect its tx and rx and use an Hyperterminal and check if what you send you receive it. 

And use CubeProgrammer to connect to the ST bootloader: 

[shubhenduatadben]

USB-Serial is working fine, tested by RX-TX loopback. Still the CubeProgrammer fails to connect.

Attaching snapshot.

[mƎALLEm]

Did you monitor USB-UART bridge Tx with an oscilloscope during the CubeProgrammer connection? 

[shubhenduatadben]

The oscilloscope visuals seems 0x7F is being transmitted over TX.

[TDK]

You need to be in the bootloader in order for 0x7F to have an effect. AN2606 lists the ways to enter the bootloader. Most commonly, holding BOOT0 high during reset will enter the bootloader under most circumstances.

[mƎALLEm · Accepted solution]

Sorry I have an issue with the notifications today and didn't know you replied to me.

From your oscilloscope screenshot it seems you have that 0x7F which the target is waiting for:

Meanwhile I still insist on the hardware check:

1- Is there a mean to connect with the STM32H7 with STLINK?, to confirm if the chip is alive?

2- If you can connect with ST-LINK, check again your hardware and continuity between STM32H7_TX / USB-USART_Rx and  STM32H7_RX / USB-USART_Tx. You need to confirm that part and check if you are using the right pins. You could have a mismatch with what you are really doing and what you are thinking about what you did ;).