Products > Test Equipment
New bench scope - Fnirsi 1014D, 7", 1GSa/s
donwulff:
Various issues, I'm not sure if I'm supposed to ask or just test & debug :-// Is there easier way to debug the AllWinner chip than just printing out debugs into file/screen?
Sometimes the traces don't come up right on startup (I'll check the initialization order/clocks and also need to get most of the settings bound to buttons so I can see if they still work)
scope_setup_usb_screen() it takes really long for the disk to become accessible (sometimes it fails entirely).
settings the trigger mode makes the scope hang. (Interesting, it runs through the set-up commands but just stops responding after that, need to see if there's some mode-specific code)
Auto setting doesn't really set up triggers or anything, just timescale and voltage I guess (I guess first step is checking if it should, actually I think the trigger isn't displaying correctly).
Well, nobody said it was gonna be easy ;) Just in case there's anything known I need to take into account, though.
I needed some other components too so I went ahead and ordered the scope components from DigiKey as well (Took their last OpAmps, mwahahaa, and they don't have the Chinese KAQY214S's which claim lower on-resistance, just the Philips ones) and checked under the cans to verify I have the same OpAmp as everybody else. Too old to be soldering that fine components though, but I might try! And 125MHz frequency (250MSa/s ) seems to work, although whether it makes any sense will require getting some readings & higher bandwidth.
pcprogrammer:
For as far as I know it does not have proper debug support, at least nothing that is documented. Have not looked in the ARM documentation if there could be something for it, but if it is there it would require code to work with it I suppose. There are no external connections for it like on newer ARM devices like the STM32 where you have SWD.
About the traces, I vaguely recall an extra FPGA command being used, so it might be needing it at some point. You can search for the fpga_write_cmd function in Ghidra, to see which commands are being send from where in the code.
Strange that the USB code is giving problems. Have not received any feedback on problems with it in the 1013D. With the code on the 1013D and linux mint that I'm using it worked every time I tested it. As a matter of fact, it is also used in the firmware backup code and did not see problems on the 1014D with it either.
It might be that the trigger part is where the 1014D FPGA differs, and needs something extra to make it work.
There is some report about a problem with the auto set function on the 1013D, and it might well be what you are writing about. I'm not sure but believe I set the trigger to 50% when auto set is used.
Indeed nobody will say it is easy, because if it was easy everybody would be doing it :-DD
You state the 125MHz ADC clocking to be working, but how did you achieve that? Did you raise the FPGA main clock from 50MHz to 62.5MHz?
This might cause the timing to fail and result in problems in the data. It will also change the 1KHz calibration signal and the screen brightness control signal frequency, and all the rest that is derived from the main clock.
donwulff:
It seems I can hit 300 MSa/s with the FPGA clock (75 MHz) before the FPGA starts flipping out, that's not to say the ADC or bandwidth can follow, in fact I'm quite sure they don't, but it *looks* like it's working, including measuring correct waveforms ;) I'm running most of the testing with stock 50 MHz clock, it makes no difference, just wanted to see how far the FPGA fabric/ADC can go right off.
EDIT: Then again, I didn't check into the MCU data acquisition path, maybe the ADC is starting to shift levels & FPGA commands fail at the same time, but the most parsimonious explanation is the FPGA is just hitting its limit.
The mounting delay may be Windows filesystem check because I'm just calling the USB disk function which expects touchscreen to terminate, time to fix that next.
And yeah the trigger mode-setting code seems to go through without hanging, and doesn't hang afterwards either unless the mode is actually changed. It's waiting for trigger indefinitely, isn't it?
Some interesting issues popping up, but yeah I don't have 1013D to test if they happen on it as well, and in some cases I may just be using the existing code wrong. But I'm making progress getting it responsive.
pcprogrammer:
--- Quote from: donwulff on January 11, 2023, 06:06:54 pm ---It seems I can hit 300 MSa/s with the FPGA clock (75 MHz) before the FPGA starts flipping out, that's not to say the ADC or bandwidth can follow, in fact I'm quite sure they don't, but it *looks* like it's working, including measuring correct waveforms ;) I'm running most of the testing with stock 50 MHz clock, it makes no difference, just wanted to see how far the FPGA fabric/ADC can go right off.
--- End quote ---
The sampling frequency depends on the time per div setting. To do the maximum possible the software needs to be set to 200MSa/s which is the case when time per div is 20ns or 10ns per division.
But not bad that it works with 75MHz main clock.
Since I have both I can do some tests and compare between the two of them. Just write up what to test and make the code available.
donwulff:
I pushed current work at https://github.com/Donwulff/FNIRSI_1014D_Firmware/tree/PORT_A - it's not at all useful yet, other than getting to experiment with things a bit. (Yeah, I stuck everything into port_a module, and edited the NetBeant Debug makefile directly so NB will overwrite it and miss the new module). I have to focus on other things, and keep breaking the source, so better for me to save a copy now ;)
Also a size comparison of Philips AQY214EHAX SSR relay. SMD model here is larger than the S model, but it could work as the other end isn't over the rest of the components. Cooking components will take a while to arrive, so may look at on resistance then, and possibly circuit simulation.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version