STM32F4 as I2C Slave getting BERR on with specific Master device.

mr4k · ‎2025-03-05

Hello, I'm writing this in hope I can successfully resolve my issue with getting BERR on every I2C call, when connected with specific master device.

I have implemented slave device using STM32F4 discovery board using HAL I2C drivers and IT functions.
For ease of testing I have also implemented master device on Arduino MKRZero. Based on available documentation of MKRZero, it comes without pull-ups placed on PCB so I have added it as shown in the picture below.

I have tried with 1k Ohm and 3k3 Ohm resistors on SDA&SCL line and in both cases communication worked.
Below is picture with 1k Ohm resistors.

MKRZero (Master), STM32F4 (slave), 1kOhm pull-ups

After implementing all functionalities on STM32F4 slave device I wanted to move forward and test the implementation with real world master device, that will be CubeOrange. This device also uses STM32 mcu (STM32H753VI), running nuttix real-time OS.

Based on schematics, CubeOrange already have 1k8 Ohm pull-ups placed, so I have connected SCL/SDA lines directly. Connection schematics and results are shown below. In neither of those cases the communication with CubeOrange was successful. I get BERR before it even enter any of the interrupt functions defined in HAL I2C driver.

CubeOrange(Master), STM32F4(Slave), 1k8 Ohm internal pull-ups, R1 = inf Ohm, Rn = 1k8 Ohm

CubeOrange(Master), STM32F4(Slave), R1 = 1k Ohm, Rn = 643 Ohm

CubeOrange(Master), STM32F4(Slave), R1 = 3k3 Ohm, Rn = 1k2 Ohm

I would say there is something wrong on the bus, but what and how to resolve it - this is beyond me right now.
Did anyone else come across similar issues? How to tackle it?

My STM32 slave I2C pin setup is following:

and all interrupts are having same priority levels(pre and sub are both 0, setting max priority for all interrupts).

Thanks for help in advice!

Andrew Neil · ‎2025-03-05

@mr4k wrote:
real world master device, that will be CubeOrange

You mean this: https://cubepilot.org/#/home ?

Have you tried contacting them for support: https://discuss.cubepilot.org/ ?

Does it work with some standard I2C Slave(s) ?

@mr4k wrote:

0-ohm pullups will certainly not work - that's just shorting the lines to the 3V ref!

@mr4k wrote:
getting BERR on every I2C call

Have you looked-up what that error means?

Have you used the debugger to see where & why, exactly, it is being generated?

mr4k · ‎2025-03-05

Andrew, thanks for response.
Yes, I mean CubePilot, more specific CubePilot CubeOrange.
With other slave devices CubeOrange works well, and same goes for STM32F4.

With 0-ohm, what I meant was there is no additional resistors on the SDA/SCL line, therefore no connection to 3V ref.
As mentioned in my OP, CubeOrange should have internal pull-ups present inside the cube, therefore the

BERR indicates that there is probably something wrong with/on the BUS.

I did use debugger to see where & why this error is generated, but I could not find the reason.
As said, the error is generated before AddrCallback is even triggered.
Needless to say, I'm trying to figure it out more but at this time, this is all I have.

Andrew Neil · ‎2025-03-05

@mr4k wrote:
With 0-ohm, what I meant was there is no additional resistors .

That would be an infinite resistance - not a zero resistance!

@mr4k wrote:
BERR indicates that there is probably something wrong with/on the BUS..

The Reference Manual gives you more specific detail; eg,

mr4k · ‎2025-03-05

@Andrew Neil wrote:
@mr4k wrote:
With 0-ohm, what I meant was there is no additional resistors .
That would be an infinite resistance - not a zero resistance!

You are absolutely right. I have updated OP with correct information / better wording.

@mr4k wrote:
BERR indicates that there is probably something wrong with/on the BUS..
The Reference Manual gives you more specific detail; eg,

Sure, documentation is our friend. However I do not see misplaced Start or Stop condition or am I missing something? I tried to investigate the situation further using debugger but could not find anything useful at this point.
So I'm still lost how to tackle the issue further.

Andrew Neil · ‎2025-03-05

@mr4k wrote:
I have updated OP with correct information / better wording.

Best not to update a post when it's already had replies - as that makes a nonsense of the existing replies