cihpkit issues on linux Mint 13

User avatar
majenko
Site Admin
Posts: 2165
Joined: Wed Nov 09, 2011 7:51 pm
Location: UK
Contact:

Re: cihpkit issues on linux Mint 13

Post by majenko » Sun Jun 12, 2016 12:24 pm

I have just installed a VM of Linux Mint 13. It has libusb 1 available, however it looks to be a rather old version (1.0.9), so you will need to upgrade it. I have just built it from source using the latest Debian Jessie source package (1.0.19). It takes a while to install all the build dependencies (it needs doxygen which has to install all of LaTeX in order to build the documentation), so I have made a "precise" repository for it. Both 32 and 64 bit versions are available.

Code: Select all

// Add to /etc/apt/sources.list:
deb http://majenko.co.uk/debian precise main
// Get the key:
$ wget -O - -q http://majenko.co.uk/debian/key.asc | sudo apt-key add -
OK
// Update apt:
$ sudo apt-get update
// Upgrade if libusb is already installed (if you don't do a dist-upgrade it keeps libusb back because it wants to install an extra package libusb-1.0-doc):
$ sudo apt-get dist-upgrade
// Or if it's not then install it:
$ sudo apt-get install libusb-1.0-0-dev
If you don't want to go through all that you can manually download and install the .deb files for 1.0.19: Now install the other dependencies you need for building:

Code: Select all

$ sudo apt-get install git build-essential autoconf libtool libudev-dev
You should now be able to build pic32prog:

Code: Select all

$ git clone https://github.com/sergev/pic32prog.git
...
$ cd pic32prog
$ make
You should now have a "pic32prog" binary in the current directory. You just need to copy that one over the one installed by chipkit-core. However, if you are using UECIDE 0.8.9-pre(x) you can just place it somewhere in your $PATH and use the "System Installed PIC32Prog" programmer which I have just created.

Alternatively, once you have libusb-1.0-0 version 1.0.19 installed, you can use one of the binaries attached to this post which I compiled on Mint 13.
Attachments
pic32prog-mint13-64.zip
(167.73 KiB) Downloaded 24 times
pic32prog-mint13-32.zip
(159.82 KiB) Downloaded 23 times
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

bperrybap
Posts: 48
Joined: Sat Nov 19, 2011 8:45 pm

Re: cihpkit issues on linux Mint 13

Post by bperrybap » Sun Jun 12, 2016 5:25 pm

majenko wrote:I2C: you do have pull-up resistors on your SDA and SCL lines don't you?
Of course.
I'm the one that exposed using the wire code after re-initalization (calling begin() again) was causing a hard hang and tracked it down due to the h/w getting falsely confused over clock stretching after the h/w was reinitialized.
So yes, I'm familiar with i2c.
--- bill

User avatar
majenko
Site Admin
Posts: 2165
Joined: Wed Nov 09, 2011 7:51 pm
Location: UK
Contact:

Re: cihpkit issues on linux Mint 13

Post by majenko » Sun Jun 12, 2016 5:30 pm

That's OK then. I just have to make sure of these things - many Arduino users don't know about pullups on I2C since the Arduino boards by default use the internal pullups, which really is very nasty. I suspected you probably did know more than enough to have pullups, but if I hadn't asked and in the end it turned out you didn't have them we'd both feel daft ;)

So can you post some example code that demonstrates the issue you are seeing?
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

bperrybap
Posts: 48
Joined: Sat Nov 19, 2011 8:45 pm

Re: cihpkit issues on linux Mint 13

Post by bperrybap » Sun Jun 12, 2016 6:00 pm

majenko wrote: So can you post some example code that demonstrates the issue you are seeing?
Sure, once I track it down and isolate it down to a small repeatable example.
I always like to fully understand the issue and often the fix and/or work arounds before reporting it.

The whole mint 13 thing is because I have older machine that I'm still using for some development until I fully cut things over to some new h/w.
But it is part of a much larger cutover involving much more than just this single machine & OS.
The systemd nightmare that has cropped up the past few years, along with the GTK2/GTK3 gnome2/gnome3 mess along with the recent desktop wars has really made a mess of linux (at least the debian based ones) over the past few years.
I do have other other machines running newer versions and often use VMs for development and testing across many different OSes but wanted to bring up that it seemed very odd have a commandline tool not work on such a mainstream LTS OS, especially since neither the Arduino IDE nor any other Arduino core has this issue/limitation.

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.


