533 / i2c

Hello. Bought a 533 in I2C flavor last week. Finally got to the point of trying to use it.

I've got several other I2C devices working, but when I try to hit the 533 it won't respond. I'm just trying to feed the bytes manually for the moment so if there's something I'm doing wrong, please advise what I should do to confirm functionality here before I try getting into the packet structure.

Honestly I wanted a plain I2C format device, not a packet structure. If I'd seen that before I bought it...I wouldn't have. I'm willing to try to make it work for the moment, however...

I do:

Start, 0x84 and get an immediate NAK.

If I disregard the NAK, I can push on and try to do a clear screen:

Start, 0x84, 0x06(clear screen), 00 (data length), 0x97, 0x5B (CRC, LSB first) stop

Or get read the hardware and firmware with:

Start, 0x84, 0x01 (get info), 00 (data length), 0x9F, 0x16 restart 0x85, readbyte
I did also try 0x16 0x9F for the CRC....

In either case, no data was made available.

Thanks for any assistance.

Tom

We have some I2C sample code:

http://www.crystalfontz.com/products/document/2097/CFA-533-I2C-AVR.zip

It runs on an Atmel ATMega.

Basically you need to send the bytes that make up the packet then STOP. The module will execute the command (you need to do a little delay as listed below) and the prepare any return data in its return buffer.

You can then do a read of the return data.

The CFA-533 takes a small amount of time to execute the command before the result can be read. For many commands 5mS is plenty of time for the CFA-533 to complete its processing and have the result ready for the host to read. Commands that may take longer are:

2 (0x02): Write User Flash Area
25mS

4 (0x04): Store Current State as Boot State
50mS

5 (0x05): Reboot CFA-533, Reset Host, or Power Off Host
500ms (for parameters \008\018\099, Reboot CFA-533)
2S (for parameters \012\028\097 Reset host)
2S (for parameters \003\011\095 Power off host)

14 (0x0E): Set LCD & Keypad Backlight
50mS (all change)

20 (0x14): Arbitrary DOW Transaction
50mS (execution time depends on the transaction)

(edit: Add in set backlight command delay. -CF Tech)

Well, I was entering the start, data and stop commands manually, so it was getting several thousand milliseconds between commands / bytes. As your documentation says, I2C devices don't "time out" so commands can be sent at down to DC speeds.

My bus is set to 100khz and other devices (I2C eeprom and a barometer I have) work properly - I have the wiring and pull-ups correct. I am powering both the display connector (on the 533) and the com logic.

I'm working with a PIC24F chip. I started with the I2C bus in a known good state and initiate a start condition by setting the .SEN bit (start enable). About 1-2 seconds later, I place the address (0x84 - the default from your documentation - I haven't changed it and confirmed that I get "42" if I hold the up and down arrows on the device) for write mode into the transmit buffer and the chip sends it.

It then reads the SDA line for the /NAK or ACK state...and I'm getting NAK which indicates nothing is listening on 0x84.

As I said, I then figured it might be a bug so I sent all the bytes for the clear screen command along with a stop at the end. So that sequence was:

START
0x84 (address)
0x06 (clear screen command)
0x00 (data length)
0x97 (CRC LSB)
0x5B (CRC MSB)
STOP

I got the CRC using one of your demo programs. But as I said, right when I put the address out there, I get a NAK which tells me the device isn't even listening...

Tom

Can you verify the firmware version you are using? It should come up on the boot screen. Also can you verify the address by holding the up and down arrows?

Can you port the "send_packet()" and CRC code from the Atmel to your PIC? I am worried that when you manually send the bytes there might be a STOP between them? Maybe the PIC is different, but in the Atmel code I have to manually tell it when to send the START STOP and NAK bits.

Worst case we can make up a demo board and loan it out to you for a bit.

I have attached a PDF with scope traces for the ping command. Those might be helpful. These were made using an Aardvark from TotalPhase, and the 533I2C_WinTest. Because of that the read is longer than it needs to be.

I received the device within the past week or so. I placed the order Jan-27 and it was listed as backordered expected Feb-1. However, I received it last week already.

Boot screen reads:

Crystalfontz 533
I2C: h1.0, c1.0

Holding down arrows results in:
I2C Address:
now: 42 boot: 42

Based on the documentation I'm therefore attempting to use 84 and 85 (although I did also try 0x42 just to be sure...) (pg 41): "The default address of the CFA-533 is 42 (84 writes, 85 reads)"

Like the AVR, the PIC I'm using has TWI/I2C built in. What I am doing manually in the PIC registers is exactly what the AVR sample code does to that device - setting conditions in control registers and reading/writing bytes to tx/rx registers. I could (and have tried) do it through code and get the same results. The code would even look the same as your AVR code - all that would change is the register names.

I can state with complete confidence that there is no stop condition between bytes - as I said, my PIC works the same as the AVR here. Further, if there were a STOP being set, the other devices would stop talking as well. I'm using an oscilloscope and can see the result of the various transactions / bus conditions. Also, the status register indicates when start/stop conditions have been detected

Upon transmitting the 0x84 write address, the status changes to 0x8008 indicating NACK (bit 15) to the previous write, and that the bus is still STARTed. When I start from a clean START condition and address the working devices, the status register reads 0x0008. What I'm getting is the condition checked for in your sample code, "send_byte" function that reads:

if(TWSR != MTX_DATA_ACK) //If NACK received return TWSR
return TWSR;

...I'm getting the NACK received, indicating an error...when I send 0x84 as the device address.

I could paste in my exact process for reading from the EEPROM, but given that the PIC works the same as the AVR just with different register names...I don't think that's necessary.

Now..I suppose I should verify connections with you just to make sure there's not a documentation error...

Looking at the back of the unit:
I'm attaching +5v/GND to the "J_PWR" jumper on the upper right corner

For I2C I am using the 10-pin header as documented on page 21 of this file: http://www.crystalfontz.com/products/533/datasheets/1703/CFA533-TMI-KC_v1.0.pdf

AHA!

I believe I found the error.

Your doc says the default address is 42, which gets shifted left 1 bit to make 84 - hence the "84 writes, 85 reads" listed above.

Thanks to your PDF attachment above...on the 2nd page detailing the "read ping"...where it says the address is 42 DEC, 2A hex....I took that 2A, doubled it (shift left 1 bit) to 54 (not 84)...and sent START 0x54 0x06 0x00 0x97 0x5B STOP ....and the screen cleared.

I wasn't expecting decimal numbers for a device address.

Tom

OK, now that you say that I think someone else had a similar problem. I'll see if we can get the address specifically noted as hex and decimal in the data sheet.

We do not have any PIC sample code, so if you would be willing to post some simple cost that illustrates sending and reading a packet, that would be awesome.

CF Tech said:

OK, now that you say that I think someone else had a similar problem. I'll see if we can get the address specifically noted as hex and decimal in the data sheet.

We do not have any PIC sample code, so if you would be willing to post some simple cost that illustrates sending and reading a packet, that would be awesome.

Click to expand...

We'll see where I end up with the code. Sometimes I write clean but other times I don't bother decluttering during/after debugging.

FWIW, I've had a bit of "down time" waiting on something else in my project so I've mostly ported over the AVR demo app code to my PIC chip.

Got a few bugs that I think are related to my prototyping layout (involving 2 ribbon cables and a hop across a breadboard), however - I can't get the code to run reliably at full speed. In a few days I'll have a circuit soldered together with a much shorter, more direct connection from the uP to the CF533. Not gonna worry about debugging more until then.