connectting J-link debugger has influence on I2C communication.

[ausera uirwaij]

I2C function always stucks at waiting for BTF flag if connectting STM32 with J-LINK debugger to start running program, however, the I2C can send command to slave device well when powered on without debuger control. I just call HAL_I2C_Master_Transmit_DMA to send two bytes command to slave device at main() function, the I2C will stuck when I click “run(F5)�? of keil without any breakpoint but it can send command successfully after powered off and on, and I'm using F429 MCU .

when start runing program in keil, SCL become low after calling HAL_I2C_Master_Transmit_DMA , I2C will stuck here:

 

when powered on, SCL & SDA all become high after calling HAL_I2C_Master_Transmit_DMA, it's normal :​

[not_cheater]

It seems I have the same issue. Have you fixed this yet? How?
Looking for any suggestions.:crying_face:

[not_cheater]

While I ran code in Debug mode or had RTT Viewer running, I2C dying quickly. I tested the same code without debug, it runs a whole weekend and running perfectly.

[not_cheater]

After my test, I think I2C may conflict with some interrupts (maybe System service call via SWI?), here is my reason:
1. I will enter_critical() by disable all interrupts, and i exit_critical() quickly. In this scenario, I2C may die after I2C_MEM_READ_DMA(), when I2C write to a register, and ready to read back.
2. when I use debug or RTT, I2C may die in same condition. 
3. after I use a lock-free fifo to avoid enter critical, I2C didn't die.
I'm totally confused:loudly_crying_face:. On one hand, STM32 is a common series and should not have this problem (I do know I2C in STM32 designed differently to avoid patents), moreover, this driver will definitely be used on RTOS, so it will inevitably enter the critical section. But on the other hand, I do bypass this issue by not enter critical section...
Maybe my environment issue? Maybe my debuger?:loudly_crying_face: Compiler?