Re: Problem with I2C


Paul Carpenter wrote:
On 5 Dec, in article
<1165369825.395623.117700@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
goister@xxxxxxxxx "galapogos" wrote:

Paul Carpenter wrote:
On 4 Dec, in article
<1165304918.361673.137080@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
goister@xxxxxxxxx "galapogos" wrote:
galapogos wrote:
Paul Carpenter wrote:
On 4 Dec, in article
<1165253652.590662.58080@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
goister@xxxxxxxxx "galapogos" wrote:

.....
Cool. I initialized my MCU to a slave receiver and now it acknowledges
the first device address, so there's no resending. I also managed to
get the MCU to interrupt on all subsequent data bytes, but I'm still
not able to send the correct data over. The data is either 0x80 of 0xfd

OK scratch that. The data that is sent is actually always 0x80, and I'm
not sure why that's the case. I'm sending 16 bytes of data over to the
master, and the initial handshaking is all fine until I actually send
data over by writing my data to my serial buffer SBI0DBR, but when I
immediately copy this data over to another junk variable, it reads
0x80, and according to my logic analyzer waveform, it is also 0x80, so
it looks like the MCU is indeed sending whatever is in the buffer, but
the buffer isn't being updated with what I actually want to send...

First *ASSUMPTION* the first data byte of the 16 data bytes to send
should be 0x80 ?

No, it is 0x00 to 0x10 in sequence. 0x80 isn't part of the data array
at all. In fact, I tried sending dummy constants but I always get 0x80
instead.

Are you sending a block of 16 bytes or 16 single byte read equences?

I enter the MCU's ISR after each ACK sent/received. Each time I enter
the ISR I send or receive 1 byte, so I guess I'm sending 16 single byte
sequences?

Check when changing to send first byte you change to transmit and have
set up everything and be sure it is in transmit mode before writing data
to controller.

Actually I'm not even sure if I can even change the transmit direction
on the fly. The control register that the transmit direction is at is
shared with the status register, so within my ISR, I check to see if
it's in transmit mode. If it is, then I'll send data, if not I'll
receive. It's really up to the hardware to tell me if it's in transmit
or receive mode AFAIK.

....
This suggests that you have not coded properly for interupt routines and
all the variables used.

Are the variables used by other functions and interupt routine
defined as volatile?

Variables modified by the ISR are declared volatile. Should those that
are simply read but not written to by the ISR also be declared
volatile?

YES if they are defined elsewhere (e.g. base pointer)

Are you sure that the index(pointer) starts at beginning of buffer?

Yes it is initialized to 0 in the init function

Are you sure that the index/pointer is reset correctly
at end of buffer to beginning of buffer?

What do you mean? The index never goes beyond the end of the buffer

Well anything could be happening.

Are you sure nothing else changes the index/pointer?

Pretty sure but I'll check

Are you sure the data is correct in the table?

Yes most definitely.

Are you sure the index/pointer is incrementing correctly and not
been optimised away. You need a way to get this value every time
used and be sure it is a real value.

You mean optimized by the compiler? How do I prevent this? By declaring
it as volatile?

If the index is incremented once EACH interupt call it is possible the
compiler optimises the increment away, for interupt routines and values
used there and elsewhere I would always make those variables volatile to
be on the safe side as a start point.

I understand. Better be safe than sorry. I've modified all the isr
variable declarations to be volatile, but it didn't change the program
behavior.

.

Relevant Pages

  • Re: AVR ADC multiplexer
    ... macros - make sure you use "volatile" keywrd when necessary. ... ISR, though. ... If the ISR puts the value into the circular buffer, ... then the buffer pointers _and_ the buffer ...
    (comp.arch.embedded)
  • Re: AVR ADC multiplexer
    ... ISR, though. ... In C, 'volatile' is a shorthand for "Dear Compiler, please don't ... If the ISR puts the value into the circular buffer, ... then the buffer pointers _and_ the buffer ...
    (comp.arch.embedded)
  • Re: Function prefix comments in C files
    ... >> volatile keyword tells the compiler that he cannot assume anything about ... >> SW ISR. ... > example, if there is a lot of data, maybe a single volatile "update" flag ... use reentrancy (assuming timer ISRs and/or other code needs to call the ...
    (comp.arch.embedded)
  • Re: Function prefix comments in C files
    ... It sounds to me like your and your colleagues are mainly electrical engineers, and none have any real training in programming. ... volatile modifier" is a common misconception, and shows an incomplete understanding of what "volatile" means, and how ISRs interact with other code. ... Since any variable modified by an ISR that is used in the program elsewhere, why would you NOT tell the compiler that the variable is volatile. ... uint16 sampleA = seconds; ...
    (comp.arch.embedded)
  • Re: Mutex does not seem to lock
    ... I guess that your ISR is called at an IRQL higher that DISPATCH_LEVEL. ... Since a mutex can be acquired recursively by the same ... the ISR called in the UserThread context will successfully acquire ... This requires me to lock the user buffer into ...
    (microsoft.public.development.device.drivers)