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

Similar projects worth following
Community project for reverse engineering the LED tile we all got cheap! Feel free to join if you want to share progress and work together!

If you want to be approved for membership, write about your progress (or effort) in the comments.

SuperConference folks: Welcome! Hopefully what we have is useful to you, please add information here if you figure something out!

We are updating the project details with information as we go.

The story so far...

We can control the LED drivers to scan out a row in the 12 sections, but we haven't figured out how to ask the CPLD to switch to the next row (or why the CPLD owns row MUX).

Current "Request For Investigation":  Figure out what the FPGA sends to the CPLD on the front board to get it to scan through the six display rows. If someone has a working display a logic analyzer capture of the FPGA->CPLD lines (ideally from boot) would be great.


Setting up and sending pixels to the LED row drivers, and turning on pixels (and the 3 self-test LEDs on the back)

Communications through the IN and OUT connectors.

Not working/unknown:

Scanning more than the first of the multiplexed rows; the CPLD is in charge of stepping these it seems.

Panel LEDs

Contributors: @Richard Aplin, @modder_mike

The panel is divided into twelve segments of 16x6.  Each segment is driven by three Texas Instruments TLC5941 16-channel LED drivers.  Each driver controls one color of the tri-color LEDs.  The three drivers have their serial data cascaded, with the first controller in the cascade being Red, then Green, then Blue.  Anode voltage is switched to each of the six rows of LEDs in sequence via a transistor controlled by the CPLD.

The 96 LEDs in the segment are controlled by only 16 driver channels by multiplexing the rows' LED anode voltage (TLC5941 switches the cathode side).  Each of the 36 rows has a transistor between the panel's +4.5V input and the LED anodes.  All like-numbered rows' transistors are connected to a common control pin on the CPLD.  The CPLD cycles through them in sequence as instructed by the FPGA, synchronized with the incoming display data.

Take care when rewriting HDL for the FPGA.  Because the LEDs are expecting to be run at only 1/6 duty cycle, they may theoretically be damaged if they are not cycled as quickly by user HDL.  (For experimenting, consider using the calibration LEDs on the rear of the panel, which are not multiplexed.)

There are three I2C devices on the LED panel, an EEPROM, a temperature sensor and an ambient light sensor used for brightness calibration.

Most of the LED driver control pins are brought out to the data connector by way of two buffers.  The remaining signals (SOUT for each driver string) are fed to the CPLD.

Back Panel Connectors

Contributors: @Richard Aplin, @modder_mike, @Chankster@Ian Hanschen

Input connector (TE AMP 206486-2 -  mates with 206485-1)

PinFunctionFPGA PinFPGA LVDS PairFPGA Direction
1+VIN. Connected to a Linear LTC1778.
Recommend 14.5-24V.
Read more »

This is a garbage project snapshot of when I first got lights. Some random thing in this is enabling the LED drivers. For {reason} you need to run this after first powering on the tile. Let's figure out what it is!

x-zip-compressed - 990.10 kB - 11/15/2017 at 22:26



may have errors, was dumped with hacky rig

octet-stream - 64.00 kB - 11/11/2017 at 06:23



may have errors, was dumped with hacky rig

octet-stream - 64.00 kB - 11/11/2017 at 06:23



The 2MByte flash dumped. Not certain the address lines are correct but it looks reasonable. Of note; some strings at 0x110eb0, also some obvious 8bit->12bit lookup tables at 0x112000, 0x112400 . Note that this FPGA uses a bitstream that is 0x29500 bytes (1,353,728 bits) long, and there's a clear break in the flash contents at that point. See for details on the data format- page 249 lists the bitstream bootstrap sync word of "0xAA995566" which is present at offset 4 in the flash. Possibly this image is off by 4 bytes, or maybe that's just how it is.

octet-stream - 2.00 MB - 11/11/2017 at 05:23



EEPROM dump, control board, Mike's sample #1

octet-stream - 64.00 kB - 11/03/2017 at 02:54


View all 11 files

  • 1 × Xilinx XC3S250E FPGA, Spartan-3E, 250K gates, TQFP-144
  • 1 × Cypress CY7C1041D Static RAM, 4Mbit (256K x 16), TSOP-44
  • 1 × Xilinx XC9536XL CPLD, 800 gates, QFP-44
  • 37 × Texas Instruments TLC5941 LED driver, low-side, 16-channel, QFN-32 (5x5)
  • 2 × Texas Instruments SN74LVC16244A Buffer/driver, tri-state, 16 channel (4x4), TSSOP-48

