STM32G030F6 I2C Bootloader not working : No ACK

[Mathieu Frohlich]

Hello,

In a master/slave system where I use stm32H7 as master and STM32G030F6 as slaves, I am trying to flash the slaves with the master using the System memory bootloader.

I can successfuly get to STM32G0 system memory (either on an empty one or one that I programmed earlier with a jumpTo code). However once I am in system memory, the slave is unresponsive to I2C addressing.

I am using I2C1 (PB6 as SCL and PB7 as SDA), and sending the address 0xA2 indicated in AN2606, but the STM32G0 slave doesn't ACK the address.

I have triple checked the hardware part, I am using a slow 25kHz I2C signal with the recommanded 1.8kOhm pull-up resistors.

Here is the transmission :

It looks fine to me, the master seems to properly send the 0xA2 write command, but the slave doesn't pull the SDA line low on last clock. Unless of course I am not understanding I2C correctly.

I have checked multiple time the reference manual, AN2606 and AN422, I just don't understand what I am missing, hope someone can help !

Cheers,

Mathieu

[waclawek.jan]

Is there any activity on other pins which would make the bootloader to go to some other branch than I2C1? There's also an erratum in AN2606 for older versions of the bootloader - you may want to check that.

If you have SWD connection, you can debug the bootloader as you'd debug your own program (except you don't have the symbols available).

JW

[Mathieu Frohlich]

Hello JW,

Thanks a lot for your quick reply. There might have been some other pins activity causing the bootloader to jump to another branch indeed. I simply disconnected those pins physically to be sure it isn't the case. It didn't solve the problem unfortunatly.

To what Errata are you refering ? In section "39.3 Bootloader version", it is stated that version 5.1 doesn't support 20pin package but I assume that the bootloader version in the actual 20pin package is up to date, right ?

As for debugging with SWD, here is the loop in which I am stuck in :

0x1fff11ee ldr r1, [r7, #8] 
0x1fff11f0 cmp r1, #1 0x1fff11f2 bne.n 0x1fff12c6 
...
0x1fff12c6 ldr r6, [pc, #568] ; (0x1fff1500) 
0x1fff12c8 ldr r0, [r6, #24] 0x1fff12ca ands r0, r5 0x1fff12cc beq.n 0x1fff127c 
...
0x1fff127e ldr r6, [pc, #632] ; (0x1fff14f8) 0x1fff127e ldr r0, [r6, #24] 0x1fff1280 ands r5, r0 0x1fff1282 beq.n 0x1fff119e
...
0x1fff119e ldr r5, [pc, #820] ; (0x1fff14d4) 0x1fff11a0 ldr r0, [r5, #28] 0x1fff11a2 lsls r0, r0, #16 0x1fff11a4 bpl.n 0x1fff11c8 
0x1fff11a6 ldr r0, [r5, #28] 0x1fff11a8 lsls r0, r0, #17 0x1fff11aa bmi.n 0x1fff11c8 
...
0x1fff11c8 movs r5, #8 0x1fff11ca ldr r0, [pc, #304] ; (0x1fff12fc) 0x1fff11cc ldr r1, [r0, #0] 0x1fff11ce ands r1, r5 0x1fff11d0 bne.n 0x1fff11ee 

I am not really good at assembly but it looks like some kind of flag checking loop, but my code doesn't leave it.

Maybe something is wrong with my JumpCode but the loop is the same weither I use the jump code or a fresh empty STM32G030F6 ...

I will try some flying wire to check if I can get the bootloader to work with USART !

Thanks a lot for the help.

Cheers,

Mathieu

[Mathieu Frohlich]

I did some wiggling to set-up an UART connection to my slave, and it works !

I can communicate with the STM32G030F6 bootloader.

When tasking the version, I get 0x31, which I guess is the version of the USART bootloader, not of the bootloader itself.

So my guess is, my STM32G030F6 chip comes with v5.2 of the bootloader. As stated in AN2606 it contain a bug which make the bootloader stuck if PA3 stays low. I am going to try I2C tomorrow with a pull-up on PA3 just to make sure it is the case, but either way, I'm going to have to change my hardware since I was using PA3 as an ADC pin :(

At that point the easiest thing to do is just switch to an UART connection for flashing my slaves. I hope this thread can save some headaches in the future.

Cheers,

Mathieu

[MMisa]

I have same problem, please comment, if you will success with i2c bootloader on STM32G030... (I have STM32G030K8T6 MCU, I have PA3 pin tied up by 4k3 resistor, but no luck).

[Mathieu Frohlich]

Hi MMisa,

I tried, with no luck also, I changed my layout to use USART instead ... The information should travel back to ST engineer !

[MMisa]

It seems that is wrong i2c address in the manual - it should be not 0x51, but 0x56. Now I can succesfully detect CPU with the stm32flash software. Unfortunatelly it seems that block erase is not working with the stm32flash tool. I didn't try mass erase and flashing yet (I have calibration values stored in the flash, so I am waiting to new boards for further tests).

[Mathieu Frohlich]

Using USART I managed to work with the embedded bootloader, but I had tons of issue with my initial architecture, in which I wanted my master (STM32H7) to be able to switch the slave (STM32G0) in bootloader mode to update it. It worked ... for a while, then some slaves stopped working after a jump to bootloader from main program, they were locked into the bootloader, with absolutely no way to get out even by reseting option bytes ... After loosing some hair and bricking a dozen STM32G0 a decided to change my architecure.

I now flash a simple USART bootloader that I developed at first boot since STM32G0 boots in internal bootloader when flash is empty, then I flash my main program using my own bootloader, and I never have to use the internal bootloader again in my product lifetime.