New bench scope - Fnirsi 1014D, 7", 1GSa/s

[pcprogrammer]

The sampling part of the 1013D code has been reverse engineered so far, to say with confidence there is no equivalent time sampling in there. They use some strange filtering technique on the sampled data to make it look good on the display causing it to be so slow that the display looks very stable.

The new firmware does no filtering and just displays the samples as is, directly after getting them from the FPGA memory. This makes it look a bit skittish, but it is much closer to the real signal. The moment you lower your sampling rate to below your signal frequency it will show aliasing in both versions of the firmware. I don't think you can reconstruct the original signal even when you process multiple sample buffers, unless maybe with doing a hell of a lot of processing on the data, and even then I'm not sure it will lead to anything good. But I'm no expert in the field.

Strange that you can't find much on the hantek scopes. There are at least four threads here on the forum.

https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/
https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/
https://www.eevblog.com/forum/testgear/hantek-dso2x1x-firmware-updates-and-best-use-practices/
https://www.eevblog.com/forum/testgear/hantek-dso2xxx-schematics/

The used ADC in it is assumed to be the ADC08D500 because it matches the pin out used on the board. It might well be a clone.

[donwulff]

I think I need more X's in the search strings, though I did just add reference to it on my notes. To note though, https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/475/ last posts, review isn't glowing, and the cheap price link is 335 EUR with shipping for me.  250 EUR:ish isn't bad for "utility scope" and it sounds like they haven't yet plugged the upgrade-hole (So that means the AWG BNC is always in place?), but doesn't quite make the <200 "gadget price" cut, and sounds like it runs the risk of not having everything enabled. Couldn't figure if the Linux build which doesn't need to be flashed in can do anything with the DSO part, but that's just a little bit of reverse engineering, right? It's interesting these are at a price point where I think shipping actually makes major part of the product price, and even labor/assembly despite it being China.

But ahem, 1014D thread, still kinda trying to focus on that I'll definitely be keeping an eye on the Hantek one though.

[pcprogrammer]

(So that means the AWG BNC is always in place?)

Yes because it is also used for the external trigger input, so always there.

And yes it has plenty of bugs that makes it not the best.

Reverse engineering it, despite it running on linux is no small feat though. There was some talk about it, but not much happened since.

[pcprogrammer]

