I need some help regarding a project we are working on.

[TAwas.1]

we are currently using the STM32 F091RC 2019 chips , and due to the chip shortage we are using the 2011 ones of the same chip, 

The issue is on the 2019 chips the I2C, USART are working fine, but on the 2011 ones the I2C is not working are there any changes in the bootloader versions of the chips.

The USART3 is used for Bluetooth which works perfectly on the 2019 ones but not the 2011 ones.

The I2C is being used for writing the firmware and the USART for Bluetooth.

[TDK]

You can query the bootloader using the get version command to find out if they're different. You could also connect with STM32CubeProgrammer and check that the contents of system memory are identical.

8 Kbyte starting from address 0x1FFFD800, contain the bootloader firmware.

[TAwas.1]

Is there a difference in the bootloader on the 2011 chips as compared to the 2019 chips which may cause this issue

[TDK]

I doubt it.

[Georgy Moshkin]

I would first check I2C and USART with a scope. If there is source code available, then debug it. Without source maybe compare ram, flash and registers between two boards using st-link utility. You can take two boards, use CubeIDE to make simple firmware: one board is I2C master, the other one is I2C slave, put wires between boards and check what's going on with I2C. In most cases it is firmware problem, or PCB design flaw. Try search for "STM32 F091RC errata", for example this one:

https://www.st.com/resource/en/errata_sheet/dm00134745-stm32f091xbxc-device-errata-stmicroelectronics.pdf

"2.11.1 10-bit master mode: new transfer cannot be launched if first part of the address is not acknowledged by the slave" and some other notes.

[TAwas.1]

We configured the I2C via software but not able to configure bootloader using I2C, if using UART its shows the chip ID and bootloader version but when using I2C its just shows 0

[TAwas.1]

We are connecting a bluetooth module on USART3, on the 2019 chips it is working fine but on the 2011 chips they are not

[Georgy Moshkin]

I meant making a test firmware, check if I2C pins can function in non-bootloader mode. Have you tried bootloader over I2C for a fully erased MCU?

If I understood correctly,

1. I2C is not working with embedded bootloader?
2. USART3 not working with Bluetooth module?

Re-check everything step by step, any differences, even option bytes. Maybe you have some changes in other hardware, for example external crystal.

Check documentation on I2C boot sequence. Use serial port monitor, etc.

If you have access to firmware, you can send register values and each function output to terminal, check all HAL_OKs and/or register state, or debug with a breakpoint. You can do it on both boards: working and one with the problem. Then compare registers state right before you going to use I2C.

For personalized problem solving you can contact me directly by email in my profile.

[TAwas.1]

Hello sir, I got a solution to the USART issue i have to physically connect the Tx pin to GND for a second to get it started is there a way of doing it in the code for just fulling the TX pin to gnd , i tried the HAL reset but did not work

[Georgy Moshkin]

Maybe your code have some flaws that need to be fixed. Where does it stuck before pulling Tx pin to GND? I can't imagine it stuck in MX_USART1_UART_Init or something like HAL_UART_Receive_DMA, more likely some blocking function call, and it unstuck after receiving one or two bytes after you shorted TX pin. Or you meant that internal bootloader starts to work? Or it is required by Bluetooth module to start? Without source code and other details it is difficult to say. You can solder thin wire from adjacent pin to Tx pin, configure it as GPIO output of one second, then as GPIO input. Or you can send 0x00 or 0xFF at low baud rate to make this pin output 0v or 3.3v for small period of time.