Strange I2C behaviour

[hippicurean]

Hi there,

I'm using an OS for the NXT called nxtOSEK, which depends on leJOS drivers (rather antiquated ones) for its I2C interface. I've recently encountered an odd behaviour using a microcontroller to transmit data to the NXT. If I set all the data on the microcontroller to have constant values of 127, they are transmitted without a hitch to the NXT and then to the PC. The status flag counters in the interrupt service routine on the microcontroller corroborates the successful data transfer. If one of the bytes has a value greater than 127, that byte and all others that follow will not be transmitted. The only exception is when it's the first byte that exceeds a value of 127. In this case, data transmission proceeds as normal.

Here a sample output from my AVR microcontroller. The first byte is a constant value of 128 while the remaining seven contain identical values of 127. The NXT requests for eight bytes at a go, and transmits the received data to the PC via USB. As can be seen here, the transmission goes smoothly.
Data: 128 127 127 127 127 127 127 127
Data: 128 127 127 127 127 127 127 127
Data: 128 127 127 127 127 127 127 127
Data: 128 127 127 127 127 127 127 127
Data: 128 127 127 127 127 127 127 127

Now, if another other byte (fifth in this case) were assigned a value of 128 or larger, and all other bytes are set to 127 or smaller, that particular byte and all others that follow will fail to be transmitted nearly all the time. The status flag counters in the microcontroller's interrupt service routine confirms the large number of bytes dropped in transmission. I've tried sending just two bytes, and the results are the same. At first glance, the numbers involved suggest a type problem. But it doesn't affect the first byte and occasionally all data will get through.
Data: 127 127 127 127 255 255 255 255
Data: 127 127 127 127 255 255 255 255
Data: 127 127 127 127 255 255 255 255
Data: 127 127 127 127 255 255 255 255
Data: 127 127 127 127 255 255 255 255
Data: 127 127 127 127 255 255 255 255
Data: 127 127 127 127 255 255 255 255
Data: 127 127 127 127 128 127 127 127 // Note!
Data: 127 127 127 127 255 255 255 255
Data: 127 127 127 127 255 255 255 255
Data: 127 127 127 127 255 255 255 255
Data: 127 127 127 127 255 255 255 255
Data: 127 127 127 127 255 255 255 255
Data: 127 127 127 127 255 255 255 255
Data: 127 127 127 127 255 255 255 255
Data: 127 127 127 127 128 127 127 127 // Note!
Data: 127 127 127 127 255 255 255 255
Data: 127 127 127 127 255 255 255 255
Data: 127 127 127 127 255 255 255 255
Data: 127 127 127 127 255 255 255 255
Data: 127 127 127 127 255 255 255 255

Since the I2C driver dates from 2008, I'm sure it contains some bugs. However, I can't find any mention of this particular issue at the Sourceforge repository. I was wondering whether anyone else here has experienced or has any recollection of this problem. Unfortunately, I can't simply update the leJOS drivers because of how nxtOSEK is structured. And I have given up emailing queries to the nxtOSEK developer because he barely ever responds. Since the I2C driver is directly borrowed form leJOS, I thought this would be the best place to pose this question. Thanks.

Cheers
Hippie

[skoehler]

nxtOSEK is pretty much unsupported.

[hippicurean]

nxtOSEK is pretty much unsupported.

Sven, I realised this to my dismay only after I've invested a couple years of work in Matlab/Simulink which requires nxtOSEK as the OS for the NXT. So, I'm stuck in a rather desperate situation. However, I'm not requesting for support for nxtOSEK. I was just asking whether the problem that I mentioned has ever been reported by leJOS users. If it has never been a leJOS issue, I can then narrow down my search for the problem within nxtOSEK. I'm just appealing for a tiny bit of help here; so if you could, I'd be most grateful. Thanks.

Cheers
Hippie

[gloomyandy]

Hi,
I've been looking after the leJOS i2c code for a number of years now and have pretty much re-written it over that time. Sorry to report that I've never seen the problem you are reporting. Nor can I think of any reason why you are seeing these rather strange results. The code you have is now very, very old and I can't really remember much about it (one of the first things I did on the leJOS firmware was to re-work this code, mainly to fix problems with using port 4). To be honest if it was me I would try very hard to update to a more recent version of the leJOS driver (or just dump nxtOSEK, but I appreciate that may not be possible).

If you have access to a dual trace scope you may be able to work out what is going on... I suspect that this is some sort of timing issue with the first bit in a byte. You are probably not seeing a problem with the first byte due to the extra operations (including I think a delay), that are used prior to receiving that byte but not performed for subsequent bytes. I would take a hard look at the code that ends a byte (and sends an acknowledgement) and how this than transitions to the next byte to ensure that the timing and state of the data pin is set correctly.

One possible but probably slow option that may work for you would be to read the bytes as single byte reads rather than multiple bytes incrementing the register address yourself rather than using the multi-byte read capability. But this may not be possible with all sensor...

I'm sorry but I don't have the time time to go back and look at this code at the moment due to other commitments...

Good luck

Andy

[hippicurean]

Hi Andy,

The continued use of antiquated leJOS drivers is why I would dump nxtOSEK if I could. However, nxtOSEK is the only OS that works with Simulink. Unfortunately, my limited programming abilities prevents me from updating the leJOS drivers on my own. The library blocks in Simulink call on functions that have different names or no longer exist in the latest I2C drivers. To reconcile the two is a challenging task in itself. Not only that, I have no idea how it all ties in with the Toppers/OSEK operating system that is part of nxtOSEK. The developer told me in one of his rare replies that it's a lot of work and he just doesn't have the time to do it.

While I was waiting for an answer on this forum, I came up with a rather inelegant but workable hack. The eight bytes from the microcontroller actually contains four blocks of 16-bit data. Each block is split into lower and upper bytes. Since the value of the data contained in each 16-bit block never goes beyond 12,000, I can shift seven bits at a time and not encounter any problems. After all, the maximum value contained in a 14-bit number is 16,383. I'll look into your suggestion as soon as I can.

Thanks for your advice. I really appreciate it.

Cheers
Hippie