View all 14 components

  • OpenNX4 source + binaries posted!

    Richard Aplin4 days ago 14 comments

    A big chunk of NX4 Xilinx code (with precompiled binaries and python code to talk to the tile over UART) just posted: 

    Currently the code supports taking to a host over UART (e.g. loading images onto the NX4) and python code is provided to make it do stuff. 

    It's currently in an 'advanced user' state, there remains one vital thing to figure out on the NX4; how to get the row scanning working (i.e. how to get the CPLD on the LED driver board to play ball). 

    Once we get that sorted out we're fairly far towards a working, daisy-chainable video tile, controllable by a variety of hosts (Ardunio, embedded linux, etc) using a variety of protocols and doing a variety of 'intelligent display' tricks. 


    We should be able to end up with something you can flash onto a tile in a minute or two with a cheap JTAG adapter, and accepts further firmware updates over the wire

    The blocker right now is the CPLD (not) doing row scan... 

    Here's a really, really bad photo where I'm moving the camera so you can see the scanned image (original inset).   The tile itself seems high quality; you can get excellent intensity gradients on it, and the 1/6 scan rate w/12-bit CC drivers is a luxury.

  • Protocol suggestions

    Richard Aplin11/06/2017 at 22:18 5 comments

    Hi there, 

    As someone who's interested in the "reimplement HDL" option for the tiles - I thought a suitable name might be "OpenNX4" (resisting the temptation to run the two n's together) and had a few thoughts/suggesions to throw out there.

    For the sake of this discussion, let's say an "end user" is someone who (at least initially) has one or more NX4 tiles and a Raspberry Pi and wants to use them as a video panel (daisychained, with the tiles in a plane or just placed artistically), with minimum extra hassle.

    Because the only limit of how many tiles you can daisychain is your power source, your frame rate and your wallet, let's look at how we can get the best frame-rate (=highest speed pixel interface).

    The tiles come with an IN and OUT port. The IN port has 2x in and 1x out LVDS pairs, and the OUT port has 2x OUT and 1x IN pairs. The pairs can be used as single-ended i/os as well of course.  

    As NX4 is FPGA driven it means almost any protocol can be implemented (although HDMI video is not reasonable). You really just want a lot of downstream performance; an upstream link back from the tiles can be arbitrarily slow.

    If we look at what protocols are available on typical hacker boards (OPi, RPi, Allwinner, or even Teensies):

    I2C up to about 1-2mbps, UART ~4mbps.. and..

    SPI (and/or I2S) ports at up to ~100Mbit/s

    (There is also SD - as 'make the tile a fake SD card' which is fiddly and takes too many wires in fast 4-bit SD mode)

    Another option is that some SBC's have a connector for an LCD display which is usually LVDS, and we could probably provide an interface to that too assuming there are enough pins (or we ignore some of them). 

    The current crop of cheap allwinner H3 boards are great, and some tricks are possible including running both I2S ports synchronously (=2 bits @ 80+Mhz); they're my fave platform right now, but much of this is doable on a Raspberry Pi too (possibly lower performance).

    Suggested configuration

    For the sake of discussion let's say you stick an Orange Pi right physically on the back of an NX4 tile, and that's your video processor; you can send it stuff over wifi or ethernet, generate trippy images, play video off SD, whatever. It runs some code that preprocesses and maps the pixels to the tiles, and blasts the result to the first (and subsequent daisychained) NX4 tiles. (You can probably power the Orange Pi off the 4v6 supply in the tile).  

    First tile in array receives single-ended

    So the NX4 is an SPI slave.  All our tiles boot up in "spi slave" mode until they hear otherwise.

    So from your OPi you run SPI MOSI and SCK over nice short terminated wires into the tile data input. Add MISO so you've got a data stream back (we could connect CS but could also design the protocol so it's not required). This will probably achieve in the ballpark of 30-80Mbps actual throughput.  

    Even higher performance option : I2S on Allwinner boards; instead of using SPI it's likely possible to use synchronous dual channel I2S; i.e. run PCM0_DOUT and PCM1_DOUT, PCM0_CLK (and PCM0_DIN for a return data channel) which might achieve ~100Mbps. 

    Daisychained are differential

    Ok so that's the first tile, what about daisychaining?  Note that we can use the first tile as a "single ended to differential converter" and have the OUT port sending LVDS signals downstream to all the other tiles; hence we gain the noise immunity, longer wire length and general better performance of LVDS for all the other tile data links, however many there are (limited only by your desired frame rate).  

    Advanced hacker bonus points would be so only one tile needs to be reflashed with different Xilinx code, and it accepts a single-ended input from the linux board and converts it to Barco format output for the other daisychained tiles...

    Bottom Line - performance

    Ok so if in practice we get say 30mbps data rate...

    Read more »

  • Some words on the I/O connectors

    modder_mike11/04/2017 at 04:47 4 comments

    I see Ian posted a preliminary pinout for the input and output connectors.  I have some additional information on that topic that I haven't posted yet, so now seems as good a time as any to get that out there.

    In a full NX-4 installation, three of these modules are cascaded via the 8- and 9-pin connectors on the rear.  That means that all signals necessary for operation of the next panel must be transmitted by the previous one.

    Here's a key piece of information that may have been glossed over.  FPGA pins 128 and 129 (IP_L06P_0/GCLK8 and IP_L06N_0/GCLK9) are dedicated input pins.  These happen to be mapped to output connector pins 5 and 8.  Therefore, we can say that the output connector contains two power pins, four output pins, and two input pins.  Because the panels are daisy-chained, we can also therefore say that the input connector contains two power pins, four input pins and two output pins.

    If you look closely at the layout of the board, there are resistors attached to pins 7 and 8 of the input connector.  If you poke around, there are also two similar resistors tied to pins 2 and 3 of the input connector and pins 5 and 8 of the output connector.  These appear to be pullup/pulldown or termination resistors for the input lines.  Therefore, I assert that the pin directions of the two connectors are:

    Input ConnectorOutput Connector
    1 - +VIN1 - +VIN
    2 - Input Pair 1N2 - GND
    3 - Input Pair 2N3 - Output Pair 2P
    4 - Output Pair N4 - Output Pair 1N
    5 - Output Pair P5 - Input Pair P
    6 - GND6 - Output Pair 2N
    7 - Input Pair 1P7 - Output Pair 1P
    8 - Input Pair 2P8 - Input Pair N
    9 - ? No discernable destination

    It would not be unreasonable to assume something like that the dual pairs are a high-speed differential channel for carrying pixel data and consisting of clock and data pairs, and the single pairs are a status bus traveling in the opposite direction for panel configuration and error messages (fan fail, overtemp, etc).  There is also a resistor between pins 5 and 8 on the output connector, and pins 3 and 8 on the input connector; based on the rest of my theory and symmetry of design, I'd guess that pins 3 and 8 were the Data bus for pixel data, and pins 2 and 7 would be the Clock.  Or I may be missing something and my theory is completely worthless - this is all unconfirmed, which is why I hadn't posted it yet :)

    One additional additional note on +VIN.  Although things start to respond at only 6V, the input has to be higher than that for everything to work properly.  The LT1933 switching regulator that runs the fan puts out 12V, and it needs maybe 2.5V of headroom to do the step-down.  So the nominal input VIN has to be at least about 14.5V.  That's a weird value, so I'd expect the real input to be somewhere in the 16-24V range.

  • Trimming down members

    Ian Hanschen11/03/2017 at 13:30 0 comments

    Dropping some of the members who haven't contributed - I'm sorry about that. I was eager to have folks join in so I was auto-approving, but please post in the comments if you have something to contribute (or are working on something - that's good enough), and we'll approve your join request. Otherwise, if you've purchased the panels and are waiting for the results, just follow. I want to make sure the folks doing the hard work get the credit.

  • I2C Devices and EEPROM Contents

    modder_mike11/03/2017 at 03:10 9 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 :)

  • Xilinx starter project on github

    Ian Hanschen11/01/2017 at 04:07 0 comments

    I've pushed a Xilinx ISE starter project configured for the NX-4 board with all of the known pins mapped and outputs defaulted to ground. It's on the GitHub repo.

  • Quick test bitstream for ya

    Richard Aplin10/31/2017 at 22:13 12 comments

    I've got a bit carried away in the weeds with adding bells and whistles to my xilinx stuff (and it's broken right now) but I uploaded a .bit and .svf (use whichever your jtag supports), which zips some pixels along the top row of each scan. It's just a very rough thing from last week so you can see some pixels light up.

    Programming this image won't affect your board; reset it and it's back to normal.

    Note that on this image I used pin 7 on the input connector (that's the male connector on the left of the back, the top-left pin) as a chip reset, so jumper it to GND to make stuff work. 

  • JTAG

    Richard Aplin10/30/2017 at 04:38 1 comment

    FYI JTAG connections you may wish to use 2.8v as marked for your JTAG interface bus voltage instead of the 3v3 provided on the jtag connector.  I honestly think 3v3's fine but... someone would have to disprove my experience by doing it and not having the $20 Xilinx blow up. 

    It looks like pretty much any JTAG interface is fine; there are a bunch of tools; OpenOCD has some JTAG support but I didn't see Spartan 3E programming in there (it looks a bit light on fpga support unless I was looking at the wrong thing). 
    You can use the Xilinx ISE tools and the "device programmer" part can generate a kinda "jtag recording" (SVF file I think?) which is so simple almost any JTAG programmer can replay it to program a device.

    I tend to use a lot of embedded linux (currently Orange Pi boards which are my default hardware platform now) so "xc3sprog" works fine with an FT2232-based JTAG interface.  

    If anyone wants a buying suggestion for a JTAG interface; If you want a quality tool the "TIAO tumba"  FT2232 board (relatively pricey at $30) has all the level shifting and jumper doodads you want and looks to be a perpetually handy thing to have around the house.

  • Control Board FPGA Pinout

    modder_mike10/27/2017 at 07:48 0 comments

    I might be missing a few connections yet which I'll correct as I come across them, but here is the pinout of the XC3S250E FPGA on the control board.  Note that the SRAM and the Flash share an interface bus.  Also note that the JTAG interface is 2.5V logic.

    PinFunction PinFunction
    1PROG_B (Pullup to +2.5V)73GND
    2LED_L1_SIN74SRAM_A16; FLASH_A15
    3LED_L2_SIN75SRAM_A15; FLASH_A14
    4LED_L3_SIN76SRAM_A14; FLASH_A13
    5LED_R1_SIN77SRAM_A13; FLASH_A12
    7LED_R2_SIN79VCCO_1 (+3.3V)
    8LED_R3_SIN80VCCINT (+1.2V)
    9VCCINT (+1.2V)81SRAM_A12; FLASH_A11
    13VCCO_3 (+3.3V)85SRAM_A10; FLASH_A9
    19GND91SRAM_A6; FLASH_A5
    25I2C_SCL97SRAM_A1; FLASH_A0
    26I2C_SDA98SRAM_A0; FLASH_DQ15/A-1
    28VCCO_3 (+3.3V)100VCCO_1 (+3.3V)
    30VCCAUX (+2.5V)102VCCAUX (+2.5V)
    42VCCO_2 (+3.3V)114
    43SRAM_BHE#115VCCINT (+1.2V)
    45VCCINT (+1.2V)117INPUT_CONN_PIN_2
    49VCCO_2 (+3.3V)121VCCO_0 (+2.5V)
    50SRAM_IO7; SRAM_IO15; FLASH_DQ7122
    64VCCO_2 (+3.3V)136
    65VCCAUX (+2.5V)137VCCAUX (+2.5V)
    66FLASH_A19138VCCO_0 (+2.5V)
    70SRAM_A17; FLASH_A16142CPLD_PIN_42
    72DONE (Pullup to +2.5V)144JTAG_TDI

  • Lights on

    Richard Aplin10/26/2017 at 21:24 0 comments

    Simple/ugly proof of concept from last night; no row-muxing yet but the lights come on..

View all 14 project logs

Enjoy this project?



Richard Aplin wrote 3 days ago point

BTW running the pixel clock at 5mhz (current default, could go faster) gives you a total frame update rate of 0.695ms, or  1438fps. This is so fast you could easily add dithering; another 4 bits would have the LSB switching at 1438/16=90hz, which is probably still not at all visible (and you could happily run the pixel clock at 10mhz to double that to 180hz). That would get you an effective 16bit pixel resolution, i.e. 48 bits per pixel. I added that (TEMPORAL_DITHER) in the code but it's not very useful right now unless you also make the frame buffer wider; it's more just to say you can do 48bits per pixel than being useful :-)

  Are you sure? yes | no

