Products > Test Equipment
Pocket-Sized 6 GHz 1 TS/s ET Scope
SJL-Instruments:
--- Quote from: joeqsmith on February 15, 2024, 03:30:43 pm ---What about a these? None are valid commands at the time it crashes.
3&4, I changed my test to run up till five failures so you can see how the scope only returns CH1 BAD responses.
I suspect you are going to spend a lot of time documenting outlier cases. IMO, it would be better to address the root problem. Once the communications are robust, you can start to build off that solid foundation.
--- End quote ---
The current manual (Section 4.5.1) states that issuing an H command with parameter below 40 will cause undefined behavior.
This will be caught and rejected when we add the bounds checking.
***
We are also restructuring the serial parser to be inherently more robust. We will perform our own fuzzing tests after the rewrite. When we are happy with the results of these tests, we can send you a prerelease firmware update if you'd like.
joeqsmith:
As I add more and more case statements to avoid having your scope lock up, it is running longer but I have yet to reproduce the spam problem.
At the time it did this, I was sending a 10-Byte payload + CR. I have change my test to now send variable payloads. Hopefully I can get it to repeat and trap it.
joeqsmith:
--- Quote from: SJL-Instruments on February 15, 2024, 02:58:04 am ---The first command is interpreted as "S2", since the third byte (0xDA) is non-printable and the rest of the command is ignored.
--- End quote ---
--- Quote from: SJL-Instruments on February 15, 2024, 03:41:14 pm ---The current manual (Section 4.5.1) states that issuing an H command with parameter below 40 will cause undefined behavior.
...
When we are happy with the results of these tests, we can send you a prerelease firmware update if you'd like.
--- End quote ---
s,S,h,H are not being sent, along with seven other codes that have cause the scope to hang. As you can see, it still hangs. Because your firmware seems to in some cases ignore the first byte of the command (7F,54 for example will interpret as a T), I now also prevent all of these cases on the second byte. Basically I will continue to increase the test cases until you provide improved firmware, or I find a combination that allows the scope to run long enough that the spam error repeats.
I have no problem running any prerelease firmware, now that I am setup to reprogram the device. FP stands for Field Programmable. As the product evolves, you may want to consider how to update the FPGA as well as the microcontroller across the USB interface. Guessing it would require a hardware change.
joeqsmith:
We used the 1708 serial interface for automotive. Something like a RS485/422. One of my motorcycles uses something similar. We were using J1587 protocol. We adopted a similar protocol for other industrial projects I have been involved with. The following link provides a simple overview of it:
https://www.kvaser.com/about-can/can-standards/j1587/
Note this is a very old standard but may still be in use today. It has certainly stood the test of time. Maybe have a quick read and see if there is something you can leverage from an existing standard like this.
joeqsmith:
Assuming that "Unknown command!"s are ignored and not causing the scope to hang, I have added a filter for them. Even with my 12 test cases in the two first fields, it will still hang.. Changing to the first three fields.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version