Why do subsequent I2C reads not work ??

[lpcware]

Content originally posted in LPCWare by Wenzu on Mon Mar 21 05:09:03 MST 2011
I'm reading interrupt driven and interrupt triggered I2C data from a sensor with I2C0 'master' on an LPCXpresso1769 @120Mhz.

As long as I'm reading the same sensor, data comes in fine.
However when I try to read the second sensor on the same I2C bus, the data of the [U]first sensor[/U] read gets garbled up, and only the data from the [U]last called[/U] I2C read appears correct.

I have tried a couple of examples, including the one from this thread:
http://knowledgebase.nxp.trimm.net/showthread.php?t=1636

I've also tried flagging when the I2C read ends( case 0x58: in the ISR), zeroing all buffers after this flag ( about 5uS 'lost' in this loop) and then reading from the second sensor, again, with no success.

What's the trick ??

I am also noticing that:

#define MAX_TIMEOUT         0x00FFFFFF

acts purely as a delay on the initial clocking !!!

I am reading at 400KHz clock, and my timeout has to be

#define MAX_TIMEOUT         0x00000001F

for reliable clocking out of data, without system hanging.

Changed also Pullup resistors to a selection of 2k2, 4k7, 10K.

Quite lost !!! :eek::eek:

[lpcware]

Content originally posted in LPCWare by renan on Thu May 03 19:53:20 MST 2012
Wenzu, do you still  have the code you post in the beginning of this thread?

Thanks,
Renan

[lpcware]

Content originally posted in LPCWare by jherrera8 on Tue Oct 11 14:36:24 MST 2011
Ok, so I know this thread was a while ago, but I am trying to do the same thing. I have a very similar IMU from SparkFun. Did you ever get this working? I would be very interested in seeing your code for this.:)

Thanks,
J

[lpcware]

Content originally posted in LPCWare by Wenzu on Tue Mar 22 14:32:57 MST 2011
Larry, Im trying to make my first steps to read an IMU3000 and ADXL345 combo as sold by sparkfun.
However..... my status till now....
1) Free I2C on the main loop works. If I do a sprintf, to see data, I get a 5-8ms break in the comms to the sensors. But, one would want to read the sensors fulltime, almost continuously.
2) I've tried GPIO / ExtInt / Timer / PWM interrupts to read the I2C bus at intervals, but all reliably fails.
3) It even fails if I bring the interrupt handler in the main.c file and not leave it external in an #include.( just trying !!)
4) the only way I could [U]manually[/U] trigger a read, is if I put the I2C read in the main loop, under control of UART trigger when I send any character. So I know that a trigger actually works.

So next step is... how to make this automatic, continuous, and give reliable results without freezing or giving incorrect readings.

:confused:

[lpcware]

Content originally posted in LPCWare by larryvc on Tue Mar 22 14:15:56 MST 2011

---

Quote: Wenzu
I'm reading interrupt driven and interrupt triggered I2C data from a sensor with I2C0 'master' on an LPCXpresso1769 @120Mhz.

---

Contrary to what everybody thinks I am not psychic, well maybe a little.:)

Sensor?  If it's proprietary you don't need to answer.

[lpcware]

Content originally posted in LPCWare by Wenzu on Tue Mar 22 14:02:59 MST 2011
Magical ??

Magical if I manage to learn what interrupt pending clear, masks, etc and what they're used for.

As for sensors....Larry, my guess is that you already know ;)

[lpcware]

Content originally posted in LPCWare by larryvc on Tue Mar 22 13:53:01 MST 2011
Hi Wenzu,

I am mainly interested in the sensors that you are using and thought you were coming up with something magical.:)

I think Dr. Zero is a fitting title.  He certainly deserves it.:)

Is this why we have Public and Private?

"Many things, having full reference
To one consent, may work contrariously"
William Shakespeare
King Henry V

[lpcware]

Content originally posted in LPCWare by Wenzu on Tue Mar 22 13:22:01 MST 2011
Hi Larry,

