Close

I2C Devices and EEPROM Contents

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.

moddermikemodder_mike 11/03/2017 at 03:109 Comments

I've mapped all five I2C devices in the assembly to addresses now.  They are as follows:

0b0111001x (0x39): LED Panel ambient light sensor
0b1001000x (0x48): LED Panel temperature sensor
0b1001001x (0x49): Control Board temperature sensor
0b1010000x (0x50): LED Panel EEPROM
0b1010001x (0x51): Control Board EEPROM

The ambient light sensor's address corresponds to one option for a Taos part; it responds to a request for register 0x0A with 0x0A, which either means it's a Taos TSL2560 Rev. 10, or it's something completely different that just parrots back the data sent to it (I haven't dug any further into it yet).

I have also dumped the two EEPROMs, and have posted them to the Files section.  They are structured differently, but both start with a preamble containing the part number, serial number and manufacture date.

Now go forth and speculate wildly :)

Discussions

Ian Hanschen wrote 11/03/2017 at 11:55 point

Good to hear Richard. I looked at the ROMs with some entropy tools last night. The control board one *might* be a simple image with repeating dot calibration followed by colors for each row.  It looks like both ROMs have a similar tail. I thought CPLDs mostly use onboard flash for config, but I want to make sure these aren't the config ROMs for the FPGA and CPLD. It seems counter to my intuition - I wouldn't expect them to be i2c and I wouldn't expect their bus to be exposed to the FPGA and CPLD. 

  Are you sure? yes | no

modder_mike wrote 11/03/2017 at 12:52 point

They can't be the config ROMs for the FPGA and CPLD, for several reasons - the CPLD isn't connected to the I2C bus and doesn't use an external ROM, and the FPGA can't use an EEPROM for configuration and 512Kbit isn't big enough to store a bitstream for it anyway.

  Are you sure? yes | no

Ian Hanschen wrote 11/03/2017 at 12:56 point

Got it. By the way, thanks for dumping these, and thanks for doing the hard work of tracing this stuff out.

  Are you sure? yes | no

modder_mike wrote 11/03/2017 at 13:06 point

You're welcome :)  All for the good of the internet, of course.

I think the flash will be the more interesting item though, I'm convinced that's where the config bitstream will be found, but it's too big for just that, so I'm curious what else it may hold.  Honestly I'm thinking the easiest thing for me to do will be to write an I2C slave routine for the FPGA and read it out the same way I did the EEPROMs.  A project for this weekend...

  Are you sure? yes | no

Ian Hanschen wrote 11/03/2017 at 13:15 point

You could do a 2 pin thing - instantiate a parallel to serial fifo, with a state machine taht walks from the beginning of the flash to the end, both clocked by an input pin on the FPGA, with the serial data on an output pin. So you just clock the whole thing enough cycles for all of the bits of the flash and you're done. I was thinking about doing this, but my download end was more complicated - I was going to write a core on another FPGA (Altera, my comfort zone) - which returns the data to my host machine over virtual JTAG. It might be a lot simpler to use a pi or whatever on that end.

  Are you sure? yes | no

modder_mike wrote 11/03/2017 at 14:49 point

Hmm.  I'll think about it, but then I'd have to write something for another piece of interface hardware.  If I can use Coregen to instantiate a simple I2C, I'd have to write fairly little HDL to emulate an EEPROM, and then I can just use my standard Bus Pirate and no additional software to do the dump.  I could similarly use SPI or UART or whatever else the Bus Pirate supports, but the I2C pullups are already there and the pins are exposed on the board on easy to grab SOICs.

[Edit] Except that Coregen doesn't seem to have an I2C peripheral.  Hmm.

  Are you sure? yes | no

Ian Hanschen wrote 11/04/2017 at 01:32 point

  Are you sure? yes | no

Richard Aplin wrote 11/03/2017 at 06:04 point

nice! I will post some xilinx code as soon as it's in a lighting-up state. Currently it doesn't actually display anything but it will shortly...  
It's interesting their "no expense spared" approach to the engineering, I rather like the thing of have a separate led cluster just for it to monitor; presumably for aging detection or maybe temperature compensations; either way it's pimpin'

  Are you sure? yes | no

modder_mike wrote 11/03/2017 at 13:02 point

Both good speculations.  I'll add LED binning compensation - since these modules are meant to be replaceable on a large installation, it's very possible that a two year old installation may have been built with differently binned LEDs than a brand new replacement panel.  In all of these cases, the result is the same, each panel must sample its LEDs and report the result to the master controller, which probably does some fun math and normalizes the data for the installation to the weakest module's ability.

Of course, the calibration LEDs need to be running all the time with comparable wear to the front array in order for aging or temperature calibration to be meaningful, so we then have to figure out an algorithm to reduce 1152 LEDs' worth of usage to three representative samples.  More fun math :)

  Are you sure? yes | no