Richard Aplin wrote 4 days ago point


Status: lots of things work EXCEPT the fucking row scanning. You can hook it to a UART and send RGB framebuffer images and have them displayed and fade them in and out and read/write SRAM and I2C and all sorts of stuff ... but the uncracked nut is getting the CPLD to scan rows. It's probably not very hard it's just a case of poking at it till we find the right thing (or logic analyzing an active tile).  There's another minor thing (likely a floating pin) that needs figuring out; after powerup you currently need to run the "test_pattern_boot" bitstream (that one I posted on here, also provided on github) one time, then the main project works. It's not that it doesn't work it's just there is no display output. Clearly there's a couple of pins (or CPLD state) not figured out yet.

Anyway.. I'm AFK for about 10 days, I hope this is useful/fun and that I put all the necessary files for ISE in github- lmk ASAP if the project doesn't build for you. 

  Are you sure? yes | no

Richard Aplin wrote 11/11/2017 at 05:43 point

I dumped the parallel flash; the Spartan bitstream is right there at the start of it. Elsewhere there's various interesting things, some text strings, some 8b->12b conversion tables, etc.  They might have put a microblaze core in there b/c the plaintext strings don't make much sense otherwise (text in the xlinx bitstream wouldn't show up as ascii in the flash of course).  File (and interesting offset locations) in files area.  Other stuff looking quite promising; I have SRAM, Flash, I2C working from the fpga, plus a working UART host interface talking to some python.  Still no actual pixels lighting up tho; I got wildly distracted with other fun (as you'll see) and left that part broken for ages, but I'll loop back around to that, get it debugged, and post some src and bitstreams

  Are you sure? yes | no