I looked at the link you added to your notes about equivalent time sampling (https://www.tek.com/en/documents/application-note/real-time-versus-equivalent-time-sampling) which provides interesting information, but confirms my believe it can't be done with the 1013D or 1014D as is. You need to be able to set a specified delay on the trigger to get the shift in the samples needed to reconstruct the original signal. The trigger system in the FPGA does not cater for this.

It also states that the maximum bandwidth that can be measured with this technique is the analog bandwidth, which in these scopes is ~30MHz. This is also below the real time bandwidth of 80MHz (200MSa/s / 2.5), so no need for equivalent time sampling.

[donwulff]

Anyway, sorry to distract from the arguments lol, but finally got around to testing loading the 1013D firmware (Remote Desktop Infrastructure maps the SD as a remote drive, and Cygwin can't even compile gparted, and I mostly have Windows at work, on lunch break lol). I partitioned a blank image on remote Linux machine, used Cygwin dd to install things (Of note: Writing 8 GB flash on 1014D took almost 4 hours, at 611kB/s, also needlessly used up flash endurance, don't do that). Turns out the Pecos firmware at least really needs FAT partition, so I built dosfstools on Cygwin and ./mkfs.fat -F32 -v /dev/sdb1

The screen seems to work without any changes, and I'm really digging the look in the Pecos firmware, although the knobs & buttons don't work of course so I can't actually do anything yet. Looks like I may have to figure out some other differences though, because it's showing about 10 volt 40 uS rounded sawtooth on both channels, but connecting anything to the probe channels changes nothing. But this is definitely a good spot to start from, as I can see the UI and, well, something is working haha. Of course, after partitioning & FAT32 format this is just smooth sailing as I can use just dd.

Unfortunately I can't yet switch the Pecos firmware to USB writing mode, and sunxi-fel seems to suffer from common libusb ailment of not being able to find a device whose parent is the Remote Desktop terminal-server host.

https://github.com/pecostm32/FNIRSI_1013D_Firmware/tree/main/fnirsi_1013d_scope/dist/Debug/GNU_ARM-Linux says "The other file fnirsi_1013d_scope.bin can be loaded to DRAM with sunxi-fel and the scope in FEL mode to do testing without writing to the SD card." so I think I need to figure out this sunxi-fel stuff & build environment next, and I'm not even getting through reading the thousands of messages on the threads, most of which are just people who wouldn't get the scope anyway bitching about it. How_to_load_scope.txt tells how to use "sunxi-fel" which might require writing https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/sunxi_stuff or https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/Binaries/Hacked%20files/sunxi_stuff on SPI or SD. Though https://linux-sunxi.org/FEL has link to the sunxi-fel utility repository.

However, I grabbed https://github.com/linux-sunxi/sunxi-tools which in turn required building https://mirrors.edge.kernel.org/pub/software/utils/dtc/ which requires adding -Wno-error=char-subscripts to WARNINGS because I CBA to fix the coding violation, and PREFIX to /usr/ so the default build can find it.

At this point I might almost try to fix the libusb error, although I briefly tried earlier, or see if sunxi-fel can be easily changed to get around that issue.

[pcprogrammer]

As I'm a Linux user for my development I can't help with any Windows related problems 

But there are a couple of things to mention here.
To be able to load data to the DRAM with sunxi-fel the scope needs to be booted with the FEL boot I wrote. The difference between standard FEL and what I wrote is that the DRAM is not enabled in standard mode. (Standard mode is when the F1C100s finds no bootable program in either the FLASH memory or on the SD card.)

So to get the scope in this DRAM enabled FEL mode you have to write the FEL boot image I wrote to the SD card, just like you did with the 1013D firmware. With this one in it the scope boots into FEL mode after enabling the DRAM, and now you can load a binary file to the DRAM with sunxi-fel and execute it.

The DRAM starts at location 0x80000000. I load the binary to 0x7FFFFFE0 to get rid of the boot header that is present before the code. This is of course only if your make is setup to create this boot header, but without it, you can't boot your code from the SD card or the FLASH.

There is also an issue with sunxi-fel. I needed to get the source code including the FLASH read and write part to interact with the FLASH. There are versions that don't have this. When you only use it for loading to DRAM it does not matter of course.

I did build it from source, but don't remember from which repository. It is on my other computer and would have to look on that to find it.

About the partition type, the original firmware needs the card to be FAT, and I stuck with that. The reason for this is that both firmware's make use of open source code for the fat file system. (Google FatFs)

You mention the Pecos firmware and that is what I wrote.    Hope you do realize that pcprogrammer and pecostm32 are the same person. Had the github account before EEVblog and wanted a different user name for it.

In the 1013D thread you can skip many pages to get to the reverse engineering stuff. You can also just look at the posts in my profile starting from the first one on the last page. https://www.eevblog.com/forum/profile/?u=754690;area=showposts;start=2525 My first year on EEVblog was mainly in the 1013D thread 

To get a grip on controlling the firmware from the serial link look into the statemachine.c file (https://github.com/pecostm32/FNIRSI_1013D_Firmware/blob/main/fnirsi_1013d_scope/statemachine.c). It starts with the touch_handler function.

There is a lot of comments in the source code so should be easy to understand what the intentions are.

[donwulff]

Haha, yes I'm aware it's your firmware, been saying that. I wondered if I should just say 'your firmware', both felt weird but because they splash screen says 'pecos score' I thought people might have better idea what I'm talking about.

FAT32 is fine, it's just it didn't even boot without the filesystem formatted, which is fine. All the details are very helpful though.

Shouldn't really get into that, but business requirement is we have Windows Remote Desktop Infrastructure at work. As might be for a lot of remote work too, now. It's annoying enough for things like this I'm almost ready to just hook the scope up to Linux AI development platform, lol. 😅 USB drives aren't mapped as raw devices but just remote drives, and for some reason Cygwin is missing all the low level stuff for drives too. But dd is ubiquitous.

And because the USB HUB isn't on the server, it's virtual, and libusb horks on that because it's missing some of the physical properties and I guess most importantly isn't actually 'HUB' class device. Since libusb won't 'see' it there's no easy workaround. There's business case for fixing that because it means basically most libusb software doesn't work, so I might actually get around to fixing it. Just need to learn everything about Windows USB enumeration first 🤓

I guess Windows 'support' for the scope/development would be nice too, but that's definitely a side quest.

Writing the SD card on another device works, and I have Linux at home of course. But right now I'm working on it, like just on lunch breaks/waiting for something to finish mainly. Having it display UI and basically run is encouraging though. I will need to go through reverse engineering the knob serial link anyway, and figure out setting up development environment, after which I believe I should be able to just hook USB disk mode to some button.

Also have a look at the FPGA, particularly as I'm not sure the scope trace should be doing what it's doing now. In theory lifting the low pass filter is easy, whether I want to actually do it is another matter entirely because it's a function of the Nyquist frequency. But anyway let's see where it goes.

[pcprogrammer]

  The PECOs comes from the first to letters of both my first and my last name as can be seen on my youtube account. Just as the pc in pcprogrammer are my initials. Some where thinking it stood for personal computer 

I thought about the connection between the two MCU's, and it might be easier to hook up a cheap logic analyzer and decode the data with sigrok. With pressing the buttons and turning the knobs the commands should be seen. Saves going through the GD32 code.

Don't remember what the communication speed is. Otherwise two CH340 serial to USB converters would do the trick too.

Edit: I did notice a difference in the acquisition part of the 1014D code, but can't recall what it was. Either they send an additional command or one less. Most of it is the same. It can be found in the Ghidra archive. One thing to keep in mind that the "special ic" part can be ignored fully because it is just doing fixed conversions on the presented data. This means all the 0x6X FPGA commands.

[donwulff]

Ha, I need to do less posting & more doing though, but hey, well planned is half done forever, and all that... Anyway so TL;DR was it's not that I can't or don't want to use Linux, but sometimes you just gotta use Windows. And I think things would work fine with Cygwin with no help needed, but Microsoft's RDP RemoteFX USB redirection is just broken...

Looking at the schematics & data sheet, I think that can only be UART1 serial, which gives easy enough port addresses to look for in the Ghidra output. Mainly for baud rate & framing, although I suppose I could scoop that too. Assuming the main processor isn't expected to send anything, it's just a few tries to find out what it's sending for keys and work from there... If it does send, I'll have to play with the emulator. I'd hate having to solder things on the pins.

Trouble is, I couldn't find instructions on setting up development environment yet. https://linux-sunxi.org/Toolchain is well hidden, and suggests nothing special is needed for the cross-toolchain, and if I'm seeing right, no libc? I'll go with something I already have around, like arm-none-eabi-gcc-10.3.1

I think the scope performance would, at some point, be limited by the cheap Runic Tech OpAmp slew rate. Taken at face value, 180 V/uS would mean it would take 7 nanoseconds to swing the 1.5V (That's the ADC range more or less?). It's strange to me the signal rise-time spec doesn't seem to account for amplitude anywhere. I put in an order for a bunch of OPA356's from AlieExpress in case I evet get to that, with 360 V/uS it should be able to do 3.5 nanoseconds rail to rail at least if the filter is relaxed. marauder indicated they might send fake chips, maybe, we'll see. Thinking if there'd be any practical way to switch/control the low-pass filter, the front-end is using mechanical relays but there aren't even any control lines free. FPGA JTAG pins might, in theory, be reconfigured as outputs. Also I didn't actually check which OpAmp my board has, but I assume it's the RS8751.

I was wondering if there's been any clarity to the "special IC", is it just crude attempt at copy prevention? If so, that'd be two extra I/O's, unfortunately both need FPGA design. Filter switching would actually need KAQY214S or similar.

[pcprogrammer]

After thinking about it a bit, I remembered that the one big difference between the 1014D and the 1013D is the clock setup for the FPGA. The MS5351M clock synthesizer needs to be initialized. This is not needed in the 1013D because it does not have it.

It needs bit banged I2C to do the initialization. There is code for it in the 1013D to read the touch panel data. But instead of PA2 and PA3 it needs to be on PA0 (SDA) and PA1 (SCL).

The first channel is used to provide the main clock to the FPGA and probably needs to be 50MHz, so input times 2. The other channel is probably for the AWG. I think this is how the frequency of the AWG is controlled. Just modify the output frequency of the second channel and have the FPGA run through a fixed number of addresses.

[pcprogrammer]

Looking at the schematics & data sheet, I think that can only be UART1 serial, which gives easy enough port addresses to look for in the Ghidra output. Mainly for baud rate & framing, although I suppose I could scoop that too. Assuming the main processor isn't expected to send anything, it's just a few tries to find out what it's sending for keys and work from there... If it does send, I'll have to play with the emulator. I'd hate having to solder things on the pins.

Yes it is UART1 that is being used. I already named a lot of the functions in the Ghidra archive for it. See the attached images. All you have to do is check the code on what is written to the UART registers starting with 0x01C254.

You already have the manual for the F1C100s in the repository. It is the same as the F1C200s which I used because it has an index.

It is probably the easiest to solder the wires on the GD32 chip end 

[pcprogrammer]

I was wondering if there's been any clarity to the "special IC", is it just crude attempt at copy prevention? If so, that'd be two extra I/O's, unfortunately both need FPGA design. Filter switching would actually need KAQY214S or similar.

I have no idea why they added this in. All it does is create problems. The I2C implementation in the FPGA is crap and I have seen it go wrong often and needing a resend of the data. The scope became more reliable after I removed the usage all together. First needed to figure out what it did of course 

But when you use 8 if statements to make up an XOR who knows what other weird stuff you think up being great.

The FPGA has 17 pins free to be used, but soldering wires to it is a young mans game.  At least for me that is. Even with a microscope it is hard for me.

[Fungus]

Imagine how many more of these they could sell if they open-sourced the firmware.

[pcprogrammer]

Yeah, would be interesting to see if the 1013D sales went up after my firmware came available 

It would make it a lot easier to improve on it if they did open source it.

[pcprogrammer]

I looked on my other system and it looks like I got the sources for the sunxi tools from here: https://github.com/linux-sunxi/sunxi-tools
Other info about it: https://linux-sunxi.org/Sunxi-tools

[pcprogrammer]

Some pictures I found that might be of help. Might have posted them earlier.

[donwulff]

Hi thanks! That can be inhered from your well done schematics (Though I was initially confused because the signals of the JTAG footprint aren't named the same as the pins on the FPGA  ). And looking at the datasheets for the possible uses of the pins / register addresses.

I'm really, really hoping I don't have to solder anything on the legs of the main chips, if I can avoid it at all, with the reverse-engineering that's been done that should probably be way easier. I was going to ignore GD32E230 and let it be as it is at the start, but I suppose it might be easier to localize the protocol from that. Even if I somehow hit the legs on the processors, that wouldn't really be a repeatable hack for a lot of people. Getting extra pins from JTAG or in a pinch from the "Special IC" would indeed be preferable, IFF it turns out there's any benefit to that.

The optoisolated solid state relay COSMO KAQY214S must be a copy of Philips AQY214S, looking at the data-sheet main difference seems to be KAQY214 *claims* ON-resistance of 20 to 30 ohms, whereas the Philips one is 25-35 ohms. This would change the frequency response, probably for the worse. On the other hand, if a COSMO KAQY214S connected in parallel with the R62/R80 on the 1014D schematic, it should alter that from 150 ohms to about 18 ohms. According to the simulation on the Russian site ( https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3147914/#msg3147914 ) it should raise the low-pass filter for Nyquist/aliasing to around ~100MHz when the photodiode is driven (While maintaining the 400 V signal/1500V isolation) with minimum components/noise. Then again, I haven't independently verified the simulation, and it looks to me like it MIGHT apply mostly to AC-coupled mode, but the easiest solution is probably to just try ~20 ohm resistor in parallel once I get unmangled readings from the ADC with the new firmware (And maybe OPA356's to get faster rise time).

Speaking of MS5351M clock-generator, looking at the board on thermal camera, that thing's running at 50C+ hottest thing on the board while everything seems to assume it should be ran at room temperature. I don't think there's floating inputs or anything possible, so just normal? https://www.qrp-labs.com/synth/ms5351m.html says it's Si5351A clone, which is presumably where I'll find the I2C protocol/commands. Something like https://media.digikey.com/pdf/Data%20Sheets/Silicon%20Laboratories%20PDFs/Si5351A_B_C.pdf Of course reverse-engineering source can confirm values.

Firmware needs straight-forward Windows installer, although I'm wondering if there's different sizes of SD cards, too. It's kind of shame they didn't make the SD card external if they were going with one...

[pcprogrammer]

I looked back at the schematics and noticed that I did not connect the JTAG connector labels to the FPGA 

The JTAG pins are dedicated and can't be used as a normal IO pin, so no luck there. I can understand not wanting to solder any wires to the IC's as part of a new setup to be widely used. Similar to the reason for not making a new FPGA programming for it.

The two pins used for the special IC, are available and can easily be connected to on the provisioned header. Only problem is the IC on the lines.

The datasheet of the MS5351 is in the repository, but there is no programming info in it, so I guess it needs to come from the Si5351 manuals, and try to find it in the firmware.

I'm no expert on analog stuff, so can't really help on that. I had some electronics education and worked in the field a bit, but mostly digital and moved on to programming. A couple of years back I returned to the electronics hobby with an emphasis on microcontroller projects. Digital audio synthesis has my interest, and to have a small scope near my computer was the reason for buying the 1013D. It arrived with a problem in the touch panel, and that is what got the reverse engineering hobby started.

[donwulff]

Same, same. That's why I'm asking Though analog electronics comes up a whole lot in digital/embedded, but generally not OpAmp frontends. I think I was looking for an affordable hobby scope for learning/experimenting that I can use for anything without having to worry about breaking it on AliExpress, and you gotta admit the 1013D/1014D specs catch the eye. But with the Chinese stores, well I'd say 110% of them qualify as some kind of scam, starting with how every entry lists the price of some wire or something and not the expensive thing in the listing, the affordable thing is sold out, shipping is more than the product etc. but the one thing is you typically get the same thing that everyone else. So you have to Google it, and this thread comes up, and I know about the 30-40MHz useable bandwidth etc. (However I'll not this is still fairly confusing, because the rule of thumb is that any scope is only professionally suitable for signals 1/5th the bandwith on the front plate, so by that FNIRSI would be for ~20MHz signals. That said sampling rate is big deal, making it 40MHz plate equivalent, and thus maybe 8MHz real? And let's not talk about the sensitivity, which makes it indicator rather than signal integrity. But let's be honest that's MOST of what one would use a scope for.). The irony is it's going about open firmware for it, but turns out it doesn't work on the 1014D That's fine though, if I was going to play with the firmware, I might just as well try to make it work.

I'm trying to actually figure out Evi's ground offset mod at https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4536116/#msg4536116 - the schematic shows the negative reference going to pin 2 of the ADC. So that must be biasing the signal to -1.125V with -2.5V ref, but seems like that would flatten the signal, if I'm following double the rise-time for the OpAmp although probably reduce noise at the ADC? Though I suppose the first question is do I need / benefit from that at all. Also looking at that board picture, that's a whole lot of wires acting as antennas, which I'm worried for any modifications.

I think people would be fine, even eager to make small changes to the scope. If the new firmware works better than original, I'm sure anyone actually using a scope anyway could handle desoldering the chip. Even without that I guess that gives one in and (more importantly) one out signal without breaking anything, as long as the FPGA can be replaced. Of course, still need cheap SPI programmer, and something to connect the IO's to. But yeah, yeah, let's see if there's any point to that.

[pcprogrammer]

The 1014D has the advantage of the FPGA JTAG connector. It is possible to program the FLASH with the Anlogic IDE and the JTAG interface I wrote about earlier.

About the mod of evi, yes it could bring some noise into the signal. Though with the sensitivity as is don't think it will be a big problem. The ground thing is a problem when you connect the USB interface and have the probe ground on the same ground as the computer. That would be solved with the mod.

[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]

No idea about the ff's or cc 55 aa 33, maybe some sort of header, but then we get:

That is just a pre amble. Probably used when FPGA's are daisy chained with the configurations in one FLASH.

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.

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.