kevtrisI decided to try and feed the display so more LFSR goodness, and I managed to get the link light to stay lit, and the fan kept spinning. Buoyed by this success, I kept at it and could keep the LED/fan on longer. Each time the FPGA was reset, the LEDs would flash on briefly with a different pattern too.
But, after awhile the status LED started doing a double flash. This means I blew away the main application firmware somehow. Whoops. Checking the rental install PDF, this means that the board is running on backup firmware. I will eventually desolder the flash on this board anyways for testing, and I will replace it with two .5mm FFC connectors to hook it up to my tester.
In the mean time, I will remove the flash from another board, bend pin 10 (/WE) up and reinstall, then solder /WE to 3.3V to prevent the flash getting blown away with subsequent poking. I should've done this from the start, but these things happen.
I was doing a bunch of poking around the barco website, and their "director toolset" is available for download. Inside the install file, I found all the various firmware images for what looks like every (or nearly so) LED product they make and have made. There's no registration or other requirements it seems and the installer is there for download.
https://www.barco.com/en/product/director-toolset
I used winzip to unpack the installer without running it.
In the installer it lives at: /install/install/installerdata/disk1/instdata/resource1.zip
in resource1.zip: /$IA_PROJECT_DIR$/directortoolset_2.08-win.zip
in the above zip: /flashfiles/
whew!
Inside was the firmware/software for these tiles. The FPGA bitstream and the microblaze code are separate files. There's a couple versions of each for the NX4 stuff. These appear to have a bit more metadata in them but otherwise look similar to the stuff found in the parallel flash.
The interesting files are named:
Nx firmware_ctrl 4.0.0.hwr (434K)
Nx firmware_mod 4.0.0.hwr (166K)
Nx program 4.0.0.swr (129K)
Nx program_backup 2.0.0.swr (57K)
Nx program_mod 4.1.0.swr (75K)
The documentation pdf that is on the director toolset link is also kind of interesting; it explains things like calibrating the display using a camera, manually, etc. as well as the kinds of diagnostic information available. These displays are also capable of gap compensation where it dims the pixels on the inside vs. the outside to make gaps less noticeable.. neat.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Richard's repo
https://github.com/raplin/OpenNX4.git
has some code for writing/dumping the flash. It looks untested but you might have the perfect platform to test it :-)
Are you sure? yes | no
yeah there is flash read code that worked last time I used it; the flash write stuff isn't implemented fully, IIRC you need to unlock the flash chip for writing with a specific sequence. I'm off doing 'real' work right now but plan to loop back to the stuff I did and finish it off. It would probably be easier to get that working than desolder the flash but YMMV
Are you sure? yes | no
Regarding the files in the Director Toolset. Only firmware_mod has a correct bitstream header for the Spartan-3E on these units; the firmware_ctrl is for a different FPGA family. I suspect firmware_ctrl is for the FPGA in the controller unit for each 9-module array (ctrl=controller, mod=module). Note that firmware_mod does not match either of the two bitstreams extracted from the flash - maybe it's a different version? I dunno.
The program_mod file seems to contain the same strings and font at the end as the firmwares in the flash, but the files are not the same. That may again mean it's a different version. Maybe there is a version string somewhere in the flash, to allow us to verify this.
Are you sure? yes | no
Yes I think there must be. I am thinking now that those text strings are used by the control box to query/set up the displays now. Some similar text is found in the "ctrl" ROM as in the display board ROM. I am trying now to send some of them but so far haven't had much luck. On startup, the board is still spitting out a repeating 10 bit pattern during initialization. It does not seem to return anything else on boot that I can see. It also continuously sends the same code out of the "out" connector to the next module when it receives an input clock.
Right now I am guessing it's a 10 bit code per character; a start bit, 8 data bits and a stop bit. There is most likely some kind of CRC check which is most likely why it is failing for me. I see refs to "CRC" in the ctrl code near the other text messages (around 33E0h in the NX program file). Lol at 336ah too: "SeCrEt CoDe 1234 %u.%u.%u.%u NX4"
Back to the LED board.
I sent all the usual permutations I can think of; LSB first, MSB first, inverted, non-inverted, etc. So far, no dice. guess I could set it up to send one command then 65536 different combinations of bytes afterwards to attempt and brute force any CRC if present.
The more "juicy" commands I see are TEST, INIT, UPDT, TFER, and INDX. There seems to be an on-time counter too... guessing that's what ONTM is. next to AGNG (aging I am guessing). Also interesting is the part number of the flash ROM is present in the same area- S29AL016D
That's about all I have poked through so far. This rabbit hole seems to run deep.
Are you sure? yes | no