Bootloader NACK on some chips but not others (not electrical problem)

[DDziu.1]

We are using stm32g431c8t6 and firmware update is performed by another MCU placed on the same board, via UART bootloader.

During development everything was fine - but after production, on some chips (~10 out of 50) bootloader behavior is undocumented:

• boot init (via setting BOOT0 pin high and reset) goes fine
• bootloader responds with ACK on initial 0x7F byte
• after that on most chips, readout unprotect, erase pages and subsequent firmware writes are going fine
• on some chips, bootloader responds with NACK on any command - including 0x00 and 0x01 ones (which shouldn't ever happen if stm received correct request).

Of course this looks like wrong levels or poor timing or something - but not only I've checked it with a scope (everything was fine) and tried multiple speeds from 4800 to 115200, at one occasion this behavior stared appearing when I connected _properly functioning_ chip to CubeProgrammer via stlink, read its state (without writing!), and disconnected it - after this process bootloader became "locked" and responded with NACK on any request. After connecting it again, performing mass erase and disconnecting - bootloader started functioning normally.

All option bytes are at default values, no readout protection (0xAA), no write protection, no suspicious settings.

On some of faulty chips, repeating this procedure (mass erase via CubeProgrammer) unlocked the bootloader, on some chips it didn't. Mass erase via openocd didn't help with any chips.

Any ideas what can be causing that?

[DDziu.1]

UPDATE: solution found MYSTERY INTENSIFIES

Originally it looked like it was solved - that's what I wrote 2 days ago:

It is caused by very poor precision of internal RC oscillator of stm on some chips. The unit I was testing for all UART speeds had another unrelated problem and failed due to it - other units without this problem started working at 4800 speed (but some didn't work even at 9600, while before I've uploaded at 115200 and on 80% of units it worked fine).

But 2 days later, two out of 4 "fixed" units stopped working without me touching them in any way. They literally were laying in a box when I took one to test an update - and found that bootloader is not working anymore! I've tested all 4 which were working 2 days ago - and it turned out that 2 didn't work. I'm genuinely clueless what is happening.

[VTaya.1]

Hello @DDziu.1​ .

As you are saying this issue is due to  internal clock deviation and if  internal clock deviation is beyond tolerance level how are internal bus protocols communicating in that case. I believe if clock is not precise all calculations can go wrong and controller will not understand anything.

I have a host controller with code for firmware update by SPI boot mode, it is working fine with slave STM32H723 controller and programmed bytes can be read out in STMCubeProgrammer.

Connecting another controller ( STM32H745II ) with host controller for firmware update result failure in establishing communication in SPI boot mode.

Do I need to make any extra changes in the code flow in case of Dual core controller (STM32H745II) ?

Is it possible to get any example code to update firmware of STM dual core controller by SPI protocol in Boot mode ?

@Community member​ 

[DDziu.1]

I'm not sure anymore that it's caused by RC precision - just updated my comment, it wasn't a reliable solution.

I plan to switch to SPI bootloader instead of UART to see if that makes any difference, but that requires changes in PCB connection so not sure when I'll have any results - possibly I can add some air wires to test on units I have at hand.