modder_mike wrote 11/11/2017 at 14:43 point

I dumped the first few K of the flash, and I also found it to start with 0xFFFFFFFF5599AA66, so either both of us were off by 4 bytes or that's how it actually begins.

  Are you sure? yes | no

Richard Aplin wrote 6 days ago point

yeah I think that's just how it is; I dumped mine twice and both times matched; the xilinx just looks for the bitstream sync marker so it doesn't care too much about the offset.

  Are you sure? yes | no

bruce.gettel wrote 11/09/2017 at 00:11 point

All - I'm not one of you experts, but I am fascinated with all things blinkenlights, and I bought 20 of these panels even though I've no idea what to do with them.  I also currently work for a Barco VAR and might have access to things that aren't all that easy for others to get.  For instance, I just downloaded the last released of firmware that Barco issued for the NX4.  

If anyone needs this or has requests for other stuff that I *might* be able to get, please ask away or contact me at bruce.gettel at gmail.


  Are you sure? yes | no

Richard Aplin wrote 11/07/2017 at 23:18 point

BTW if you like now might be a good time to order an Orange Pi if you want to play along with my fiddlings (to be posted RSN);  I was planning to do some host-specific things like implement a dual-I2S receiver mode which should run at around 100mbps (plus also use the hardware H264 decode etc) and set up a "plug'n'play'display" bootable SD image. Anyway, there are a bunch of them (on aliexpress, or some vendors on amazon if you want them faster); specifically I suggest the "Orange Pi One" (if you can wait for shipping ; if you want wifi use a USB dongle (e.g. a decent 802.11a with useful antennas). Other OPis models (there are many) can work but there are pros and cons too long to go into here. Like any component I suggest you buy two for the usual reasons.  I really _really_ enjoy working with them as host platforms for stuff. 

  Are you sure? yes | no

SpaceCoaster wrote 11/06/2017 at 23:21 point

I checked the rotation speed of the fan using an optical tachometer. With the original firmware it starts at 5800 rpm and then turns off. If I create firmware which just pulls the FPGA pin 39, lt19333_enable low to start the fan then the speed of the fan is 4100 rpm. Some magic in the original firmware must happen to control the fan speed and somehow to make it run faster!

  Are you sure? yes | no

modder_mike wrote 11/07/2017 at 01:37 point

If you look at the voltage driving the fan, you'll find it might be something like 7.5V... I believe pin 122 on the FPGA modifies the output voltage of the LT1933.

  Are you sure? yes | no

SpaceCoaster wrote 11/07/2017 at 02:07 point

That works! Driving the panel with 12V and setting pin 122 high produces 11.1V on the fan and a speed of about 6200 rpm. Toggling pin 122 at around 1kHz and I get a speed of 5800 rpm. The fan is quiet at 4100 rpm and even quieter when off!

So pin 122 is one for the docs, fan_boost?

  Are you sure? yes | no

modder_mike wrote 11/07/2017 at 02:28 point

I called it "FAN_ADJUST"... we're not really boosting the voltage, the nominal voltage is 12 and we're really adjusting it down.  On another note, the reason you're getting 11.1V is because LT1933 can't make 12V from 12V, it needs about 14.5V minimum.  I use 16-20V, but 24V should be fine too if you have it.

I see a very faint ~40kHz spike on pin 122, I wonder if that's the nominal control frequency... I can't prove it, because all the stock bitstream seems to do without signal input is 0% or 100% duty cycle.  It has to be fast enough that the smoothing capacitor at the LT1933 feedback input sees an essentially DC voltage - keep in mind we're using PWM to drive an analog feedback circuit.

  Are you sure? yes | no

Ian Hanschen wrote 11/04/2017 at 19:48 point

Would it still be worthwhile to lift the FPGA? I damaged the LEDs getting the plastic off my first board (too excited I guess) - I was planning to reflow them since the pads look ok, but I'd be almost ok with that panel being sacrificial.

  Are you sure? yes | no

modder_mike wrote 11/04/2017 at 22:51 point

Well, that would tell us whether any of the remaining unidentified FPGA pins go anywhere, which would be nice.  I'd enjoy seeing it, if you really want to sacrifice a control board.

  Are you sure? yes | no

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

Is anyone going to the Hackaday SuperConference?

  Are you sure? yes | no

modder_mike wrote 11/03/2017 at 17:36 point

nope :(

  Are you sure? yes | no

David Kuder wrote 11/01/2017 at 18:38 point

Is TE 206482-2 the right part number?  I couldn't find it at TE or distributors, 206485-1 however looks like the right part.

  Are you sure? yes | no

Chankster wrote 11/01/2017 at 19:38 point

I updated the parts list and can confirm these works (per the picture below).

206485-1 - CPC PLUG ASSEMBLY SIZE 11-9
206434-1 - CPC PLUG ASSEMBLY SIZE 11-8

  Are you sure? yes | no

modder_mike wrote 11/01/2017 at 21:17 point

The parts in the parts list were the connectors on the board, they shouldn't have been replaced with the plugs - they're two different parts :)

  Are you sure? yes | no

Chankster wrote 11/01/2017 at 21:33 point

I clarified the mating part numbers.

  Are you sure? yes | no

Richard Aplin wrote 11/02/2017 at 00:12 point

Thanks! Damn those things cost more each than we paid for the NX4 :-)

  Are you sure? yes | no

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