I'll track down the issues and post appropriate findings as either new threads or git issues, it is just that I'm in the final stages of trying to push out a new set of libraries and didn't want to get bogged down and dragged into toolset issues.

User avatar
majenko
Site Admin
Posts: 2165
Joined: Wed Nov 09, 2011 7:51 pm
Location: UK
Contact:

Re: cihpkit issues on linux Mint 13

Post by majenko » Sun Jun 12, 2016 6:25 pm

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 mint 13 and anything newer. The libraries on Mint 13 are just too old. It complains about not finding libudev.so.0 since libudev is now on 1.5.0 - a considerable increase from 0.whatever.itwas.

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.
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.
along with the GTK2/GTK3 gnome2/gnome3 mess along with the recent desktop wars has really made a mess of linux (at least the debian based ones) over the past few years.
That's why I run Debian. You don't suffer from that kind of thing when you're using the distro that all the other systems that are fighting between themselves are based on. Yes, it can be a bit sluggish with updates, but you don't get the stupidity that you get with some - especially how Ubuntu keep breaking package dependencies with their idiotic version extensions and requiring precise version numbers in their packages. Plus Debian doesn't impose a desktop on you. You just install the one you want to use. At the moment I'm using KDE since it works well with my dual video cards. It's not my favourite, but it works.
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.
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

bperrybap
Posts: 48
Joined: Sat Nov 19, 2011 8:45 pm

Re: cihpkit issues on linux Mint 13

Post by bperrybap » Sun Jun 12, 2016 9:14 pm

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

void setup()
{
    delay(5);
    Serial.begin(9600);
}

void loop()
{
    Serial.println("Hello, World");
    Serial.println("-------------------------------------------------");
    delay(1000);
}
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.

--- bill

User avatar
majenko
Site Admin
Posts: 2165
Joined: Wed Nov 09, 2011 7:51 pm
Location: UK
Contact:

Re: cihpkit issues on linux Mint 13

Post by majenko » Sun Jun 12, 2016 9:32 pm

This definitely has something to do with the control of the DTR signal. I don't see it in UECIDE becuase the IDE itself manually toggles DTR and all is well.

If you run pic32prog manually, the first time it uploads properly. However it seems to then leave the DTR in a bad state and it won't reset the board from then on.

Using the stty -F /dev/ttyUSB0 hupcl command resets the port to the right state, and pic32prog will work again - once.

I need to take a look and see what it is doing with the serial port to see why the DTR is getting locked out like that.
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

User avatar
majenko
Site Admin
Posts: 2165
Joined: Wed Nov 09, 2011 7:51 pm
Location: UK
Contact:

Re: cihpkit issues on linux Mint 13

Post by majenko » Sun Jun 12, 2016 9:41 pm

Found a bug that meant the serial port's settings weren't getting restored properly under some circumstances. PR submitted.
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

User avatar
majenko
Site Admin
Posts: 2165
Joined: Wed Nov 09, 2011 7:51 pm
Location: UK
Contact:

Re: cihpkit issues on linux Mint 13

Post by majenko » Sun Jun 12, 2016 9:44 pm

I guess more libraries could be statically compiled into pic32prog instead of relying on dynamic libraries - that's probably what avrdude does.

The only reason you need to have a more up to date libusb1 to compile pic32prog is that it happens to use some particularly low-level calls that aren't in the older version. This is specifically for a bit-banged FT232 based ICSP programmer. It was that which was using libusb0 before, and upgrading it to libusb1 had to use some functions that had only recently been added.
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

User avatar
majenko
Site Admin
Posts: 2165
Joined: Wed Nov 09, 2011 7:51 pm
Location: UK
Contact:

Re: cihpkit issues on linux Mint 13

Post by majenko » Sun Jun 12, 2016 9:48 pm

The only thing that can't be statically linked, it seems, is libudev - and that makes sense, since it is tied into the operating system at a low level and if you try using the wrong version then all hell will break loose.
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

Post Reply