STM32F103 I2C peripherals 5V tolerant? - Page 1
Forum section: electronics / general

author: 3dgeo
author_rank: Frequent Contributor
timestamp: October 30, 2019, 05:05:48 pm
content: Howdy,I can run software I2C on STM32F103 @5V, but hardware is not working @5V or 3.3V, it worked before (testing with same code) but I can't remember if I used 3.3 or 5V pullups before, did I fried both hardware I2C? Logic analyzed gives no voltage drop on both I2Cs.

author: langwadt
author_rank: Super Contributor
timestamp: October 30, 2019, 05:46:37 pm
content: afair most of the pins on stm32 are 5V tolerant as long as you keep the pull-up turned off

author: 3dgeo
author_rank: Frequent Contributor
timestamp: October 30, 2019, 06:19:22 pm
content: I know that most IO are 5V tolerant, but IO not equal peripheral, my question is not if IO 5V tolerant, my question is is I2C peripheral 5V tolerant.I can't imagine other reason why hardware I2C does not work anymore with same code, default libraries but works with software I2C on same pins.

author: iMo
author_rank: Super Contributor
timestamp: October 30, 2019, 07:08:07 pm
content: When the SW I2C works and HW does not, it may not necessarily indicate a hw problem.Double-check your code, especially init.

author: 3dgeo
author_rank: Frequent Contributor
timestamp: October 30, 2019, 07:14:57 pm
content: I doubt it's code, I used 3 different versions from few cores that worked before... 2 of them are example codes that should work.

author: iMo
author_rank: Super Contributor
timestamp: October 30, 2019, 07:21:20 pm
content: The sw I2c and hw i2c is never the same code. It happened many times to me I had to go with sw I2C because hw I2C did not work because I created a mess..HW I2C could have set 1MHz clock, while SW I2C 100kHz. Also the pins or I2C number could have been set differently somewhere inside. Or HW and SW differs in messing with the I2C address. Etc.

author: janoc
author_rank: Super Contributor
timestamp: October 30, 2019, 07:47:31 pm
content: Quote from: imo on October 30, 2019, 07:21:20 pmEspecially on STM32F103 which has some well known issues with the I2C peripheral.Quote from: 3dgeo on October 30, 2019, 06:19:22 pmHow do you think the I2C peripheral is connected to the pin? Through the I/O block (which includes a multiplexer). So there is no input level for the peripheral, only for the pins.Pins which arenot5V tolerant are explicitly marked in the datasheet as such (there are only few, mostly the ones dealing with ADC inputs and clock/xtal inputs). As far as I can see from the datasheet, all I2C pins on STM32F103 are tagged as "FT", i.e. 5V tolerant, with the only exception being one SMBus related pin (which you don't need for I2C).I think you have most likely some bug in the code. I2C on STM32s is a complex beast with a lot of quirks and issues that are not obvious - such as that you must know that you are going to stop transmitting one byte ahead at least (i.e. you cannot set the stop bit during or after transmitting the last byte, that's too late!). You need to be careful how wide is your data access or you will transmit two bytes (one containing a zero or garbage) instead of one. Then the silicon bugs in the STM32F103 which could make the peripheral hang unless you are very careful with your code (e.g. it is strongly recommended to always use DMA to avoid most of the issues).And then the usual stuff common for all peripherals - turning on the power (to both I/O and I2C), enabling clock for both I/O & I2C, programming the correct alternate functions and then correctly initializing and enabling the I2C peripheral.

author: 3dgeo
author_rank: Frequent Contributor
timestamp: October 30, 2019, 08:16:06 pm
content: Yah, I tried with Arduino and official ST core and both peripherals seem to work, but I didn't change anything in my code since last time it worked, guessing some software update messed things up...

author: janoc
author_rank: Super Contributor
timestamp: October 30, 2019, 09:43:11 pm
content: Quote from: 3dgeo on October 30, 2019, 08:16:06 pmOhArduinoon STM32 ... OK, that explains a few things.Don't you think that's a kinda important piece of context to provide when you are asking why something isn't working?E.g. STM32 has at least 4 common frameworks/SDKs that are being used:- Standard peripheral libraries (or "stdperiph") (the old style vendor SDK)- CubeMX/HAL (the new style vendor SDK)- mBed- Arduino - and there are several "cores" for it.Then there is also libopencm3, ChibiOS, etc. Plus you can always use direct register access, e.g. with CMSIS. Each of these has its own bugs and issues. How are we supposed to know what are you doing?

author: 3dgeo
author_rank: Frequent Contributor
timestamp: October 30, 2019, 10:40:50 pm
content: As I said, I used same exact code that I used before that worked, so I didn't expect software to be an issue...It's so frustrating to spend few days troubleshooting to find out that updates messes things up... I'm never updating again

author: jackthomson41
author_rank: Regular Contributor
timestamp: October 31, 2019, 01:26:57 am
content: Quote from: 3dgeo on October 30, 2019, 10:40:50 pmYeah it happens a lot, I think you are having a problem with any library which is not compatible with theSTM32upgrade. So, you have to try your code step by step and find out which one (piece of code) is not working.