I guess I should clarify a little more.  206433-2 and 206486-2 are the empty housing part numbers, without the PC pins installed.  1776889-1 and 1776890-1 are the part numbers with PC pins preinstalled, but it's difficult to find info on those parts.

  Are you sure? yes | no

David Kuder wrote 11/01/2017 at 21:42 point

Thanks, yes I meant 206485-1 as the mating connector for the 9 pin.

  Are you sure? yes | no

Chankster wrote 11/01/2017 at 13:39 point

I can confirm that the TE circular connectors fit perfectly.

  Are you sure? yes | no

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


  Are you sure? yes | no

Ian Hanschen wrote 10/30/2017 at 15:37 point

Watching the constant use of the flash (the FPGA is using flash pins that aren't shared with SRAM), I wonder if it has an onboard microblaze or other soft processor and it's executing a poll loop, constantly reading the instructions from flash.

  Are you sure? yes | no

modder_mike wrote 10/30/2017 at 16:36 point

How often?  I saw that there was activity on the I2C bus every so often as well, it could just be logging temperature data or something.

  Are you sure? yes | no

Ian Hanschen wrote 10/30/2017 at 19:22 point

In my case it's constant - at least this is what I get from putting things in the 'read pin state' mode for JTAG. The address pins wiggle so I'm not sure it's logging temperature.

  Are you sure? yes | no

modder_mike wrote 11/01/2017 at 01:55 point

Are you sure?  The Chip Enable for the flash (FPGA pin 104) on my board is solid high (not enabled), whereas the Chip Enable for the SRAM (FPGA pin 31) is constantly moving.

  Are you sure? yes | no

Ian Hanschen wrote 10/30/2017 at 03:37 point

Finally got JTAG wired up, enumerates ok! (using 2.8 for vcc)

  Are you sure? yes | no

Richard Aplin wrote 10/30/2017 at 02:34 point

BTW I would remind everyone that I have a dead board (dead FPGA; just sucks power and gets hot) and I'm not sure what the cause was.  At the time I had a JLink connected (and working) and was using the 3v3 on the JTAG connector as my VREF (which runs the client-side of the level shifter in the jlink). The Xilinx also has series resistors on the JTAG port (there's a small resistor pack on the bottom of the board) which is recommended for running the jtag at 3v3 by Xilinx so i'd think it would be ok. However, my board worked for an hour or something, and then everything suddenly went south; the fpga turned into a heater and essentially is now essentially shorting its power rails.  Note that this also may have been a separate rogue loose wire zapping the board, and not the jtag at all, i.e. I fat-fingered something... but given that new FPGAs are $20 a pop on digikey, I thought I'd mention it.   What I can say is that if you nab 2v8 off the fpga and use that as your JTAG VCC then there's no problem (been hooked up for days to board #2, works fine).  Honestly I kinda expected 3v3 JTAG to be ok and it probably is, but I have a cautionary tale on my desk. :-)

  Are you sure? yes | no

