Close

I^2C for Fun and Profit

A project log for BARCO NX-4 GROUP REVERSING ADVENTURE

This a project for a group of folks working to reverse engineer the Barco NX-4 LED panels.

kevtriskevtris 12/03/2017 at 01:222 Comments

After some messing around, I managed to capture the entire I^2C sequence on startup, and now have a complete log of what happens on the bus.

Looks like it initializes everything and then reads a bunch of the data out of the EEPROM on the LED board which isn't too surprising.  Every 2 seconds, it reads the two temperature sensors.    I will have a link below to the entire data log in human readable format.  Here's some highlights, though, with my notes:

At the start, there's a bunch of small 1-4 byte reads out of the two EEPROMs, most likely reading version/model information.

START
DEVADD: 50 WRITE ACK
SUBADD: 0F ACK 10 ACK

START
DEVADD: 50 READ  ACK
SUBADD: 32 ACK 32 ACK 32 ACK 32 NACK

STOP

START
DEVADD: 50 WRITE ACK
SUBADD: 0F ACK 14 ACK

START
DEVADD: 50 READ  ACK
SUBADD: 00 ACK 12 NACK

STOP

START
DEVADD: 51 WRITE ACK
SUBADD: 01 ACK 00 ACK

START
DEVADD: 51 READ  ACK
SUBADD: 32 ACK 32 ACK 32 ACK 32 NACK

STOP

START
DEVADD: 51 WRITE ACK
SUBADD: 01 ACK 04 ACK

START
DEVADD: 51 READ  ACK
SUBADD: 00 ACK 05 NACK

STOP

If you know about I^2C, the above should be self-explainatory.  If not, here's how a typical EEPROM read works:  First, the start condition tells the chip a transmission is happening;  then it sends the device address (50h is the control board's EEPROM, 51h is the display board's).   The direction of the following command is sent (read or write) then the sub-address.

For the first transmission the address 0F10h is sent.   To read from a location in the EEPROM, you first tell the chip you're going to write and specify an address, then repeat the start condition with read.   This is kinda hacky IMO but it is how it works.

After this, the EEPROM will spit out 1 or more bytes.  Your code has to ACK each byte except the last;  at which point you NACK to tell the chip you're done with it, and finally end with a stop condition.

So right off the bat, they are reading locations 0F10h-0F13h from the control board EEPROM, then they read from 0F14h-0F15h.  

They then read from the EEPROM on the LED board in a similar manner, except it's reading addresses 0100-0103h and then 0104h-0105h.

There's some more transfers from the two EEPROMs and then they initialize the light sensor:

START
DEVADD: 39 WRITE ACK
SUBADD: 80 ACK 03 ACK

STOP

START
DEVADD: 39 WRITE ACK
SUBADD: 81 ACK 00 ACK

STOP


Going by the datasheet for the TSL2560CL ( https://www.digikey.com/product-detail/en/ams/TSL2560CL/TSL2560CLTR-ND/3095174 )

Device address 39h is the sensor, then they write 03h to register 00h  which turns the chip on.  Register 00h is the configuration register.

Next, they write 00h to register 01h.  This is the "timing register".  It sets the gain to 1x, and sets integration time to 13.7ms (the longest integration time available).

After this, the two temperature sensors are initialized:

START
DEVADD: 49 WRITE ACK
SUBADD: 01 ACK 00 ACK

STOP

START
DEVADD: 49 WRITE ACK
SUBADD: 05 ACK 00 ACK

STOP

START
DEVADD: 49 WRITE ACK
SUBADD: 02 ACK 4B ACK 00 ACK

STOP

START
DEVADD: 49 WRITE ACK
SUBADD: 03 ACK 55 ACK 00 ACK

STOP

START
DEVADD: 48 WRITE ACK
SUBADD: 01 ACK 00 ACK

STOP

START
DEVADD: 48 WRITE ACK
SUBADD: 05 ACK 00 ACK

STOP

START
DEVADD: 48 WRITE ACK
SUBADD: 02 ACK 4B ACK 00 ACK

STOP

START
DEVADD: 48 WRITE ACK
SUBADD: 03 ACK 55 ACK 00 ACK

STOP

Device addresses 48h and 49h are the two temperature sensors.   Both are programmed identically.   The meaning of the writes is:

01h 00h:   Write 00h to register 01h-  this is the configuration register.   This selects temperature sensor 0 (the internal temperature sensor), clears the error queue, and turns the chip on.

05h 00h:  Write 00h to register 05h-  this is the secondary configuration register.  It's simply zeroed out since this chip does not have the "conversion start" pin.

02h 4bh 00h:  Writes 4b00h to register 02h- this sets the lower hysteresis trip point for overtemp.  4bh = 75C.

03h 55h 00h: Writes 5500h to register 03h- this sets the upper trip point for overtemp.  55h = 85C.

Interestingly the overtemp output pin is not used, yet they still set trip points for it.   They periodically read the temperature manually to check it and the overtemp pin is not connected to anything as far as I can tell.

After this, there are more reads (a lot more reads) from the control EEPROM and it gets written to the SRAM.   The LED board's EEPROM is barely used.  Maybe the outside controller has to request calibration data?  Maybe the calibration data is stored in the control EEPROM?  I doubt this but I guess it is possible.

During the EEPROM read, it gets interrupted to perform a temperature read:

START
DEVADD: 48 WRITE ACK
SUBADD: 00 ACK

STOP

START
DEVADD: 48 READ  ACK
SUBADD: 1A ACK C0 NACK

STOP

START
DEVADD: 49 WRITE ACK
SUBADD: 00 ACK

STOP

START
DEVADD: 49 READ  ACK
SUBADD: 1C ACK 80 NACK

STOP


Basically what it is doing is reading register 00h.   This is done by outputting a device address with write set, and then the sub address they wish to read (or write).

Then they do a device address + read, and get back 1AC0h (this is the 10 bit temperature, left shifted 6x).  1Ah = 26C.   The second board's temp sensor is read in a similar manner and returns 1Ch which is 28C.

These temp reads are repeated every 2 seconds while power is on.

Anyways, here's the log I made.

http://blog.kevtris.org/blogfiles/iic.txt

Enjoy!

Discussions

kevtris wrote 12/04/2017 at 01:34 point

I didn't check, I was going by previous information.  Let's see, I will check the address pins right now on the control EEPROM.   Yeah you're right.  I should've checked that.   50 is indeed the LED board and 51 is the control board.

Interestingly A0 is pulled high, A1 is grounded, and A2 floats.  I checked the datasheet and it says if any address lines are open, they have pulldowns.  So yeah they are reading most of that LED EEPROM in which makes a lot more sense.

Good catch!

  Are you sure? yes | no

modder_mike wrote 12/03/2017 at 13:59 point

It's good to be able to confirm TSL2560 (or functionally equivalent alternate), I was going on appearance and I2C address alone.

Are you sure about your I2C device assignments?  I'm fairly certain 0x50 is the LED panel EEPROM, which makes more sense to be read into memory at startup.

  Are you sure? yes | no