Problems using the internal bootloader with an STM32F7

[Rub�n Acerete Halli]

Posted on April 19, 2017 at 12:18

Hello, I would like updating the firmware of an STM32F767ZI using the internal boot loader. I am using the USART3 (PB10 and PB11). In order to transfer the program I am using the program �Flash Loader Demostrator�.

My testing application has two parts. A led blink implemented in the main loop and the jump to the internal boot loader implemented in and EXTI interrupt. In that way when I press a button the application jump to the internal boot loader code and starts the updating process.

When I press the button and I star the communication with the flash Loader everything seems ok:

When I try reading the firmware appear the following message:

I try enabling the reading with the Flash Loader:

The program informs that the memory will be erased. After the process the result is:

When I try reading the program the result is the same as before:

If I use the ST_LINK Utility I can read and write the memory without problems. The configuration of the Option Bytes is:

I have tested the same process with STM32F407 and everything works fine.

Can anyone help me?

#bootloader #flash-loader-demonstrator #stm32f7 #read-protection

[Tesla DeLorean]

I can check with an STM32F756G-EVAL over the weekend, it exposes USART1 via the RS232 port, and does mention support for ISP.

https://www.st.com/en/evaluation-tools/stm32756g-eval.html

[Tesla DeLorean]

I found Cube Programmer v1.2.0 to be less than satisfactory, I was able to identify the chip and loader ID via both the RS232 and VCP connections to the board at 9600 8E1, but after that the progress bar would just swoosh back and forth endlessly.

STM32F756NGH6 Rev Z, Chip 0x449, Loader Ver 3.1

#Stm32f756g-eval​ 

[Gunnar Bohlen]

Hello,

thank you for testing this.

The chip you used was not exactly the one that I have here (STM32F765 vs. STM32F756)

Chip ID is 0x451, Bootloader protocol version : 3.1

I assume the binary file of the bootloader code is not exactly the same, so there is a chance that there is a bootloader bug in the device that we use ?!?

In case there is a known bug in the bootloader, ST could create a workaround in Cube programmer and discard the wrong first anser byte? (in case this is the only problem...., maybe only a bad initialiaztion of USART1?

As I said before, USART3 is working as expected, but the pins are not accessible in the current design.

Therefore I would be happy is ST says either:

-Yes its a known bug but no woraround available

-Yes its a known bug and a woraround available in *** weeks.

-...

With a clear answer we can decide to do a redesign or wait.

[Imen.D]

Hello,

I will raise your feedback internally to the appropriate team for check and investigation.

We'll keep you informed soon by our results.

Kind Regards,

Imen

[Tesla DeLorean]

Have also STM32F779I-EVAL (0x451)

[Nawres GHARBI]

Hi @Gunnar Bohlen​ 

Could you please copy paste the trace log

[Gunnar Bohlen]

Hello,

I do not have a valid trace file.

The flash tool sends the databyte 0x71 and it seems it expects a valid answer, otherwise the device it not detected and I can't do anything.

I used a scope to find out what is going on (no answer at all, wrong singal levels etc.) and found out that the answer from UART1 is 0xC0 0x79. On the other UART3 the scope shows the correct answer (only 0x79) , and the flash tool detects the correct device.

[Nawres GHARBI]

Hi @Rub�n Acerete Halli​ ,

Will be fixed next release 1.4.0 which will be on the web W51