Re: [sigrok-devel] Getting firmware for Kingston LA2016
(just my guess on reported run_state's) my assumption is that run_state 0x85e_2_ is meaning "waiting for trigger condition". from your other log output i see that there is no edge/level-trigger requested, device should just start sampling 200M samples no matter what signals are applied... and my device immediately signals this by reporting a run_state of 0x85e_e_ "triggered". next run_state 0x85e_d_ is signaled as soon as acquisition buffer of 200M samples is full, which will trigger download. your device does successfully transition from 0x85e_9_ to 0x85e_2_. i am curious what your log looks like if you request fewer samples (e.g. via --samples 256). (also make sure to leave the programm running long enough (~20s ?) such that enough log messages are generated.) flo. ___ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
Re: [sigrok-devel] Getting firmware for Kingston LA2016
hi helge, TL;DR: can someone help helge with creating a usb trace on windows? attached is a log file from running the command sigrok-cli -l 5 -d kingst-la2016 --samples 200M -O binary -o test.bin on my linux machine (debian kernel 4.19.0-2-amd64 with debian's libusb-1.0-0 version 1.0.22 on ICH9 usb controller) generated with: (those are master HEAD's at time of writing) libsigrok master efce57da322cbe3d8c65332122ab3fb76e02089a sigrok-cli master a23df119fc43c72eacf1dbd68d6fc0b205cee60b sigrok-util master f8dd8b1eb8bc6da53335a4745d258830ea6367a0 firmware extracted from vendor version 3.4.2: md5sum .../sigrok-firmware/kingst-la-01a2.fw 8fb89c53eee7114e3e1d19e980e8dc4e md5sum .../sigrok-firmware/kingst-la2016a-fpga.bitstream ad2bd9e0a755d5f5e09a20dbfacb2eb9 can you compare whether you get the same fw-hashes? please also keep in mind that the log-output will differ when running the program a second and further times after plugging in the hardware (the ezusb firmware upload is only done once after plugging the device, and as such those log messages are missing in your log file) can you re-plug your hardware and generate that log file again? from your file i can see that you tried to retrieve 200M samples, this will take some time to acquire and download (~0.9s on my host), you could try to test first with fewer samples: sigrok-cli -l 5 -d kingst-la2016 --samples 256 (as your log shows only 5 "run_state" updates after "Received SR_DF_HEADER", all within the same millisecond?) the only significant difference from my to your log file (minus ezusb messages and the final data-download) is that your device is not reacting as expected after FPGA bitstream upload -> this is hinted by the log message "unknown_cmd2 response is not as expected!" which does not happen with my device. (there are two "not-completely" reverse-engineered commands sent to the device after bitstream upload, i am expecting the message about the first one, but not about the 2nd command) and the run_state reported in the end does not look like the device is actually acquiring data ... (i would expect 0x85ee as in my log, and then 0x85ed when data can be downloaded) this leaves me to believe that something with fpga bitstream-upload or configuration went wrong. for me it would be easiest to get a full usb-trace from running "sigrok-cli -l 5 -d kingst-la2016 --samples 256" directly after plugging the device. (probably best via direct-mail) i can describe how to generate such a trace on a real linux (no WSL, e.g. via an debian/ubuntu live cd?) if you have root-rights, the usbmon kernel module, wireshark or tshark. basically: sudo modprobe usbmon sudo apt-get install tshark # plug hardware # identify on which usb bus the device is plugged in e.g. via lsusb -d 77a1:01a2 # Bus 004 Device -> usbmon4 sudo tshark -i usbmon4 -w - > trace.pcapng # run sigrok-cli ...in another terminal / or vendor software # press ctrl-c on tshark terminal to stop trace (trace will contain ALL data from that bus... so maybe you might want to make sure that there is no other device with sensitive data plugged to that bus -- like usb drive with sensitive data...) but i can not describe how to generate one on windows. i think it can also be done using wireshark but i guess you might need some additional drivers... maybe someone else here on the list can describe how to generate a full usb trace on windows? or try google i would prefer a pcap file from wireshark/tshark but would also be willing to interpret other log formats (as long as they are text based and include all usb-data) if you can generate such a full trace from "sigrok-cli" it would also be very helpful to re-plug the hardware again and then do another usb-trace while doing an acquisition with the vendors original software -- that way i can look for differences. (as requested i've also attached log output from running sigrok-cli -l 5 -d kingst-la2016 --scan just after plugging the hardware -> sigrok-cli-scan-kingst-la2016-linux-1st.log) flo. On 10/27/20 2:30 PM, Helge Kruse wrote: ... With this change I am able to upload the firmware. But the driver doesn't receive any data from the device. (see kingst.log) ... I would be interesting to see a successful operation with that device on a Linux PC hardware. Could you generate a similar log with "sigrok-cli --scan" and send it to me? sr: [00:00.01] log: libsigrok loglevel set to 5. sr: [00:00.77] backend: libsigrok 0.6.0-git-efce57da/4:0:0. sr: [00:00.000118] backend: Libs: glib 2.62.4 (rt: 2.62.4/6204:4), libzip 1.5.1, libserialport 0.1.1/1:0:1 (rt: 0.1.1/1:0:1), libusb-1.0 1.0.22.11312 API 0x01000106, hidapi 0.9.0, bluez 5.50, libftdi 1.4. sr: [00:00.000135] backend: Host: x86_64-pc-linux-gnu, little-endian. sr: [00:00.000148] backend: SCPI backends: TCP, RPC, serial, USBTMC. sr: [00:00.000159] backend: Firmware search paths: sr: [00:00.000188] backend: - /home/flo/.local/share/sigrok-firmware
Re: [sigrok-devel] Getting firmware for Kingston LA2016
I doubt that the USB pass through is fast enough, but I will give it a try. I found that the driver libsigrok/src/hardware/kingst-la2016/protocol.c sends one of two commands: unknown_cmd1_340 unknown_cmd1_342 depending on the firmware file size. The name of the variables suggest that the driver author (Florian Schmidt) doesn't know exactly the meaning of the commands. So it might be necessary to send the matching commands, that are specific at least for the versions 3.4.0 and 3.4.2. The vendor software at the CD is 3.4.1 and the currently available download software version is 3.4.3. I fear that there are differences in the firmware versions and the commands necessary to communicate with the device. Does anybody know where I can get the vendor's public available installer software 3.4.2? Best regards, Helge -Original Message- From: Paul Fertser [mailto:fercer...@gmail.com] Sent: Tuesday, October 27, 2020 5:39 PM To: Helge Kruse Cc: sigrok-devel@lists.sourceforge.net Subject: Re: [sigrok-devel] Getting firmware for Kingston LA2016 Hey! On Tue, Oct 27, 2020 at 02:30:42PM +0100, Helge Kruse wrote: > I am not sure what configuration should be set here. I would be interesting > to see a successful operation with that device on a Linux PC hardware. Could > you generate a similar log with "sigrok-cli --scan" and send it to me? I do not have this device so can't send you a log, unfortunately. I can only suggest to try a LiveCD/LiveUSB system with GNU/Linux or probably use a VM and USB pass-through and that would be the most direct way for you to see where the things go differently as you'll be able to do as many tests as needed. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
Re: [sigrok-devel] Getting firmware for Kingston LA2016
Hey! On Tue, Oct 27, 2020 at 02:30:42PM +0100, Helge Kruse wrote: > I am not sure what configuration should be set here. I would be interesting > to see a successful operation with that device on a Linux PC hardware. Could > you generate a similar log with "sigrok-cli --scan" and send it to me? I do not have this device so can't send you a log, unfortunately. I can only suggest to try a LiveCD/LiveUSB system with GNU/Linux or probably use a VM and USB pass-through and that would be the most direct way for you to see where the things go differently as you'll be able to do as many tests as needed. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
Re: [sigrok-devel] Getting firmware for Kingston LA2016
I have built with cross-compiler mingw for the target platform (Windows). I have patched the mentioned fragment to ignore the error in libusb_set_configuration. With this change I am able to upload the firmware. But the driver doesn't receive any data from the device. (see kingst.log) The patch ignores the return value of libusb_set_configuration(). All further calls to the USB library are successful: ezusb_reset(hdl,1) ezusb_install_firmware(ctx, hdl, name) ezusb_reset(hdl,0) I am not sure what configuration should be set here. I would be interesting to see a successful operation with that device on a Linux PC hardware. Could you generate a similar log with "sigrok-cli --scan" and send it to me? >Probably ez-usb devices were never properly tested on Windows. >Another option would be using some other external program to upload >this firmware to EZ / FX2 chip you have. Well, at least the log tells me that the firmware upload was successful. Best regards, Helge -Original Message- From: Paul Fertser [mailto:fercer...@gmail.com] Sent: Sunday, October 18, 2020 12:08 PM To: Helge Kruse Cc: sigrok-devel@lists.sourceforge.net Subject: Re: [sigrok-devel] Getting firmware for Kingston LA2016 On Sun, Oct 18, 2020 at 11:46:43AM +0200, Helge Kruse wrote: > Anyway, the nightly build should support the LA2016. The --scan result is > attached. The essential lines are probably: > sr: [00:01.403000] kingst-la2016: Found a LA2016 device. > sr: [00:01.403000] kingst-la2016: device at 'usb/2-8' has no firmware > loaded! > sr: [00:01.404000] ezusb: uploading firmware to device on 2.11 > sr: [00:01.405000] ezusb: Unable to set configuration: > LIBUSB_ERROR_INVALID_PARAM Good progress. I suggest you comment out this if block: https://sigrok.org/gitweb/?p=libsigrok.git;a=blob;f=src/ezusb.c;h=c2d270c4f8 5164298f626aa7de3826bc8e1ddd80;hb=f2cd2debf9dcbf0e83ec70d8ea41d8421a400dfd#l 126 This might be related to https://github.com/libusb/libusb/issues/743 Probably ez-usb devices were never properly tested on Windows. Another option would be using some other external program to upload this firmware to EZ / FX2 chip you have. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com kingst-la2016.log Description: Binary data ___ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
[sigrok-devel] Submitting again: Fix calibration frequency for scopes
Hi Uwe, hi sigrok team,
Just a reminder - I've submitted this fix for FX2 based scopes already
half a year ago.
If you do not like the extra frequencies, please correct at least the
100, 1000 and 1 Hz values, 50 kHz doesn't work with 12 MHz CPU clock.
Easy fix: The settings of RCAP2 must be half as big in function "static
BOOL set_calibration_pulse(BYTE fs)"
https://github.com/sigrokproject/sigrok-firmware-fx2lafw/blob/b6ec4813b592757e39784b9b370f3b12ae876954/include/scope.inc#L265
There is also a small typo in line 276 (comment should read "10kHz").
Martin
Weitergeleitete Nachricht
Betreff:Fix calibration frequency for scopes
Datum: Tue, 7 Apr 2020 21:01:37 +0200
Von:Martin Homuth-Rosemann
An: sigrok-devel@lists.sourceforge.net
Hi Uwe, hi sigrok team,
The initial setting of the calibration frequency output (1 kHz)of the
FX2-based scopes is ok, but as soon as the user sets the frequency via
'set_calibration_pulse()' the output frequency is only half the
requested value, probably due to a recent change of CPU_FREQ from 24 to
12 MHz. The settings of RCAP2 must be half as big (see also
https://github.com/sigrokproject/sigrok-firmware-fx2lafw/commit/14728a53624f000db0fa8388ecdb8b021250322b).
Martin
PFA the patch that fixes the behaviour and adds also more frequency
choices (this is used in my OpenHantek6022 project).
--- a/include/scope.inc
+++ b/include/scope.inc
@@ -263,24 +263,54 @@ static BOOL set_samplerate(BYTE rate)
}
static BOOL set_calibration_pulse(BYTE fs)
-{
+{ // values for CLK_12M
switch (fs) {
- case 0: // 100Hz
+ case 105: // 50Hz
RCAP2L = -1 & 0xff;
RCAP2H = (-1 & 0xff00) >> 8;
return TRUE;
- case 1: // 1kHz
+ case 106: // 60Hz
+ RCAP2L = -8333 & 0xff;
+ RCAP2H = (-8333 & 0xff00) >> 8;
+ return TRUE;
+ case 0: // 100Hz
+ case 110: // 100Hz
+ RCAP2L = -5000 & 0xff;
+ RCAP2H = (-5000 & 0xff00) >> 8;
+ return TRUE;
+ case 120: // 200Hz
+ RCAP2L = -2500 & 0xff;
+ RCAP2H = (-2500 & 0xff00) >> 8;
+ return TRUE;
+ case 150: // 500Hz
RCAP2L = -1000 & 0xff;
RCAP2H = (-1000 & 0xff00) >> 8;
return TRUE;
- case 10: // 1kHz
- RCAP2L = (BYTE)(-100 & 0xff);
+ case 1: // 1kHz
+ RCAP2L = -500 & 0xff;
+ RCAP2H = (-500 & 0xff00) >> 8;
+ return TRUE;
+ case 2: // 2kHz
+ RCAP2L = -250 & 0xff;
+ RCAP2H = (-250 & 0xff00) >> 8;
+ return TRUE;
+ case 5: // 5kHz
+ RCAP2L = -100 & 0xff;
+ RCAP2H = (-100 & 0xff00) >> 8;
+ return TRUE;
+ case 10: // 10kHz
+ RCAP2L = (BYTE)(-50 & 0xff);
RCAP2H = 0xff;
return TRUE;
- case 50: // 50kHz
- RCAP2L = (BYTE)(-20 & 0xff);
+ case 20: // 20kHz
+ RCAP2L = (BYTE)(-25 & 0xff);
RCAP2H = 0xff;
return TRUE;
+// setting for 50 kHz doesn't work, gives 25 kHz (interrupt fires too often?)
+// case 50: // 50kHz
+// RCAP2L = (BYTE)(-10 & 0xff);
+// RCAP2H = 0xff;
+// return TRUE;
default:
return FALSE;
}
___
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
