PinguinoOTG USB access on Kubuntu

Hello, Please accept my apologies if this is a silly question. I get the following message when I put the PinguinoOTG board in bootloader mode:

class org.uecide.UsbHidDevice cannot be cast to class java.lang.Comparable (org.uecide.UsbHidDevice is in unnamed module of loader 'app'; java.lang.Comparable is in module java.base of loader 'bootstrap')

Also no Devices show up in Uecide. I have followed your blog post on troubleshooting ACM and USB access with the following result:

ap@ap-KJ336AA-ABG-s3480a:~$ id uid=1000(ap) gid=1000(ap) groups=1000(ap),4(adm),20(dialout),24(cdrom),27(sudo),30(dip),46(plugdev),121(lpadmin),131(lxd),132(sambashare) ap@ap-KJ336AA-ABG-s3480a:~$ ls -l /dev/ttyACM* /dev/ttyUSB* ls: cannot access '/dev/ttyACM': No such file or directory ls: cannot access '/dev/ttyUSB': No such file or directory ap@ap-KJ336AA-ABG-s3480a:~$ lsusb Bus 001 Device 003: ID 058f:6377 Alcor Micro Corp. AU6375 4-LUN card reader Bus 001 Device 002: ID 0846:6a00 NetGear, Inc. WG111v2 54 Mbps Wireless [RealTek RTL8187L] Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 008: ID 04d8:003c Microchip Technology, Inc. USB HID Bootloader Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Other boards work well, ChipKit Lenny, no problem, ChipKit Max32..... It is not a Uecide problem but I think rather an access to the USB issue...

Thank you for any help you can give. Uecide 0.11.8 on Kubuntu 20.04 64 bit


The major problem with the

The major problem with the pinguino boards is that they don't use the normal chipKIT bootloader. They use their own bootloader (which is actually fatally flawed in a couple of ways, but if you're careful it survives...) and when in bootloader mode there is no UART - instead it's a HID bootloader using its own protocol.

You won't get anything in the ports menu when it's in bootloader mode simply because there's nothing to show.

The device in your USB list is:

04d8:003c Microchip Technology, Inc. USB HID Bootloader

and you have to ensure that your user has access to that device using a udev rule. I have, in /etc/udev/rules.d/50-boards.rules:

SUBSYSTEM=="usb", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="003c", MODE="0666", GROUP="dialout"

which should ensure that you have access to the device.

It's not a bootloader I have used in some time, and I'd recommend replacing it with the chipKIT bootloader instead (I think this is the right one) so you get the same experience as the other boards and don't have the fatal flaw that the bootloader can erase itself that the original one has (yes, I had that happen to me in working on support for the Pinguino...)

Hello Matt, thank you I have

Hello Matt, thank you I have a 50-olimex.rules although I have the GROUP="plugdev" I will try with dialout tomorrow. I taught first year engineering students using Uecide and the PinguinoOTG boards as they come with the factory bootloader. I had good success with them and they survived some rough treatment. The latest Uecide is very nice to use. Regards Anthony

plugdev and dialout should

plugdev and dialout should have the same effect - the default user is usually a member of plugdev normally anyway, so that should be fine.

I should see if I can dig out a copy of the original Olimex bootloader and put it back on my OTG board to see if it still works with current UECIDE versions - but it's not really UECIDE that cares, more the config files and pic32prog.

I have Uecide 10.5 on

I have Uecide 10.5 on Elementary on another machine that I am retiring hence the new setup, are there files I could copy over?

And this non-workingness is a

And this non-workingness is a change from the old 0.10.8? I shall have to have a play and see if something has changed that would affect it...


Yes After the PonguinoOTG board is programmed with a serial output(by the Uecide 0.10) it shows up in the new system with the serial monitor working. So your right it is in the config or pic32prog when trying to program the board that it fails

My next job, of course, is to

My next job, of course, is to find my PICkit2, then solder in some wires to the OTG as it has a silly tiny ICSP header that I have no connector for...

Ok, so I've modded the board,

Ok, so I've modded the board, and installed a bootloader. Not sure it's the original one - the one for the MX440 doesn't work, but the one for the MX460 does - and this is an MX440...

Still, it identifies as 04d8/003c. I then write a program (blink) with the OTG selected and PIC32PROG as the programmer - hit upload, it compiles and uploads to the board.

Yes, I get that java error, but that can be ignored, it's irrelevant.

Once uploaded it has a CDC/ACM device by default and shows up in the devices menu.

It not showing up in the devices menu isn't an error - it's just it not presenting any suitable device for UECIDE to know about. But UECIDE doesn't care, it just runs pic32prog which then goes and finds the bootloader by the USB VID/PID.

Hello Matt,

Hello Matt, I have attached a couple of screenshots to show you what is happening. You will see that on upload it says No Target Found, the Device is left over from when it is not in bootloader and sending to the serial It seems pic32prog is not finding the bootloader.... Regards Anthony


The output tab should show

The output tab should show you what exact command is being run (you may need to turn the verbose command output on in preferences). It's very strange that the lenny is saying no target found too...