modder_mike wrote 10/30/2017 at 05:27 point

Have you decided whether to pull the chip off yet?  I'd like to know how many of the pins I wasn't able to immediately trace are actually used somewhere on the board, which would be pretty simple if we could see under the FPGA :)

  Are you sure? yes | no

Richard Aplin wrote 10/30/2017 at 05:31 point

heh ok lemmie fire up the hot air one sec. thanks for your hard work on the other pinouts..

Update: I tried for a while. It wasn't coming off. I used a rectangular nozzle on my hot air that wasn't quite the right size, I could have tried longer or with different air settings but I got bored.

  Are you sure? yes | no

modder_mike wrote 10/30/2017 at 05:39 point

You're welcome :) By the way, I see your note in the UCF you posted, "Missing: Fan control on/off"... we actually aren't, the LT1933 generates the 12V for the fan, so pin 39 is actually the fan control (though I'm not yet ready to say there's not another control pin to set speed, TBD after seeing your results).  

Coincidentally, fan control and a blinking red status LED are as far as I've made it on my own HDL adventure so far...

  Are you sure? yes | no

Ian Hanschen wrote 10/30/2017 at 19:24 point

Have you tried those solder alloys that stay molten for much longer, like chip-quik? They make desoldering these sorts of chips easy.

  Are you sure? yes | no

Richard Aplin wrote 10/30/2017 at 01:31 point

A mike you have jtag- cool yeah I'll massage things into a working state and post to the github. Not sure if I have access - I'm "raplin"

  Are you sure? yes | no

Ian Hanschen wrote 10/30/2017 at 15:55 point

I've added you.

  Are you sure? yes | no

Richard Aplin wrote 10/30/2017 at 01:29 point

Yeah can anyone with a bit more time than me beep out the pins from the flash (and ideally sram too) to the Xilinx? Lots of kiddie halloween going on here.   I'm thinking that handy firmware for this would be a multi-mode receiver where the panel will display pixels sent as any of:  SPI, WS2812, UART or I2C, if we get carried away could have images stored in the flash (programmable over the interface) and then send "image select" messages, with intensity etc. Maybe play animated GIFs?  Lots of fun things to do anyway.  I implemented a framebuffer a a BRAM and that looks fine; still haven't figured out how to change the led scanline yet tho; stuck on outputting to the first 1/6. It should be easy (e.g. a 3 pin mux select) but they did put a CPLD on the display board so maybe they made it all fancy...
I'll post some stuff to github when I have a sec. I think the free webpack xilinx ISE will program these.  I used a JLINK and an FT2232 based board (w/level shifter) both successfully, I just got a Digilent JTAG device that is supported by ISE...  "End users" should be able to just jtag the unit once with something cheap (FT2232 most likely) and then send other stuff over the data link.   

Ian you look like an FPGA pro; last time I did anything on FPGAs was the Game Genie back in the 90's, that was all Altera and Actel and 486 PCs and dos tools :-)

  Are you sure? yes | no

modder_mike wrote 10/30/2017 at 02:16 point

Re: pinout of flash and SRAM - I already beeped it out and posted it, check the project logs :)

By the way and for what it's worth to anyone else interested in working on this - I'm using a Bus Pirate with OpenOCD to poke at it.  I'll post a tutorial when I actually get something working.

  Are you sure? yes | no

Richard Aplin wrote 10/30/2017 at 02:27 point

oh thankyou! I'd install the xilinx webpack version if you don't have it

  Are you sure? yes | no

Ian Hanschen wrote 10/30/2017 at 03:50 point

TopJTAG Probe is a fine tool, thanks for the heads up!

  Are you sure? yes | no

Richard Aplin wrote 10/30/2017 at 05:34 point

