Electronics > Microcontrollers

STM32F4 avoid I2C busy flag due to slave clock pulse

<< < (2/2)

Siwastaja:

--- Quote from: 3dgeo on August 14, 2022, 10:05:24 am ---I'm pretty sure reason of it is that I2C gets BUSY flag from assigning IO to it (IO state change detected), so any play with IO will give BUSY state

--- End quote ---

Remotely possible, but quite wild assumption. You should try it.

The fact HAL doesn't make it easy just shows where you are going wrong: you are using the HAL. When it works out of the box, it's great, but when it doesn't, working around it is a misery.

newbrain:

--- Quote from: 3dgeo on August 13, 2022, 11:36:57 pm ---Can you elaborate?
--- End quote ---
Using a HW buffer to isolate the MCU pin from the distributed SCL - so that the MCU will not "see" the pulse.
As said only works if clock stretching is not used (probable).

3dgeo:

--- Quote from: newbrain on August 14, 2022, 03:14:23 pm ---
--- Quote from: 3dgeo on August 13, 2022, 11:36:57 pm ---Can you elaborate?
--- End quote ---
Using a HW buffer to isolate the MCU pin from the distributed SCL - so that the MCU will not "see" the pulse.
As said only works if clock stretching is not used (probable).

--- End quote ---

You mean like transistor to isolate IC that generates INT? Adding any hardware due to this issue is even worse than bitbnging.
After few days of testing have to say bitbanging works, maybe not very elegant solution to get rid of those pusles, but after hardware IC2 takes over and everything works fine – added a picture to my main post.

Siwastaja:
Bitbanging I2C is fine. MCU I2C peripherals are notoriously buggy (and vary a lot between MCUs, even just product families of same MCU brand), and I2C is low-speed configuration bus, really, so speed doesn't usually matter. Write good bitbang implementation once and you will be able to use it in future projects, and get exactly what you need.

wek:

--- Quote from: Siwastaja on August 15, 2022, 09:01:47 am ---Bitbanging I2C is fine.

--- End quote ---
+1

--- Quote from: Siwastaja on August 15, 2022, 09:01:47 am --- MCU I2C peripherals are notoriously buggy

--- End quote ---
Yes, but I2C slave driving SCL blatantly violates the standard. So, who's the culprit here.

(Btw. I'd like to know what's the slave. According to the waveform in the OP, responding to several different addresses, so the I2C standard was interpreted very loosely by that particular vendor.)

But in this particular case, you can play along, too. Set the pin you use for SCL to throw an interrupt, and when that pulse is finished, reset the I2C module (either using its dedicated reset bit - it's there for a reason - or in RCC - yes, that dedicated reset bit is redundant), set it up as needed, conduct any communication needed, and then shut it down and wait for the next interrupt pin. Timeouts, recovery etc. in place as needed.

JW

Navigation

[0] Message Index

[*] Previous page

There was an error while thanking
Thanking...
Go to full version