Bug/inconsistency with propeller detection on Linux
pedward
Posts: 1,642
I tried 3 different boards, the PropKEY and Quickstart reliably only detect every other attempt. I hit "run", it works, "hit run", no worky, "hit run", it works, etc. The Protoboard USB worked about 3 times in a row, then got a not-detected error.
I'm putting this out there to see if anyone has any ideas or suggestions of what the root problem is, I plan on tracking it down. I've written reliable serial code for Linux before, so that's not a stretch for me.
I'm putting this out there to see if anyone has any ideas or suggestions of what the root problem is, I plan on tracking it down. I've written reliable serial code for Linux before, so that's not a stretch for me.
Comments
With Catalina, the main problem on Linux appears to be a simple timing issue. I have found that using the "nice" command (and also being more generous with read timeouts) ups the reliability to near 100%. Without that, I see similar results to those you are reporting.
For example, instead of: On Linux I generally have to say:
(Note that payload is a Catalina-specific command, and the -t option sets the read timeout in ms - I don't know the equivalent PropGCC commands).
Ross.
Steve, I'm using a distro, so it looks like I should update the distro and try again.
Does propeller-load use select for comms detection and timeout?
Yes, it does.
I have intermediate distributions or just propeller-load binaries if you want to try that.
I don't think the timing issue is related to sending or receiving individual characters - the normal buffering takes care of that adequately. I think the timing problem is related to the timing of things like toggling DTR and then sending the calibration bytes and then waiting for the response. Perhaps a more judicious use of buffer flushing would help, but select wouldn't make any difference.
Ross.
A hardware solution is to use a 10K resistor to weakly pull P30 (TX) up to Vdd. A software solution would be to have the PC receive everything during the handshake sequence, and search for the correct handshake sub-string. Jazzed's recent loader changes implement the software solution. Jeff has updated the Propeller Tool to fix this problem, too. Those Propeller Tool fixes will be rolled out with the next release of the Propeller Tool software.
I will look at adding the pullup and see if that fixes it. Just tried the 10k pullup, and that doesn't fix it.
I do note that every time it fails, SIDE is flushing a number of characters from the serial port, so SIDE is seeing something.
Perhaps the *real* problem is that the serial buffer has data in it on the OS and the port needs to be flushed first.
Perhaps:
Raise DTR
Flush
Lower DTR
Raise DTR
Detect
Curiously, because of the inline cap, you can't hold the prop in reset while you flush the port.
The first load always fails after some idle time, then all loads pass after that.
This is not the Quickstart oscillator problem.
--Steve
Thanks for the update Daniel - I'll do some experiments to check out your suggested fix. I have never experienced any problems with the Propeller tool, and on Linux I can make it very nearly as reliable without any hardware changes or buffer flushing just by tweaking the timing. But I suppose changing the timing could also change the likelihood of receiving garbage bytes back during the handshake sequence.
Ross.
No - sorry, does the hardware fix mentioned by Daniel apply only to that board? That might explain why I've not seen it.
Ross.
Yes ... so far. Quickstart is a unique and interesting board. There is much written about it here.
We must flush the garbage between sending the magic LFSR sync-up and the transmit-back serial streams.
Ok - thanks. I've not heard reports of any problems using Payload with the Quickstart, but I'll add a buffer flush in the next release (and make it optional).
Ross.
Let me know if you get a chance to try that loader. It solves my Fedora-17 issues.