Hello, I was able to program

Hello, I was able to program the Lenny using the pic32prog with 1200 baud reset, however this does not work with the PinguinoOTG I have also attached the Pinguino bootloader as a txt file....


Hello Matt,

Hello Matt,

My old system running Uecide 0.10.6 on Elementary 64 bit programs all the boards... Trying to program the Lenny with pic32prog:

/home/ap/Documents/UECIDE/compilers/pic32-tools/bin/pic32-g++ -c /tmp/build-6b020862-d492-4c84-a969-b960d8783b3b/SerialComsDemo_combined.cpp -o /tmp/ build-6b020862-d492-4c84-a969-b960d8783b3b/SerialComsDemo_combined.cpp.o -mprocessor=32MX270F256D -Os -DF_CPU=40000000L -DARDUINO=157 -D_BOARD_LENNY_ -DMPIDEVER=10001932 -DMPIDE=157 -DIDE=UECIDE -mips32r2 -D__USB_ENABLED__ -D__USB_CDCACM_KM__ -D__SERIAL_IS_USB__ -w -G1024 -g -fno-exceptions -ffunc tion-sections -fdata-sections -mno-smart-io -mdebugger -Wcast-align -fno-short-double -std=gnu++11 -I/home/ap/Documents/UECIDE/cores/chipkit/pic32 -I /home/ap/Documents/UECIDE/boards/chipKIT/chipkit-lenny -I/tmp/build-6b020862-d492-4c84-a969-b960d8783b3b -I/home/ap/Documents/UECIDE/UECIDEsketch/Ser ialComsDemo

/home/ap/Documents/UECIDE/compilers/pic32-tools/bin/pic32-g++ -mprocessor=32MX270F256D -Os -DF_CPU=40000000L -DARDUINO=157 -D_BOARD_LENNY_ -DMPIDEVER =10001932 -DMPIDE=157 -DIDE=UECIDE -mips32r2 -D__USB_ENABLED__ -D__USB_CDCACM_KM__ -D__SERIAL_IS_USB__ -w -G1024 -Wl,--gc-sections,-Map,/tmp/build-6b 020862-d492-4c84-a969-b960d8783b3b/ -mdebugger -mno-peripheral-libs -nostartfiles -T /home/ap/Documents/UECIDE/cores/chipkit/pic32/ chipKIT-application-32MX270F256.ld -T /home/ap/Documents/UECIDE/cores/chipkit/pic32/chipKIT-application-COMMON.ld /home/ap/Documents/UECIDE/cores/chi pkit/pic32/cpp-startup.S -o /tmp/build-6b020862-d492-4c84-a969-b960d8783b3b/SerialComsDemo.elf /tmp/build-6b020862-d492-4c84-a969-b960d8783b3b/Serial ComsDemo_combined.cpp.o -L/tmp/build-6b020862-d492-4c84-a969-b960d8783b3b -L/home/ap/Documents/UECIDE/cache/chipkit/chipkit-lenny -Wl,--start-group - lCore_api -Wl,--end-group -lm

/home/ap/Documents/UECIDE/compilers/pic32-tools/bin/pic32-objcopy -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --ch ange-section-lma .eeprom=0 /tmp/build-6b020862-d492-4c84-a969-b960d8783b3b/SerialComsDemo.elf /tmp/build-6b020862-d492-4c84-a969-b960d8783b3b/SerialC omsDemo.eep

stdin /tmp/build-6b020862-d492-4c84-a969-b960d8783b3b/SerialComsDemo.etx /home/ap/Documents/UECIDE/compilers/pic32-tools/bin/pic32-objdump -t /tmp/bu ild-6b020862-d492-4c84-a969-b960d8783b3b/SerialComsDemo.elf

/home/ap/Documents/UECIDE/compilers/pic32-tools/bin/pic32-objdump -t /tmp/build-6b020862-d492-4c84-a969-b960d8783b3b/SerialComsDemo.elf

/home/ap/Documents/UECIDE/compilers/pic32-tools/bin/pic32-bin2hex -a /tmp/build-6b020862-d492-4c84-a969-b960d8783b3b/SerialComsDemo.elf

stdin /tmp/build-6b020862-d492-4c84-a969-b960d8783b3b/SerialComsDemo.lss /home/ap/Documents/UECIDE/compilers/pic32-tools/bin/pic32-objdump -h -S /tmp /build-6b020862-d492-4c84-a969-b960d8783b3b/SerialComsDemo.elf

/home/ap/Documents/UECIDE/compilers/pic32-tools/bin/pic32-objdump -h -S /tmp/build-6b020862-d492-4c84-a969-b960d8783b3b/SerialComsDemo.elf

/home/ap/Documents/UECIDE/compilers/pic32-tools/bin/pic32-size -S /tmp/build-6b020862-d492-4c84-a969-b960d8783b3b/SerialComsDemo.elf

exec programmer.stk500v2.script

bullet Uploading with STK500v2 protocol

bullet2 Resetting board

port open 115200

port pulse

port close

bullet2 Uploading firmware