author: ozcar
author_rank: Frequent Contributor
timestamp: October 31, 2019, 03:06:16 am
content: Quote from: janoc on October 30, 2019, 07:47:31 pmI certainly had problems with the STM32CubeMX-generated HAL code. I2C1 would sometimes get hung in "busy" state as indicated by flag in SR2, and my I2C code, based on what I found others had done to handle serial LCDs and AT24 eeproms did not react well to the resulting HAL error codes. I'm not sure how you could handle this problem anyway, as I could not find any obvious way to get the HAL code to clear the busy state. Even calling the I2C initialisation code again did not help, unless I first cleared the “busy” state with xxx->Instance->CR1 |= I2C_CR1_SWRST .In the end I found an old discussion on electronics.stackexchange.com, where it was noted that HAL_I2C_MspInit sets up the GPIOs before enabling the I2C peripheral clock, and it said that the problem did not appear to happen if the order of those was reversed. I tried that, and it did work for me. I left my code to clear the “busy” state in place, but when debugging, that code was never entered any more.

author: 3dgeo
author_rank: Frequent Contributor
timestamp: October 31, 2019, 02:48:33 pm
content: Well, at least scanner works now, if I try to send data to those chips but they do nothing, tho it might be other stuff...It's kinda funny, when picking faster MCU for my project I picked STM32F103, but due to amount of work I would have to put in to make it work I thought I rather go with SAMD21 chips that are more expensive, way slower and freaking programmer costs 150buks. After investing time and money trying to make SAMD21 to work I realized that it's same amount of work as making STM32F103 to work, so here I'mI know this isn't relevant, but I had to let it out of my system – SAM21 sucksWith that said – anyone need 30 SAMD21 chips and Atmel ICE?OK, I'm done now

author: janoc
author_rank: Super Contributor
timestamp: October 31, 2019, 07:37:40 pm
content: Why did you pick STM32F103? That's the first generation of Cortex M3 chips from ST Micro and they have a lot of known issues. A much better choice for new projects are either STM32F0 series or e.g. STM32F4 series. The prices are about the same for comparable parts.Of course, if you are buying by what you can find cheaply on AliExpress and/or what Arduino runs on, that's a different story - but then you get trouble (especially given the amount of dodgy STM32F103 chips being sold in some of the "Bluepill" clones). Arduino's Wiring library that is used for I2C is dodgy and has plenty of issues even on ATMegas that it was originally developed for.

author: janoc
author_rank: Super Contributor
timestamp: October 31, 2019, 07:41:21 pm
content: Quote from: ozcar on October 31, 2019, 03:06:16 amYou will want to check the errata for the MCU. This sort of hang reminds me very much of the well known STM32F103 I2C bug. There are some workarounds (such as using DMA) for it. And, well, both HAL and StdPeriph are not exactly known for being bug-free - it often helps to check what those functions actually set in the registers. I had a bug where one bit didn't get initialized and the peripheral simply didn't work at all with the official example code(which is of no help to the OP because he is using Arduino ...)

author: 3dgeo
author_rank: Frequent Contributor
timestamp: October 31, 2019, 08:29:47 pm
content: I'm using DMA. I made it work, both I2C and many chips on them seems to be working just fine.I will buy chips fromLCSC. Almost 230K in stock, I really doubt they are selling not genuine chips.I picked STM32F103 over SAMD21 – even with default recommended hardware configuration chip just refused to reset when reset pin went low, I had really hard time uploading using its USB and it was too "weak" and expensive. Chips are from Digikey. And the 150 programmer was a cherry on top...Well, ok, most of the time if something was not working I'm the idiot to blame, but with the SAMD21 I was way more often an idiot than with STM32 chipSTM32 just works for me, even cheap clones from ali, I got both I2C to work at the same time, no glitches, nothing.STM32F0 chips too "weak", I need 72mhz STM32F1 offers, STM32F4 too expensive, too big.I'm only now using Arduino just to figure out hardware, after I will dive deep and write my own code, bootloader from scratch.Have any known issues with STM32F103 USB? Two things that important to me – reliable USB HID and both I2C peripherals.Fun fact – I made a PCB of my product with SAMD21, but I had no luck making it work. I soldered jump wires and connected it to blue pill and it just works... Man I'm salty on SAMD

author: jhpadjustable
author_rank: Frequent Contributor
timestamp: October 31, 2019, 09:25:20 pm
content: Quote from: 3dgeo on October 31, 2019, 08:29:47 pmWhy would you do that when there is a perfectly serviceable multi-port bootloader built into the system ROM, well-supported by open source software? Especially in the post-F103 models, where you also get a USB DFU class device. You only need to pull BOOT0 high at reset for the magic to happen. If you don't mind paying extra, there are vendors that purport to offer a bluepill board with an F072 on it, which does have all that magic and more. Or, you can save a bit by breaking out the hot air tool and swapping the chips yourself.QuoteThe only USB-related erratum is an odd case related to a slow APB1 bus clock, which is easily avoided. I've never had any problems with USB on it.On the other hand, there are six pages of errata for the I2C peripheral.In my relatively undemanding applications I haven't personally had trouble with the I2C in 400kHz fast mode using HAL. Maybe HAL works around the silicon errata. Dunno.libopencm3 is worth a look, especially if you want to figure out hardware rather than arduino.

author: techman-001
author_rank: Frequent Contributor
timestamp: October 31, 2019, 10:03:09 pm
content: Quote from: 3dgeo on October 31, 2019, 08:29:47 pmUSB shares memory with the CANBUS hardware, which means that USB and CAN cannot be enabled at the same time.

author: 3dgeo
author_rank: Frequent Contributor
timestamp: October 31, 2019, 11:09:01 pm
content: Product will use USB communication, also I want that "driver software" would be able to update firmware with no user input.I noticed you are using fancy words – don't, I'm not there yetI'll deal with the software side when I'll have solid hardware combination. For now Arduino is enough, I made ruff code that works with it. In the worst case scenario I even could swap MCU itself, for now MCU isn't an issue and hopefully will not become one