Skip to main content
NRoos.1348
NRoos.1348
Associate II
November 18, 2019
Solved

I2C interrupt not triggered

  • November 18, 2019
  • 3 replies
  • 2255 views

I'm running out of ideas, there is no interrupt triggered when sending data over I2C.

Processor: STM32L451

Middleware: FreeRTOS

I2C interrupts are enabled in STMCubeMx, also pins are configured for I2C.

Sending data with HAL_I2C_Master_Transmit_IT():

CR1: PE, TXIE, NACKIE, STOPIE, TCIE, ERRIE are enabled

ISR: BUSY, TXIS, TXE are set

Handlers for all I2C interfaces (event and error) are placed in the interrupt vector table in startup_stm32l451vetx.s

Directly in these handlers i put a breakpoint and additionally turned on a debug LED, but neither the breakpoint is reached nor the LED is turned on.

I tried it with all 4 I2C interfaces, none triggers an interrupt.

On the I2C line, i can see the first byte is sent and acknowledged by the receiver; the ACK also disappears after one clock, so the I2C interface obviously has received the ACK.

Tried it with another board as well, to no success.

Sending data with HAL_I2C_Master_Transmit() (not interrupt driven) works fine.

Then i enabled the debug LED in the timer interrupt, this is working, so interrupts are not generally disabled.

Has someone an idea what else i could check?

This topic has been closed for replies.
Best answer by NRoos.1348

Ok, seems to be a mistake on my side: I did the I2C transactions before osKernelStart() was called. After i put them into the default task, the interrupts are coming trough.

It's not a real answer to why the interrupts were still blocked when they were enabled and pending, but now as it works i won't investigate it any further.

3 replies

ARash
ARash
Associate II
November 18, 2019

I have the similar problem. Seems like there is something wrong with API. If you do polling based API and DMA based I2C read and writes, no problem.

Also the problem appeared in 7 bit addressing mod. 10 bit addressing mod work fine for me.

NRoos.1348
NRoos.1348Author
Associate II
November 18, 2019

Update: One thing is, It seems the code is not generated properly. Although i selected "Generate" from the menu, the I2C initialization was missing. In the MX editor i deselected the I2C interrupts, generated code, then enabled the I2C interrupts in the editor again, regenerated, and this time the I2C initialization was generated.

But still it's not working.

When writing the question, i didn't know the interrupts are passed through an interrupt controller, the NVIC. In the debugger, i can see:

ISER / ICER: I2C interrupts are enabled (i guess the clear register shows the same as the set register)

ISPR / ICPR: My interrupt is pending (corresponding bit is set)

IABR: My interrupt is not active

Priority is 5.

Are there some more modules where the interrupt request must go through before it finally becomes active?

NRoos.1348
NRoos.1348AuthorBest answer
Associate II
November 19, 2019

Ok, seems to be a mistake on my side: I did the I2C transactions before osKernelStart() was called. After i put them into the default task, the interrupts are coming trough.

It's not a real answer to why the interrupts were still blocked when they were enabled and pending, but now as it works i won't investigate it any further.

Terms & ConditionsAccessibility statement