May 06, 2021
12:48 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 06, 2021
12:48 AM
I have written a test program with DAVE 4 that uses I2C interfaces on an XMC4500.
When there are no problems with the hardware, everything works correctly, but if the hardware has a problem (pull-up missing for example) the program hangs.
I use the I2C_MASTER_Transmit() function to send the data and then wait until it is not busy, using I2C_MASTER_IsTxBusy(). In the case of a bus error, it just remains busy for ever! I have tried looking at the status but I cannot find any status that shows this error.
How can I write a robust program that works with hardware errors? There must be some way to detect this situation and deal with it in the software. Which bit of which register do I need to look at?
When there are no problems with the hardware, everything works correctly, but if the hardware has a problem (pull-up missing for example) the program hangs.
I use the I2C_MASTER_Transmit() function to send the data and then wait until it is not busy, using I2C_MASTER_IsTxBusy(). In the case of a bus error, it just remains busy for ever! I have tried looking at the status but I cannot find any status that shows this error.
How can I write a robust program that works with hardware errors? There must be some way to detect this situation and deal with it in the software. Which bit of which register do I need to look at?
Solved! Go to Solution.
- Tags:
- i2c master
- IFX
1 Solution
Attachments are accessible only for community members.
May 21, 2021
06:05 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 21, 2021
06:05 AM
No, you are definitely not.
We had similar problems, most of them originating from noise on the line generated by an external power supply, which made the I2C connection stall. To work around it, we added two things
1. Do not wait forever to read / write, but instead define a timeout and return from the method in case of a timeout.
2. Let the enclosing software layer handle too many timeouts by resetting the I2C communication completely.
Attached you'll find a simple example for interfacing the TMP275 temperature sensor. It is not complete, but probably not too hard to understand.
Best regards,
Ernie
We had similar problems, most of them originating from noise on the line generated by an external power supply, which made the I2C connection stall. To work around it, we added two things
1. Do not wait forever to read / write, but instead define a timeout and return from the method in case of a timeout.
2. Let the enclosing software layer handle too many timeouts by resetting the I2C communication completely.
Attached you'll find a simple example for interfacing the TMP275 temperature sensor. It is not complete, but probably not too hard to understand.
Best regards,
Ernie
5 Replies
May 12, 2021
04:29 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 12, 2021
04:29 AM
Am I the only person using I2C?
How can I write a robust program? I need to know if the bus is blocked, or the transmit is not finished.
How can I write a robust program? I need to know if the bus is blocked, or the transmit is not finished.
Attachments are accessible only for community members.
May 21, 2021
06:05 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 21, 2021
06:05 AM
No, you are definitely not.
We had similar problems, most of them originating from noise on the line generated by an external power supply, which made the I2C connection stall. To work around it, we added two things
1. Do not wait forever to read / write, but instead define a timeout and return from the method in case of a timeout.
2. Let the enclosing software layer handle too many timeouts by resetting the I2C communication completely.
Attached you'll find a simple example for interfacing the TMP275 temperature sensor. It is not complete, but probably not too hard to understand.
Best regards,
Ernie
We had similar problems, most of them originating from noise on the line generated by an external power supply, which made the I2C connection stall. To work around it, we added two things
1. Do not wait forever to read / write, but instead define a timeout and return from the method in case of a timeout.
2. Let the enclosing software layer handle too many timeouts by resetting the I2C communication completely.
Attached you'll find a simple example for interfacing the TMP275 temperature sensor. It is not complete, but probably not too hard to understand.
Best regards,
Ernie
Jun 24, 2021
09:11 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 24, 2021
09:11 AM
Turn off FIFOs with I2C.
What I’ve found while testing here on my board is that the unit will hang (and reset via the WDT), even with no communications activity or anything. If so, a solution to that seems to be to disable the FIFO’s for the I2C app. In the I2C ISR there is a potentially infinite loop in the generated code where it waits for the FIFO to be empty (if FIFO mode is enabled). Why it gets to the point where it fails to ever pass- I don’t know. I can look at that in more detail if you want, but if this is the problem you see then disabling the FIFO’s is probably the most straightforward solution.
What I’ve found while testing here on my board is that the unit will hang (and reset via the WDT), even with no communications activity or anything. If so, a solution to that seems to be to disable the FIFO’s for the I2C app. In the I2C ISR there is a potentially infinite loop in the generated code where it waits for the FIFO to be empty (if FIFO mode is enabled). Why it gets to the point where it fails to ever pass- I don’t know. I can look at that in more detail if you want, but if this is the problem you see then disabling the FIFO’s is probably the most straightforward solution.
Jun 24, 2021
11:57 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 24, 2021
11:57 PM
I do not know if this is your problem, but I know there is/was a bug in the XMClib function to set the RX FIFO trigger level. The TX trigger level get changed as well.
I cannot remember all the details, but I think the FIFO was disabled before changing the limit. Reading the reference manual makes it seem necessary to disable the FIFO first, but this is not the case and causes the side effect. I copied the XMClib function and removed the disable and had no more problems.
I cannot remember all the details, but I think the FIFO was disabled before changing the limit. Reading the reference manual makes it seem necessary to disable the FIFO first, but this is not the case and causes the side effect. I copied the XMClib function and removed the disable and had no more problems.
Jul 07, 2021
08:21 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 07, 2021
08:21 AM
I generally use Dave apps. Then modify from there as needed.
I'm use FreeRTOS too.
I was getting random crashes that where very hard to track down. When I turned off I2C FIFOs, the random crashes went away.
Also, I use 1 task - 1 hardware entity. I don't use multiple tasks access same hardware and using mutex to control access.
I'm use FreeRTOS too.
I was getting random crashes that where very hard to track down. When I turned off I2C FIFOs, the random crashes went away.
Also, I use 1 task - 1 hardware entity. I don't use multiple tasks access same hardware and using mutex to control access.