I've been scheming to make something like that for SWD as well, I was pleased to see it but there's a ton you can do with the concept. So nice to sample the pins of a device you're RE'ing with just 2/4 debug connections

  Are you sure? yes | no

Ian Hanschen wrote 10/27/2017 at 15:39 point

Thanks for posting the pinout - could one of you try to dump the flash and (or) eeprom on the back of the led board? I'm curious what they contain. So far, thoughts are calibration info, gamma correction ramps, ...? Also curious why it has a whole megabyte of sram. Maybe it generates the ramps and stores them there.

  Are you sure? yes | no

modder_mike wrote 10/28/2017 at 22:14 point

Half megabyte actually (256K x 16), but yeah.  There are only 3500 individual LED dice, so that's a lot of storage per subpixel.

As for dumping the memories, I'll work on it, but I'm not sure whether Richard or I will be able to get there first... the EEPROMs will be easy, but the flash will require one of us to write some HDL to read it out to a serial port or something because there's too many pins to do it any other convenient way, and he's got the leg up on me with regard to build environment :)

  Are you sure? yes | no

Ian Hanschen wrote 10/29/2017 at 23:07 point

I had a little time this weekend, I tried to send differential signals for clock, load and data (from an lfsr) to the 3 lvds pairs. The orange "have a connection" light went on, but I wasn't able to 'fuzz' it in any interesting way. The third pair below looks to be an output (oops) - I can read a voltage off of it. So really all I got done this weekend was figuring out P and N from the FPGA datasheet.

    INPUT_CONN_PIN_5 IO_L01P_0 (P) 112 
    INPUT_CONN_PIN_4 IO_L01N_0 (N) 113

    INPUT_CONN_PIN_7 IO_L02P_0 (P) 116
    INPUT_CONN_PIN_2 IO_L02N_0 (N) 117

    INPUT_CONN_PIN_8 IP_L03P_0 (P) 119
    INPUT_CONN_PIN_3 IP_L03N_0 (N) 120

Quartus is my mainstay, I'm still learning Xilinx ISE - if Richard doesn't beat me to dumping the flash, I'll try and get that done.

  Are you sure? yes | no

modder_mike wrote 10/30/2017 at 00:10 point

Yeah, I was going to include the pin names in the pinout project log, but the length of the names screwed with the layout of the table so I scrapped them, sorry about that.

I just a half hour ago got OpenOCD talking to the board, but I don't have any useful HDL written and probably won't have time until next weekend... so we'll see who gets to it first :)

  Are you sure? yes | no

Richard Aplin wrote 10/27/2017 at 00:24 point

Fairly obvious but worth pointing out that these things have 6 (optionally differential pair) inputs so should be straightforward to support all sorts of pixel input formats; SPI, I2C, UART.. even WS2812B emulation :-)  Enough flash and ram to support all sorts of things; perhaps even enough gates for a simple soft cpu? So much fun.

  Are you sure? yes | no

modder_mike wrote 10/27/2017 at 08:15 point

Hey, on your UCF.  You and I seem to have opposite LED_XLAT and LED_MODE assignments.  I went and traced the signal all the way back to the LED drivers and I think I've got it right, but then I don't understand how your HDL works...?

  Are you sure? yes | no

Richard Aplin wrote 10/27/2017 at 08:30 point

aaahaahahaaaaa.... that explains a lot of the last few hours of random flashing! :-) Thanks!   I was fuzzing stuff last night, working over it properly this evening and yes was having weird results... yes that works much better now :-)

  Are you sure? yes | no

Ian Hanschen wrote 10/26/2017 at 14:28 point

Github repo here, feel free to push:

  Are you sure? yes | no

Ian Hanschen wrote 10/26/2017 at 13:56 point

Moved the last progress update from summary to a log, please fix if I screwed anything up :)

  Are you sure? yes | no

Richard Aplin wrote 10/26/2017 at 12:44 point

Yes! 5:33am and we have leds lighting up!