The I2C code I was experimenting with is exactly the one that was posted in the previous link. When I stripped down everything else to post, it came almost exactly to the zipped file, except the registers I added for accessing the data.

After Zero's [I]pointer[/I] , and also, as I was stripping down the code for posting, subsequent reads immediately worked ( topic name redundant ?? ;), whenever I was reading I2C freely, and not according to the data ready interrupt coming out from this device.

I am still not successful in achieving what I want, but that's because I'm a [I]( [/I]somewhat [I]courageous[/I] ;) nooob.
Re-reading the UM is helping, as well as learning how to control interrupt priorities.

So, now that I confirmed that the quoted example works, and learned/identified/visualized where all ISR's are happening in the I2C example, I need to spend some more sleepless nights trying to figure out what I need to tailor in my use to be able to have successful interrupt reading without any interference from other parts of the code.
I don't know if an RTOS is the solution, but as I really have thirst to learn keen coding, I want to still pursue this challenge. :eek:

[lpcware]

Content originally posted in LPCWare by larryvc on Tue Mar 22 12:23:25 MST 2011

---

Quote: Wenzu
Ok.. let me edit it to make it readable and slightly more presentable,and I'll post it. :D

---

Have you forgotten?:)

[lpcware]

Content originally posted in LPCWare by Wenzu on Mon Mar 21 13:35:27 MST 2011
It's a good thing that I told the 'doctor' everything I was feeling, and also gave [I]pointers[/I] as to what was seeming very strange to me...(max_timeout)

Speaking about courage, and pointers...

That is all I needed. Thanks Zero for [I]pointing [/I]it out.
You just 'fkn' ;) hit the nail on the head !!:DLOL:D!!

Quick test:
Calling and reading the I2C bus 'freely' from the main loop, the outputs from all devices sharing the bus are working fine and giving correct results. What [U]wa[/U]s happening to the I2C ISR was that  I2CMasterState was never going above 0x100 due to the [U]timeout [/U]being too narrow. Therefore I2CEngine never 'recovered'.

However, now that at least I know that 'free run' read works from all sensors, I started to read again from the interrupt trigger that the first I2C device gives me... the data ready interrupt.
However in this case, as soon as the trigger occurs and the I2C read is called, the timeout on startup just 'pulse stretches' beyond the next ISR trigger that calls again to read a fresh set of values = brainfreeze.

This is absolutely the reason why I shortened the timeout in the first place.
A single read was working well, but when I changed the address to read another device, the read of the first device was cut short ( no timeout  to give chance ) and the next call was made.

Once again, thanks Dr.Zero.
Was this a good prognosis ??

Now off to understand [I]why[/I] this is happening. Do you have another [I]pointer[/I], Doc ??
:D

[lpcware]

Content originally posted in LPCWare by larryvc on Mon Mar 21 09:39:53 MST 2011

---

Quote:
That's courageous :)

---

Zero without your terrific sense of humor this forum would be very boring.:)

Did William Shakespeare know about pointers?

[I]By indirections find directions out.  Hamlet.[/I]

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Mon Mar 21 09:22:10 MST 2011

---

Quote: Wenzu
I am also noticing that:

#define MAX_TIMEOUT         0x00FFFFFF

acts purely as a delay on the initial clocking !!!

I am reading at 400KHz clock, and my timeout has to be

#define MAX_TIMEOUT         0x00000001F

for reliable clocking out of data, without system hanging.

Quite lost !!!

---

:confused::confused: That's no delay, that's TIMEOUT. It's used to get out of a loop while waiting for something. You've allowed your I2C code to break waiting for I2C data. That's courageous

[lpcware]

Content originally posted in LPCWare by Wenzu on Mon Mar 21 09:12:44 MST 2011
Ok.. let me edit it to make it readable and slightly more presentable,and I'll post it. :D

[lpcware]

Content originally posted in LPCWare by larryvc on Mon Mar 21 08:50:45 MST 2011
Can you post your code?