Products > Test Equipment
New bench scope - Fnirsi 1014D, 7", 1GSa/s
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. 8) 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 :-DD
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:
:-DD 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 :-DD
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version