Go Down

Topic: ARM Cortex I2c datasheet/Documentation. (Read 201 times) previous topic - next topic

stan_w_gifford

As the title says, I am seeking the datasheet/documentation for the ARM Cortex M3 I2c implementation. I am good at google - but just cannot find it. (I know the first response will come in 10 msec later with the pointer and I will go 'Doh!'.

That is the short story.

The long story is I have an issue with a Due talking to a Mega.

Due is Master, Mega is slave on address 0x11

Master sends a request to slave asking for 6 bytes.
Slave responds with {Byte}Hello (where {byte} is a message sequence that increments and rolls over from 255 back to zero.

All the above works PERFECTLY!

The issue is when I push reset on the slave.

The Due still manages to request the six bytes but after the first byte sends a nack (according to logic analyser).

In the Receive logic on the Due I have six bytes indicated received but all are the same value (the value of the message sequence.).

Looking in the wire code I have come up with a theory - and that is why I need the documentation to find out exactly what is going on - and what I need to do to rectify it.

I suspect that when the mega reset, the request to the mega will have failed/timed out. This set some status register to a 'value'

When the Due goes into it's receive logic and jumps into wire code, I can see that wire checks for (I am at work and don't have the exact code available) a byte being available. It still does this six times and places the byte value into the buffer (so that is why the receive gets the byte six times). The checking of the 'is a byte available (in wire code) is perhaps because of the previous funny status set sort of succeeding and it retrieves the first byte received (The hardware has not got any more data). After doing this six times it sends the nack to indicate it has all it wants - my gut feel is that it is doing this operation very very fast because it has an erroneous status that still indicates data is available to be read from the H/W)

All of the above is not explained very well (because it is a theory) and in some respects is irrelevant to the actual posting - Datasheet/documentation - however someone else may have come across a similar issue.

I am twitchy about putting serial.print in the library code (but will if I have too).

A possible (untested) workaround is to call wire.begin on the due at the start of each 'Transaction' in the hope that it may reset the wire hardware - but it is a bit of a kluge.

Anyway, I want to try to resolve what is happening and the doc would be a great help - if anyone can assist.

Stan


stan_w_gifford

Thanks for that - I did also find: http://www.nxp.com/technical-support-portal/#/tid=50809,sid=56890,bt=,tab=usermanuals,p=1,rpp=,sc=,so=

Which seems pretty good.

Stan

Go Up