| Products > Test Equipment |
| New bench scope - Fnirsi 1014D, 7", 1GSa/s |
| << < (50/67) > >> |
| donwulff:
Thanks, I wasn't seeing much divergence from ground in normal use and was wondering if that's a problem in some scopes because I didn't see any context for that mod. But figuring out why the level goes all wrong when plugged to computer has been in the back of my mind, because that needs to be fixed for any kind of data logger use... Although avoiding ground loops is a big thing with scopes, so haven't really looked at how that works yet. As for the FPGA, turns out the SPI flash on my scope is actually ZB25VQ80ATIG which is one reason reading it was so hard. Latest flashrom binary (with Bus Pirate and 1014D in same USB, 3v3 not connected) doesn't recognize the chip, but finally produces 1 megabyte dump using some standard mode (The FPGA needs to be able to read it, after all). It doesn't match the 1013D one in your repository, but that's probably to be expected. I seem to recall seeing a link to some header information in one of the threads, but now can't find it. Based on differences only starting on 92nd byte, I suspect the SPI reading was OK and I think there's a good chance the FPGA part is still the same though. 92 34 ^\ 344 M-d 95 222 M-^R 36 ^^ 96 15 ^M 156 n 165 0 ^@ 23 ^S 166 0 ^@ 30 ^X 167 0 ^@ 200 M-^@ 168 54 , 40 316 0 ^@ 2 ^B (more differences) Since the PFGA can't be field-upgraded, the FPGA interface must still be same with all 1014D's. Or well, 1014D has two different display variant, with different firmware updates from FNIRSI, so I suppose technically they COULD have different FPGA interface too. Edit: cmp -lb dump above starts at index 1 and whos byte values in octal, which makes it near useless, certainly if you try to match to the hexdump below... |
| pcprogrammer:
For as far as I know they did not tinker with the FPGA - MCU interface on hardware level. It is the same setup in all the 1013D's and 1014D's I know of. I did generate a partial net list for the 1014D FPGA, so if you are interested I can upload what I have to the FPGA reversal repository. Because it was an exploratory and educational adventure, I did not feel the urge to make a full fledged reversal software package for the Anlogic FPGA's, and due to this the clock nets of the 1014D are not listed. Did them by hand for the 1013D. I did look into the AWG part and memory usage a bit and found that the sampling memory setup is the same as in the 1013D and one additional memory block is used for the AWG. Basically the same crap design. Edit: Here is a link to a repository I got a lot of the used information about the Anlogic FPGA's from: https://github.com/mmicko/prjtang |
| donwulff:
Thanks again, after wading around a bit found the main thing I was after, the bitstream format/header: https://github.com/mmicko/prjtang/blob/master/docs/architecture/bitstream_format.rst 00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000020 cc 55 aa 33 f0 00 00 06 18 00 6c 31 0b b7 c2 00 |.U.3......l1....| 00000030 00 06 d1 00 05 00 e9 93 c3 00 00 06 d7 b0 4b b0 |..............K.| 00000040 af f0 c7 00 00 06 04 33 01 01 a6 53 c8 00 00 06 |.......3...S....| 00000050 00 00 04 80 98 88 c1 00 00 06 00 e4 00 00 1e 6e |...............n| 00000060 c4 00 00 06 02 00 00 20 6b 60 f1 00 00 04 00 00 |....... k`......| 00000070 78 af ec f0 04 33 00 00 b0 00 00 00 00 00 02 c0 |x....3..........| 00000080 00 02 c0 00 00 00 00 00 0b 00 00 00 2c 00 00 00 |............,...| 00000090 00 00 00 b0 00 00 b0 00 00 00 00 00 02 c0 00 00 |................| 000000a0 0b 00 00 00 13 18 80 20 00 00 2c 00 00 00 00 00 |....... ..,.....| 000000b0 00 b0 00 00 02 c0 00 00 00 00 00 0b 00 00 00 00 |................| 000000c0 00 00 00 00 00 00 00 00 00 b0 00 00 00 00 00 02 |................| 000000d0 c0 00 02 c0 00 00 00 00 00 0b 00 00 00 2c 00 00 |.............,..| 000000e0 00 00 00 00 b0 00 00 b0 00 00 00 00 00 02 c0 00 |................| 000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0 |................| 00000100 00 00 00 00 00 02 c0 00 02 c0 00 00 00 00 00 0b |................| 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * No idea about the ff's or cc 55 aa 33, maybe some sort of header, but then we get: f0 (device id packet) 00 (flags) 0006 (6 bytes) 18006c31 (al3_10) 0bb7 (crc) - which happens to be the al3_10 identifier, so yup, same device, which is main thing I wanted to know. First difference looks like starting at 0x56, c1 that is VERSION_UCODE, on mine that is 00e40000, in your repository 001c0000 The rest of the changes are after the "ec f0 0433" identifier, which I'm not sure from that description, but seems to indicate that's the actual FPGA blocks already. 0x0433 = 1075 = number of frames in Anlogic AL3 family. I may return to the FPGA later, but probably a good time to get libusb RDP and/or scope traces and knobs working. |
| pcprogrammer:
--- Quote from: donwulff on January 05, 2023, 06:44:01 pm ---No idea about the ff's or cc 55 aa 33, maybe some sort of header, but then we get: --- End quote --- That is just a pre amble. Probably used when FPGA's are daisy chained with the configurations in one FLASH. --- Quote from: donwulff on January 05, 2023, 06:44:01 pm ---The rest of the changes are after the "ec f0 0433" identifier, which I'm not sure from that description, but seems to indicate that's the actual FPGA blocks already. 0x0433 = 1075 = number of frames in Anlogic AL3 family. --- End quote --- Yep that is the number of frames in there. There is also another identifier that gives the number of memory pre loading frames. The size of the bit stream can be longer when the memory is initialized via it. The code I wrote to analyze the bit stream does not handle that, but it does process all the normal configuration bits. Was quite a task to figure it all out with the information at hand, because it did not mention where the padding of the frames sits or how the bits mapped to the data base information. The whole adventure is described in the FPGA reverse engineering thread. The trickiest part was to figure out the routing through the fabric. Wasn't until I stumbled on information about Gowin FPGA's that the light went on :) |
| donwulff:
Clock generator chip registers, in Chinese: https://datasheet.lcsc.com/lcsc/2012241239_Hangzhou-Ruimeng-Tech-MS5351M_C1509083.pdf Guess need to feed that to translator, although the should be pretty much same as https://media.digikey.com/pdf/Data%20Sheets/Silicon%20Laboratories%20PDFs/Si5351A_B_C.pdf which features desktop software for designing the register values. Ghidra decompile of the clock chip is giving me a headache, looks like the registers are changed for different time-divs, and presumably there's a table of at least some of the register values in memory, but also some dynamic stuff, and I'm not conversant enough in Ghidra to figure that out yet (looks complicated, to be fair. Need to also compare to the 1013D source code to make sure what it's doing). The I2C pull-ups are right under the clock generator chip, right hand side for the bus-side, it would be relatively easy to attach Bus Pirate and try to capture the register profiles. Not a big fan of unnecessary soldering though. The values are presumably just straight out the ADC clocks for each channel, so using the Silicon Labs software to design optimal values for the clocks might work too. In the 1014D design the clock generator and knob processor are on the same pins as the touch on 1013D. Funnily enough, the I2C is on alternate pins of the four though... I disabled the touch code just to be sure, but I guess the clock gen has just empty default configuration so there's no change to the scope trace from that yet. Serial-port/knob controller next, so I can easily program SD-card in place for testing? Link-time optimization makes the binary size grow? I guess that's what you get for compiling at -O3. I'm actually not sure how full the memory is currently. Shame they didn't just but F1C200s on all. |
| Navigation |
| Message Index |
| Next page |
| Previous page |