STM32F030F4P6 bootloader on PA2, PA3 possible?

[BAren.1]

I want to use hardware I2C (which is only available on pins PA9, PA10 on the STM32F030F4P6 in TSSOP20 case).

That overlaps with the standard pins used in the bootloader code for USART1_TX and USART1_RX (AN2606 Rev 55, page 50). The alternative pins used from bootloader are

PA14 and PA15. But that device don't have a PA15 pin!

I would expect, that the programmed bootloader use the existing pins PA2 and PA3

for second option USART1_TX and USART1_RX instead of PA14 and PA15.

Somebody already tried, if that (undocumented) PA2 and PA3 pins can be used with the bootloader?

I think, the connected I2C hardware on PA9 and PA10 can make trouble when

transfering USART protocol on SDA and SCL but I don't want to use bitbang I2C

or jumpers if possible.

Kind regards :)

[waclawek.jan]

Bootloader does not work on pins which are not documented in AN2606.

I2C is open collector and unless addressed, all connected devices leave the pins floating. If you intend to connect some UART transceiver (e.g. some USB-to-UART converter) only for the bootloading, it will work as push-pull and basically half-duplex, so there's zero risk of any connected I2C slave to "see" a valid slave address.

JW

[BAren.1]

Hello Jan,

thank you for your anwer. I2C is clear. Programmed bitbang I2C several times.

I don't know if the bootloader use a kind of half duplex or if there can be traffic on TxD and RxD simultaneously. If yes, I think there can be some conditions looks like I2C start - stop condition.

The chance to send a valid I2C address to a connected device is near zero but

I don't like such things which 'may' happens.

It's a reason for endless updates of different, unsafe operating systems ...

How do you know, that only documented ports in AN2606 will work?

To be honest, I expected that people who programmed a professional bootloader will not implement a

stupid USART port on PA14, PA15 if PA15 is not implemented on STM32F030F4P6 in the TSSOP20 package.

Especially not, when change only a few bytes to set the alternate function on a different port would solve the problem. Or they should make a notice, that PA14, PA15 is not usable on STM32F030F4P6

and don't try to initialize a non complete USART port.

Kind regards

Burkhard Arenfeld

[Tesla DeLorean]

The same die is used in multiple packages, a shrinking subset of pins are bonded out as those on the package dimish. Some of the 8 pin packages are bonded to multiple pads, leading to other headaches.​

[waclawek.jan]

Hi Burkhard,

The UART bootloader protocol is described in AN3155, so you can judge the "halfduplexity" of it yourself.

JW

[BAren.1]

Hello Jan,

thanks for your answers. I took a look in AN3155 and yes - looks like a BYTEbang protocol in half duplex.

Thank you for the hint. So for I2C devices it looks like a lot START STOP conditions on SDA or a lot SCL clocks. But not at the same time so nothing that should trigger an I2C device to get active.

I think it's OK to use bootloader and I2C parallel without problems. I'll try ;)

Will also test, if really USART on PA2, PA3 works...

BA