[ Note: this is the 'easy' way - this is making the panel work by reprogramming the FPGA on it (temporarily; every time you reapply power the FPGA reboots with factory code from the EEPROM chip on the board) - critically this doesn't include any understanding of the regular Barco pixel bitstream, this is reprogramming the thing very hackily to make light come out..  A better solution will be to figure out the data format Barco use, but right now I have nothing that generates that data... ]

 I totally overlooked the part of the TLC5941 sheet that says you have to wiggle BLANK every 4096 GClks else you get nothing.  Anyway.. light is now coming out of the LED array and also the separate LED_CAL_SIN leds on the back.  Plenty of figuring out left to be done but safe to say it's looking like it'll be fine. 

I'll post something useful (xilinx bitstream, video, etc) asap but here's some somewhat useful Xilinx Spartan pinouts:  

NOTE these pinouts ("Pxx") refer to the main Xilinx pin assignments; the CPLD is a simpler chip on the LED front panel PCB that (I currently assume) is a fairly simple mux-with-bells-on.

// Preliminary/incomplete Spartan 3E pin usage for NX-4 tile. Definitely not fully correct; but LEDs light up

NET "led_l_sin[1]" LOC = P2; //m101 test point

NET "led_l_sin[2]" LOC = P3;
NET "led_l_sin[3]" LOC = P4;
NET "led_l_sin[4]" LOC = P5;
//rest of the LED_L_SIN or LED_R_SIN are not fully confirmed ; may be wrong, but probably close...

NET "led_l_sin[5]" LOC = P7; 
NET "led_l_sin[6]" LOC = P8; //not fully confirmed may be wrong
NET "led_r_sin[1]" LOC = P14; //not fully confirmed may be wrong
NET "led_r_sin[2]" LOC = P15; //not fully confirmed may be wrong
NET "led_r_sin[3]" LOC = P16; //not fully confirmed may be wrong
NET "led_r_sin[4]" LOC = P17; //not fully confirmed may be wrong
NET "led_r_sin[5]" LOC = P20; //not confirmed may be wrong
NET "led_r_sin[6]" LOC = P21; //not confirmed may be wrong
NET "led_sclk" LOC = P139;   //right
NET "led_mode" LOC = P32; //m104 test point on PCB  right
NET "led_xlat" LOC = P33; //m103 test point  right
NET "led_blank" LOC = P34; //m105 tp   right - note you have to drive this actively to get light..
NET "led_xerr" LOC=P10;   //not confirmed but likely
NET "led_cal_sin" LOC=P22; //serial in to a one-off driver that runs diagnostic leds 

//Now the comms pins to the small CPLD on the LED driver board

// we don't know what these do yet, but the CPLD handles row muxing plus more

NET "led_unk_cpld_p8" LOC=P123;
NET "led_unk_cpld_p5" LOC=P126;
NET "led_unk_cpld_p6" LOC=P24; //m102 test point
NET "led_unk_cpld_p44" LOC=P23;
NET "led_unk_cpld_p43" LOC=P132;
NET "led_unk_cpld_p42" LOC=P142;
NET "led_unk_cpld_p41" LOC=P143;

// i2c not checked but probably right
NET "i2c_scl" LOC=P25;
NET "i2c_sda" LOC=P26;

//definitely good...

NET "led_gsclk" LOC = P140;
NET "clock" LOC = P56;   //40mhz xtal on board

NET "led_status" LOC = P60; //yellow
NET "led_status2" LOC = P62; //red

//this is a pin on the NX4 input data connector; testing here...
NET "reset" LOC = P116;

  Are you sure? yes | no

Ian Hanschen wrote 10/26/2017 at 14:07 point

I've added a github repo, feel free to push code to it:

  Are you sure? yes | no

modder_mike wrote 10/26/2017 at 18:23 point

Well done sir, 0 to blinky in just a few days :)

One small correction, I don't believe Spartan-3E can boot from an I2C EEPROM, so I am guessing that the firmware is actually on the Spansion flash.  There's about 16 times too much space on the flash for a XC3S250E bitstream, so they're either using multiboot (there was mention in the manual about main and backup firmware), or there's some additional user data on the flash, or both.

One of my next tasks, after finishing extracting the component pinouts, will be to dump all the memories and see what we're working with.  I don't think anyone's managed to reverse-engineer a Xilinx bitstream yet, have they?  That'd make it pretty simple :)

  Are you sure? yes | no

Richard Aplin wrote 10/26/2017 at 20:59 point

The FPGA can't boot off a serial eeprom? That sounds odd - or maybe only SPI not I2C?  Anyway... I'm guessing the flash (which uses a hell of a lot of pins, being parallel) contains dot correction for the drivers (6 bits per R/G/B) as well as the Xilinx bitstream; because the rows are muxed you'd have to reload dot correction data every scanline, which would account for it being in parallel flash. (..but they could have copied it into the framebuffer SRAM on boot from a serial flash).. one guesses they may also support some other sorts of separate per-pixel adjustable coefficient.  Either way it's got a lot of junk in the trunk; the joy of not working down to a budget :-)    Having SRAM and flash (and a reasonable amount of I/O on the IN/OUT ports) makes a really nice fpga hacker platform 

  Are you sure? yes | no

modder_mike wrote 10/27/2017 at 00:01 point

Actually, looking over the datasheet again, it probably won't boot from a SPI EEPROM either.  The allowable options are:

- Master Serial from a Xilinx Platform Flash PROM

- Serial Peripheral Interface (SPI) from an industry-standard SPI serial Flash

- Byte Peripheral Interface (BPI) Up or Down from an industry-standard x8 or x8/x16 parallel NOR Flash

- Slave Serial, typically downloaded from a processor

- Slave Parallel, typically downloaded from a processor

- Boundary Scan (JTAG), typically downloaded from a processor or system tester

I'm guessing they're using the third option on this board.  We can be sure by probing the memory interface selection pins on the FPGA, which I'll try to do tonight.

Dot correction data, interesting.  That seems like it would be more appropriate to store on the panel EEPROM though - that way, if panel and controller were separated at the factory or on RMA, the panel's correction data could be loaded by a new controller and no additional calibration would be required.  A 512K EEPROM would be plenty large to record dot correction data for 1200 LEDs.  Flash being as slow as it is, I wouldn't expect it to contain runtime data; whether the data is in flash or EEPROM, it would normally be loaded to SRAM at boot.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates