1
\$\begingroup\$

Here's the current scenario: There's a remote STM32 MCU F746ZG that is prohibitively expensive to retrieve or access, and only has an I2C1 connection.

The USART peripheral interface is causing issues (hanging the device intermittently, something which was not caught during extensive testing), and flashing new code into the MCU is not possible. e.g there is no remote command that allows for HAL_USART_DeInit().

My objective is to disable the USART interface permanently via direct access to USART registers in MCU's flash.I understand from the reference manual of stm32f74xxx RM0385 Rev 8 in Section 2.2.2 that the USART_CR1 is directly accessible with the address provided in Table 1.

Section 2.5 of the same document (RM0385 Rev 8) also defines the sequence to start the bootloader, but it does not help me as I do not have physical access to the bootpin now, only an I2C bus.

Following AN2602 Section 4.1, Pattern 8 should be applied to activated the bootloader

enter image description here

Assuming this pattern is done, I should then be able to send the slave address as shown in AN2606 Rev 59 Table 83 to put it into bootloader mode.

Following that, I would then write memory to the USART CR1 register to disable it, before enabling write protect to prevent the current application from enabling it.

My questions is three-fold:

  1. Given that I have never uploaded a custom bootloader code before, is it possible to activate the embedded bootloader?
  2. I did not program BOOT_ADD0 at all, and I have no way of determining what it is either due to the remote location of the MCU. Given the default value programmed by ST of 0x0020 0000, does this mean it is impossible for me to execute pattern 8 remotely?
  3. Assuming I am able to activate Pattern 8 remotely, how would I ensure that the application, which currently has a USART_Init written in it, would not overwrite the changes I have made to the USART_CR1 register?

The only forms of control I currently have is

  1. a I2C connection to the MCU via a separate MCU (not stm32) that can receive Over-the-Air software updates
  2. control over its power lines.
\$\endgroup\$

1 Answer 1

0
\$\begingroup\$
  1. Activating the embedded bootloader means you need to somehow be able to boot the MCU into it, by powering it up or resetting while applying the correct pattern. If you cannot set boot0 high remotely, you can't enter the factory bootloader.

  2. If what you say is true, and MCU default is different from what is required to enter bootloader, then it cannot be entered until the boot address flags are correct. But then it means accessing the MCU via JTAG/SWD only. Usually the default settings allow you to boot a never before used MCU to bootloader but this may be different.

  3. But that's not how it works. You can't write to UART peripheral register and store settings somehow and preventing your main program from enabling it. You need to modify your main program and reprogram the firmware. If you can trigger the STM into bootloader, you can upload firmware via I2C.

\$\endgroup\$
1
  • \$\begingroup\$ Thanks for the answer! I think that confirms the obstacles I face, so it seems it is impossible in my scenario to trigger STM into bootloader remotely. Will keep this in mind for future deployments. \$\endgroup\$
    – UberChio
    Commented Sep 6, 2023 at 6:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.