STM32H750 rev V chip does not respond to sync command in bootloader mode. Rev Y does!

[DB1]

Help please. I have a STM32F0 and two STM32H750 micros all sharing Tx,Rx and Boot 0 lines but separate reset lines to a host processor running Linux. I need to be able to reprogram all three STM32's one at a time from the host. The F0 works fine, no problem, but the H750 does not respond to the 0x7F sync byte.  

On the H750 I'm using USART1 (PA9, PA10). The uart is not used for anything else except loading firmware in bootloader mode. When the micro is running, PA9 and PA10 are configured as inputs with no pull up/down and are not used.

I have verified the boot 0 and reset lines are toggled in the proper sequence and get pulled all the way up to 3.3 and gnd. I have tried to isolate a single H750 by tying the other reset lines to hard ground. The other Tx/Rx lines are hiZ.

I have tried all the baud rates between 9600 and 4000000 and measured the pulse width and verified that they are within spec(+/- 0.5%)

The final twist is that I have found two revision H750 parts on our hardware and based on what I have tested so far, chips marked as rev V never respond to the sync byte, but chips marked as rev Y do and can be programmed. I will add that they almost never respond to the first sync byte, but do after between 2 and 5 retries. My update software retries 10 times before failing. They also ONLY respond to 115200 baud rate.

I have scoured AN2606, 3155, the datasheet errata and refManual but don't see what I am missing.

We are just starting production and not being able to update firmware in the field is a very big problem. If anybody has any insight to this issue, I would really like to know.

Thanks,

Dave

[Tesla DeLorean]

Sounds like something to discuss with your FAE. Perhaps file an "Online Support" ticket?

What version does the loader report itself to be?

The loader is sensitive to inputs on multiple interfaces, if ST added more features/interfaces that might present a problem.

This pin list in the Sept 2019 AN2606 is getting a bit long, might help if ST flags the critically sensitive ones.

https://www.st.com/content/ccc/resource/technical/document/application_note/b9/9b/16/3a/12/1e/40/0c/CD00167594.pdf/files/CD00167594.pdf/jcr:content/translations/en.CD00167594.pdf

Notes like this are also a bit troubling..

"Note: To be able to connect to the bootloader USART1 using PB14/PB15 pins, you need to send two synchronization bytes."

[Tesla DeLorean]

>>The final twist is that I have found two revision H750 parts on our hardware and based on what I have tested so far, chips marked as rev V never respond to the sync byte, but chips marked as rev Y do and can be programmed. I will add that they almost never respond to the first sync byte, but do after between 2 and 5 retries. My update software retries 10 times before failing. They also ONLY respond to 115200 baud rate.

How long out of reset before you probe?

[DB1]

Thanks for the response Clive. I have already contacted the FAE, but wanted to share with the forum to see what others know and provide help to others in the future.

Right now I am waiting 500ms after reset before probing, but I have tried many others. Think I started at 100ms, then 200ms,..

Also just for debugging I have sat in a loop just sending the sync byte over and over again, waiting various lengths of time between resends, but still get no response from the H7.

[Tesla DeLorean]

500ms sounds more than enough.

The sync pattern on the USART is typically a once and done thing. The loader has the input in TIM mode and measures the pulse train of the 0x7E 8E1 pattern for auto-baud purposes, the USART isn't "receiving" the 0x7F, the TIM gets it a timing measurement and the USART responds with 0x79. If it miss judges the pattern it should just respond at the wrong speed.

[DB1]

That's what we thought too; it does sound like it is not receiving the sync. I have started running some tests just to prove to myself that the usart does work using some ST HAL example code that implements a basic hyper-terminal. So far I'm getting some partial data out and nothing in yet, but I'm still working on hooking things up.

Another note is that my design uses an external 24.576MHz crystal, but I believe the bootloader uses the internal HSI 64MHz? is that right. I know the HSI clock is not as accurate. In my usart testing I have switched back and forth between the two and can see the pulse width accuracy go down when the HSI is used.

[Tesla DeLorean]

Should use 64 MHz HSI. It might benchmark the HSE for USB/CAN.

HSI should be fine for serial, and any slight bias will basically be folded into the auto-baud computation.

The ROM is located at 0x1FF09800 [0xF000]

The V ROM, that I have starts with the words 0x24003AF8, 0x1FF09ABD, 0x1FF0B4CD

[Tesla DeLorean]

Kind of wished I hadn't asked myself the question

24003228, 1FF09ABD, 1FF0B6B9, [SIZE=0000C5D8, CRC32=725907CF] h747_x_rom.bin

24003AF8, 1FF09ABD, 1FF0B4CD, [SIZE=0000B868, CRC32=9FAC1927] h743_v_rom.bin

24003AF8, 1FF09ABD, 1FF0B4CD, [SIZE=0000B868, CRC32=9FAC1927] h745_v_rom.bin

24003AF8, 1FF09ABD, 1FF0B4CD, [SIZE=0000B868, CRC32=9FAC1927] h747_v_rom.bin

24003AF8, 1FF09ABD, 1FF0B4CD, [SIZE=0000B868, CRC32=9FAC1927] h750_y_rom.bin

24014130, 1FF09ABD, 1FF0C555, [SIZE=0000E9A8, CRC32=005ABE9B] h743_y_rom.bin

[DB1]

I found the problem.

First ST showed me a cool trick to figure out if the part was getting into bootloader mode. I connected to the H750 with my debugger and ran it. Then using jumpers I manually put the part in bootloader mode (pull boot0 high) and toggle the reset line. Then stop the debugger and look at the program counter. This will tell you what part of memory you are running out of. I found the PC to be in the 0x1ff0 range so I knew the part was in bootloader mode.

That confirmed our suspicion that the device was not properly receiving the sync byte or was being interfered with. So I started working my way down the list of alternate bootloader ports. The troublemaker was SPI1.

The app note states that these pins must be either high or low, doesn't matter. They just can't be chattering while it's trying to detect a sync command. Well, that's not quite right.

On my host processor side I had a pull up on MISO, MOSI looked like it was floating. While testing, I had both pins shorted to ground. This did NOT work!

I found that if I instead pulled MISO and MOSI up to 3.3V, it worked! I didn't really want to do a hw mod, so we modified the pin config on the host side so both pins would be pulled up. This too worked.

It seems to be working quite reliable now, but I'm still not very satisfied with this explanation. The the SCK is held low and the cs is held high. How can the H750 clock sync detection be thrown off by a completely inactive SPI port? This does not follow the documented expected behavior. It would appear that the MOSI and MISO must both be high or maybe just the same?

I'll repost here if I get more info from ST.