Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

STM32L4 I2C NACK should be handled by I2C_EV #328

Closed
mikewolfram opened this issue Feb 21, 2020 · 3 comments · Fixed by #331
Closed

STM32L4 I2C NACK should be handled by I2C_EV #328

mikewolfram opened this issue Feb 21, 2020 · 3 comments · Fixed by #331

Comments

@mikewolfram
Copy link
Contributor

Current implementation is handling the NACK in the error interrupt, but in reality it is an event and should therefor be handled there:

image

I made a quick a dirty fix and copied the part from the I2C_ERR handler to I2C_EV handler right after checking for stop. Works now.
Since I'm not an I2C expert maybe you could tell me, if that's the right position and especially if that needs to be handled in the template file to change it for L4 only? With some advice I'll provide a fix.

@salkinium
Copy link
Member

Related to this #305. cc @nesos

@salkinium
Copy link
Member

The L4 template is the place to fix it, yes.

@mikewolfram
Copy link
Contributor Author

I had a look into #305 before. That one simply enables the NACK IRQ. On systems which use a global I2C interrupt handler this works fine. But if there are I2C_ERR and I2C_EV IRQ handlers this would simply not handle the NACK flag.

Looked into few reference manuals which I had on my disk. F3, F4, G4, L4 and F7 all tell, NACK is a I2C event. Still not clear to me is, which MCU have the global IRQ handler and which not. Beside the table in the first post some manuals use this graph:
image
Reading the table above could also mean, there are event and error interrupts as well as a global interrupt.

Anyway it looks to me the right place to handle NACK is the event IRQ handler. I'll prepare a PR and we can discuss whether the code is in the right place and does the right thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

2 participants