dwprog
dwprog copied to clipboard
mvirkkunen
standard serial support
I noticed some unused code for standard serial support (i.e. /dev/ttyUSB0). Are you planning on finishing that? If not, I'll probably fork your repo and do it myself since all of my USB-ttl adapters are non-FTDI (Pl2303hx & Ch340G).
The standard serial interface should actually work although I don't think I've used it in a while. The reason it's disabled is because it is really, really slow (FTDI is slow to begin with), although I believe this depends on drivers. The problem is that sending a "break" seems to send a really long break in some cases while a short one would work just fine. The protocol requires the serial breaks so they can't be completely avoided.
I just wrote this is a quick one-off tool, so it's missing a few features, but if there's interest I could develop it further. More device support would be nice (all that needs is the parameters for each one), and auto-bauding would take out some guesswork (not sure how easy that would be to implement in software).
dwprog.py is hard-coded to use FTDIInterface. It looks like you planned to support SerialInterface but either didn't finish or didn't push the changes. Regarding sending break, the simplest way is to lower the baud rate to < 1/3rd of the target baud rate, and send a null (zero). For example a null at 9600bps looks like a break to a target at 62.5kbps. Autobaud is tricky, especially if you want it to work with different ttl dongles like Pl2303 and CH340G.
On Fri, Mar 30, 2018, 18:44 Matti Virkkunen [email protected] wrote:
The standard serial interface should actually work although I don't think I've used it in a while. The reason it's disabled is because it is really, really slow (FTDI is slow to begin with), although I believe this depends on drivers. The problem is that sending a "break" seems to send a really long break in some cases while a short one would work just fine. The protocol requires the serial breaks so they can't be completely avoided.
I just wrote this is a quick one-off tool, so it's missing a few features, but if there's interest I could develop it further. More device support would be nice (all that need is the parameters for each one), and auto-bauding would take out some guesswork (not sure how easy that would be to implement in software).
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mvirkkunen/dwprog/issues/1#issuecomment-377628354, or mute the thread https://github.com/notifications/unsubscribe-auth/AFTc-pC_e1gHKQ2UKsFlvwqsWge75YEKks5tjqS2gaJpZM4TBwjm .
I just pushed a baud rate detector program: https://github.com/nerdralph/nerdralph/blob/master/autobaud.py With a Pl2303hx under Linux, it gets within 2-3% of the target baud rate.
Looks pretty nice! I guess you won't mind if I borrow the general idea of the algorithm? I didn't know about "break_condition" either, that might be faster than using the pySerial "send_break" directly and might make the FTDI interface pointless to begin with.
I think I can improve it by looking for the baud rate where I read back 5 0xF0 characters, which would be 5x the target baud rate. Regarding speed, I used the break on/off because it was much faster than send_break, which I had tried first. I may be able to make it even faster by sending a 0x00 at a baud rate lower than the target's, but so far I'm having problems with switching the port configuration back fast enough to read the 0x55 reply. Looking at it on my scope, there's only about 150uS between the end of break and the 0x55.
On Wed, Apr 11, 2018, 06:37 Matti Virkkunen [email protected] wrote:
Looks pretty nice! I guess you won't mind if I borrow the general idea of the algorithm? I didn't know about "break_condition" either, that might be faster than using the pySerial "send_break" directly and might make the FTDI interface pointless to begin with.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mvirkkunen/dwprog/issues/1#issuecomment-380454661, or mute the thread https://github.com/notifications/unsubscribe-auth/AFTc-jqHDGszcdesVM43JAzpjkjPz4Pdks5tngcvgaJpZM4TBwjm .
I tried the autobaud code and it seems to work pretty good!
Additionally using break_condition and standard pySerial it works just as fast as the FTDI specific interface, so I think I'll make standard serial the default.
In unrelated news I reviewed some of the flash writing code and by batching writes it became about 17 times faster. There's probably still room for optimization but it's a good start. Now I just have to clean the code up...
@nerdralph Would you mind giving this version a try? I deprecated the FTDI interface for now and made standard pySerial the default. With these optimizations writing is also much times faster on a PL2303 chip than the old FTDI interface. My tiny test program went from 83 seconds to just 3 seconds to flash. A 27-fold improvement!
When I have time (maybe later this week?) I'll put your better baud rate detection, and also finish working on a device database generator that I started working on a long time ago to generate devices.py from Atmel (Microchip?) data.
I'm travelling, so I'll test it out when I am back.
On Thu, Apr 12, 2018, 15:05 Matti Virkkunen [email protected] wrote:
@nerdralph https://github.com/nerdralph Would you mind giving this version a try? I deprecated the FTDI interface for now and made standard pySerial the default. With these optimizations writing is also much times faster on a PL2303 chip than the old FTDI interface. My tiny test program went from 83 seconds to just 3 seconds to flash. A 27-fold improvement!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mvirkkunen/dwprog/issues/1#issuecomment-380958593, or mute the thread https://github.com/notifications/unsubscribe-auth/AFTc-oQh8FStRR2ezCwbh-3S5jKUWzLoks5tn8-vgaJpZM4TBwjm .
I just tested it out, and there seems to be an intermittent bug in flashing.
Starting dwprog.
Getting target device properties.
Auto-detecting target device...
Opening debugWIRE interface...
Successfully opened /dev/ttyUSB0 at baudrate 71000
Target is: ATtiny13 (signature 0x9007)
Writing 3 pages (96 bytes) to target.
[################################# ] page 2/3...ERROR: Read timeout. Check connections and make sure debugWIRE is enabled.
This happens about 25% of the time. I didn't look at your code yet, but I did watch the communications on my scope. After power-up, you don't need to send a full break in order to activate debugwire; sending 0x00 is sufficient. I also see that you send a reset (0x07) before any commands. This is not necessary and slows things down, especially on devices with the 64ms SUT fuse set.
Is the baud rate exactly correct? Intermittent errors usually seem to be caused by that.
Resetting just seemed like a good idea. Does doing it cause more than 100ms or so of slowdown?
Baud rate should be within 1%, as I verified with my scope. I tried a couple baud rates and will try a few more to make sure.
The delay after reset is about 80ms.
On Fri, Apr 20, 2018, 16:29 Matti Virkkunen [email protected] wrote:
Is the baud rate exactly correct? Intermittent errors usually seem to be caused by that.
Resetting just seemed like a good idea. Does doing it cause more than 100ms or so of slowdown?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mvirkkunen/dwprog/issues/1#issuecomment-383198397, or mute the thread https://github.com/notifications/unsubscribe-auth/AFTc-hng2jfahwxQYz2_v1cWNRp59toyks5tqjcmgaJpZM4TBwjm .
On Apr 20, 2018 16:29, "Matti Virkkunen" [email protected] wrote:
Is the baud rate exactly correct? Intermittent errors usually seem to be caused by that.
Resetting just seemed like a good idea. Does doing it cause more than 100ms or so of slowdown?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mvirkkunen/dwprog/issues/1#issuecomment-383198397, or mute the thread https://github.com/notifications/unsubscribe-auth/AFTc-hng2jfahwxQYz2_v1cWNRp59toyks5tqjcmgaJpZM4TBwjm .
The problem doesn't seem to be related to the baud rate. It seems to be related to tty (serial) error handling such as break and frame/parity errors. As you may have noticed, termios2 is poorly documented in linux, and some of the documented termios flags do not seem to work as documented. For example framing and parity errors seem to be always ignored regardless of the ignpar tty flag setting. I don't think this is a bug in the pl2303 driver, as it does set flags for tty errors. https://github.com/torvalds/linux/blob/master/drivers/usb/serial/pl2303.c#L965
Although I haven't followed all the code from the driver up to the read() syscall, I think what may be happening is the tty stays in an error state after a break, and is not cleared until a read(). If the read doesn't happen until after the 0x55 sync byte is received, the sync gets dropped.
What I've done is change open so it sends 0x00 instead of a break. I've also removed all the calls to send_break except for those in write_flash_page, which I still have to work on.
With those changes I've been able to run over 1000 verify and identify operations without any errors. For testing I use a basic shell script:
count=1
while ./dwprog.py -q -b 71000 identify
do
echo run $count result: $?
count=$((count+1))
done
I just pushed an improved autobaud.py. After finding the rough baud rate, it tries 1.5% changes until it finds the exact baud rate (within +- 0.75%). If you don't mind waiting an extra second or two, you can change .985 on line 67 to .99, and get +- 0.5%.