/home/ap/Documents/UECIDE/programmers/pic32prog/linux64/pic32prog -S -d /dev/ttyACM0 -b 115200 -p SerialComsDemo.hex
Copyright: (C) 2011-2015 Serge Vakulenko
2016-2017 Majenko Technologies
Programmer for Microchip PIC32 microcontrollers, Version 2.1.56

No target found.


Hello Matt,

Hello Matt, I have done a complete reinstall of kubuntu and installed uecide 0.11.8 by deb and now get the error: Unable to start process Cannot run program "/home/anthony/Documents/UECIDE/compilers/pic32-tools/bin/pic32-g++" (in directory "/tmp/build-e256d2dd-2fba-4448-96a9-be9b48eb0525"): error=2, No such file or directory Compiling Failed

Any help you can give would be great, thank you

I suspect the problem is just

I suspect the problem is just that it's not entering the bootloader at the right time? For the Lenny you need the special 1200 baud programmer variant (from the plugin manager) which may (or may not ;) ) work. For the OTG I have no idea, though 1200 baud with a bootloader may work - although that's really geared towards looking for a new UART port appearing.

The older version of UECIDE had the reboot code in the IDE itself. The newer version has moved it to a small script in the programmer instead. The 1200 baud programmer was really just an experiment. I guess I need to overhaul the main pic32prog programmer script and incorporate the different reboot systems into that one file. It shouldn't be too hard to do.

For now just manually enter the bootloader at the right time (press PROG on the Lenny, and (I think) hold the button and hit reset on the OTG) to program. I'm out for much of today, but may be able to look at an overhaul of the programmer config later tonight.

For chipKIT you must install 32-bit support (sudo apt-get install libc6-i386) as there is only a 32-bit version of the compiler available at the moment. We're fighting with Microchip to get a 64-bit version (also needed urgently for Catalina, which no longer has any 32-bit support at all), and I am (in what little spare time I have) looking at the possibility of migrating to a vanilla mipsel-unknown-elf gcc compiled by me, but that's a mammoth task and will require rewriting some parts of the core.

I'm thinking I have the wrong

I'm thinking I have the wrong bootloader on this Olimex board. I programmed it the other day fine, but today I can't get it to enter the bootloader, so it's probably not the right one.

I have rewritten the programmer though, and it works well for the lenny and the MAX32 that I've tried it with. I need to test it with this Olimex board though to confirm it's working right...

Actually, thinking about it,

Actually, thinking about it, this can never work. The chipKIT method for activating the bootloader through 1200 baud requires support from the bootloader, so it can't ever work with the Olimex bootloader. And without the right version of the bootloader to map the program button I can only program the board once.

Olimex's support for these boards is pitiful. The only copies of the bootloader that seem to exist are embedded in their (very out of date and unsupported) IDE, and those don't seem to even be the right ones.

So really, please switch to the chipKIT bootloader. It'll save you so much hassle in the long run.

Hello Matt,

Hello Matt, So the txt file(rename to .hex) I uploaded doesn't work? I have not got uecide working yet fully on my system, I have several of the PinguinoOTG boards and as you noted they are difficult to replace/reprogram the bootloader. Is it possible to copy the complete uecide data folder from one computer to another? You may have guessed I am a novice with Linux and am not sure what I am doing. My old system uecide0.10.6 on Elementary works very well, I program esp32, pinguino, chipkit, mikroelectronica... I will keep at it, thank you very much for your time and comments. Regards Anthony

I didn't see that file, sorry

I didn't see that file, sorry. I'll grab it and try it.

Yes, you can copy the data dir (~/.uecide) across systems. You could copy it to a new location so as not to replace your current one to try it, and use the --datadir=... flag to UECIDE to use the new location. That way you can have the "old" and "new" data directories existing in parallel.

I get the same results with

I get the same results with that HEX as I do with the MX440 HEX I got from digging in the IDE - absolutely nothing. But then, they're identical anyway, so that's to be expected :(


Working I did a fresh install of Kubuntu, installed libc6, installed uecide via app store, added uecide repository, copied over my working uecide (with everything in it) then via preferences/ locations directed uecide to the copied folder, All great, programed the PinguinoOTG straight away..... Thank you for your help Regards



I have a new version of the programmer & chipKIT boards in testing at the moment. I really could do with the right bootloader for this board though. I may have to tap you up for some testing in a bit instead.

An alternative is I could try writing a flash dumping sketch to try and pull the bootloader off your OTG board and program it onto mine - that may be a way of getting mine in the exact same state as yours. It shouldn't be too hard to arrange, especially as the OTG has an SD card slot built in. Maybe I'll have a play with that later.

Hello Matt,

Hello Matt, I have a Pinguino OTG and a Pinguino Micro that have wires soldered so I can use a Pickit3. I have programed both boards with a simple serial out demo using Uecide and the Pinguino bootloader. I have attached both read hex files (change ".txt to ".hex) and another bootloader hex that I think I saved some years back. I guess you can use these hex's and that they should put your boards in the same state as mine... I have also modified the board defs for the OTG and the Micro, for me they are working very well. I hope this helps Regards