majenko wrote:Well, you have all the tools you need there to get it working on Mint 13. Incidentally, the same pic32prog binary cannot run on both
pic32prog is more than just a serial STK500V2 protocol uploader. It also deals with a number of USB based programmers and other bootloaders, so the USB support is kind of integral to it. Yes, it could probably be re-written in huge chunks to not use some of the libraries, but you're still likely to run into similar problems with not having a library that it needs that's a new enough version.
avrdude also does more than serial transfers and uses libusb as well, but it doesn't have this issue.
I can run the avrdude binary on multiple platforms and even build avrdude from sources and not have issues like this.
The systemd nightmare that has cropped up the past few years,
I used to think so. Now, though, after building an ARM Linux distro from Jessie base and implemented a number of systemd targets and services for it, I find it a very nice clean system. I love it. It takes some getting used to, but it's really nicely integrated. It works really well.
systemd has some really nice features but from a security standpoint it is just plain scary. Just like SELinux. While they do make some things simpler and have interesting new management features and security capabilities they also push large amounts of trust out of the kernel and into userspace processes, and both make it trivial to hide back-doors that are easy to install and exploit and yet difficult to detect since they both include "useful" configuration options/capabilities that look secure and offer great management capabilities but can be easily silently compromised from the network, without ever touching the machine or any of its files or settings. They both allow malicious privileged processes or malicious network actors to be able to do things that can be used compromise security in ways that could never be done before.
i.e. from a functional stand point it doesn't matter where code runs (user space or kernel) but from an overall security standpoint it can make a big difference.
but all that is way off topic.
That and there seems to be some pic32prog uploading issues even on newer Mint versions (17.1) where everything "works".
It seems to be related to opening multiple IDE windows and possibly aggravated by switching between different boards/cores - which I happen to do quite often during my testing.
Is that the locking up the port thing you mentioned earlier? Does the stty command unlock it for you? It'd be interesting to know if it is clobbering the hupcl setting, and to track down just where it's coming from. It may be something from deep inside Java though. It's not something I seem to see with UECIDE, so it may be specific to the Arduino IDE. Maybe something to help get around the complete ****up they made with FTDI based boards in 1.6.8.
So I tracked this down a bit more.
the stty command doesn't help in this case, it merely resets the target chipKIT board.
When in this state, during the upload, there is some traffic going to the UNO32 and ld1 blinks 3 times then pic32prog reports:
"No Target Found"
It appears to be related to serial output.
Here is a minimal sample sketch that triggers this issue.
// test for pic32prog upload issue
Code: Select all
upload the sketch and let it run for a few seconds.
You will see ld2 blink each time the data squirts out of the pic32.
However after about 4 iterations, something changes (maybe the FTDI usb buffer fills) and the led ld2 stops blinking.
At this point uploads will fail.
The only way out of this, is to:
- pull the cable, re-attach it
- start another upload after the "no target found" error while ld4 is still blinking
In either case above you must do an upload while ld4 is still blinking before the sketch has run and fills up buffers inside the FTDI chip.
If you wait until the ld4 is no longer blinking and ld2 has stopped blinking, you can never upload a sketch and you will get the "No Target Found" error.
NOTE: pressing reset on the board does not fix this.
Of curious interest is that If you set the baud rate to 115200 it does not fail.
It is looking like there is some kind of issue in pic32prog with the way it handles the port.
Maybe it doesn't flush out the old FTDI buffered serial data correctly?
I don't know, but that should be enough to replicate it and track it down.
On a Arduino AVR Uno board I have that uses the FTDI chip, the transmit led behaves the same but avrdude does not have this issue.
avrdude can reset and upload the AVR Uno board just fine even after the FTDI transmit led has stopped blinking.