Hi,
I have found the source file for the zketech driver
/src/hardware/zketech-ebd-usb/protocol.c
I see an issue in:
SR_PRIV int ebd_set_current_limit(const struct sr_dev_inst *sdi, float current)
Line 313/314 does nothing if the driver thinks current = 0 and the
request is zero. The issue with this if there is a comms error on the
first current=0 setting. Then the only way to get current = 0 is to set
it and then reset it. This is not robust. Looks like I need to do a get
of the code and work out how to compile to fix the driver.
A pointer to where the 2 second loop occurs would be handy.
Ta
Stuart
On 28/08/2021 2:59 pm, Stuart Tyler wrote:
Hi,
I am experimenting with smuview and beginning to debug the ZKE-EBD-USB
driver lockup issue.
My first step is to understand the system, and I wrote a test script
to see what smuview is getting as data.
The idea of this script is to look at the last sample and sample
number every 0.4s, to see if I can see the core sample rate. From this
I see the ZKE is being sampled every 2 seconds.
smuview_configkey_trial.py > zke-ebd-usb-test1.txt
How is this 2sec set in smuview? I dont see any control over the
sample rate. Am I missing reading about a setup parameter to control this?
Smuview print() observation: When I stop then start scripts, sometimes
print() starts to do double prints. Then stop and start again. print()
does tripple prints. See smuview-stop.start.txt
When I enable updating the ZKE load current and always write the same
current, the observed sample rate is still 2sec.
smuview_configkey_trial_set_current.py > zke-ebd-usb-test2.txt
When I enable the code to alternate writes of the current of 0.0A and
0.01A, every 0.4sec, I get an observed sample rate of the 0.4sec write
rate.
smuview_configkey_trial_change_current.py > zke-ebd-usb-test3.txt
There are a couple of surprises here for me:
1. it seems that the system code remembers what it sent last - and if
multiple requests of the same write data occurs, only the first one
occurs. This is bad when the underlying hardware has error checking
but no ack. If my application now needs to write zero current - and I
need to do this a few times to ensure it gets through, the system
seems to be now blocking the multiple writes to the hardware.
2. The sample data rate (say it is set to 2 seconds) - is now altered
if a write of the a config data occurs.
What I was expecting:
1. A sampling system that occurs irrespective of anything else - not
get additional data when writes occur
2. When the system is commanded to write something - the write occurs.
Not be blocked because the system thinks - well you just wrote that so
I wont send it to the hardware
What I think is happening in the zke-ebd-usb driver and hardware.
1. The zke-ebd-usb device consists of a pl23035A usb to uart IC, and a
st 8S003F3P6 microprocessor. The uart tx/rx and mcu reset pin is
easily accessible for debug and testing
2. When things go wrong and sigrok/zke device seem to lock up - the
comport device (Win10) is still present. Because the comport is still
there - the pl23035A and its device driver seems robust. The issues
seem to be at the sigrok zke-ebd-usb driver and timing of data
send/requests to the device
3. The mcu in the zke is a small micro - the timing of reads/writes to
it need to be managed. My observations with the supplier software is
that it is robust when time between messages are managed. I am going
to do an investigation on this and try to report back a number for
this. I expect the answer to be something like: Yes send a message, a
response will be returned within xxx ms. If a message has a response
or no response (many do), you should not send another message within
xxx ms.
I am about to get the scope out and study this more - but my smuview
observations looks likes that the sigrok zke-ebd-usb driver level is
not honoring delay times correctly to the device, and gets locked up /
confused about what responses to expect.
I can observe 2 types of failure modes:
One where a restart of smuview device attachment recovers
communications (remove_device then connect_device)
Session.remove_device(loaddev)
loaddev = Session.connect_device(LOAD_DEV_CONN_STRING)[0]
- I want to explore this fault. I think it starts to occur when a
communications fault occurs
The second where the zke-ebd-usb mcu stops responding. The reset pin
to the mcu can be pulled low with a press-button - and then the system
recovers
I am starting to get a handle on telling the two situations apart.
The first one is observable in running smuview_configkey_trial.py >
after some amount of time the 2sec sampling period just stops.
Understanding how the 2sec sampling is set up and what triggers it
would be nice to know. What should I watch to ensure the sampling
point is being triggered?
On the second one - how do I observe/debug at the lower level when
sigrok wants to send commands to the driver? Is there logs to look at
to see what is going on? Where is the source for zke-ebd-usb driver?
Any brief pointers to - yeah this is a known problem - read here
Or - no this is new - please provide more debug data - please read
here on how to get debug data the team needs
Regards
Stuart
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
