chipKIT® Development Platform

Inspired by Arduino™

Fubarino SD USB issues after programming

Created Tue, 30 Dec 2014 13:36:15 +0000 by Becherraecher

Becherraecher

Tue, 30 Dec 2014 13:36:15 +0000

Hi

I am playing with my Fubarino SD at the moment. Everytime I upload code the Fubarino and my laptop are loosing their connection and I have to switch the USB-Port to get it running again.

I admit I only have one USB3 port at my machine and am using a USB hub. But it doesn't matter if I have connected it directly to the laptop or via USB hub. After every upload I have to change the USB port to get it back in device manager.

I'm getting this behaviour with MPIDE in the newest test build ('builds/mpide-0150-windows-20141104-test.zip') and also with the priorly used version ('builds/mpide-0023-windows-20140316.zip'). No difference. I also exchanged the drivers from the 20140316-version with the newest ones. no success.

I'm using a win 8.1 64bit system.

I'm playing around with the HW-UARTs at the moment. The Fubarino is directly connected to an Arduino Uno via Serial1 (Pins 28/29 because 5V tolerant). It recieves serial data on serial1 and should forward that to the regular serrial port (usb-serial).

Here is the sketch:

int count = 0;
char data[6] = "";

void setup(){
 Serial.begin(115200); 
 Serial1.begin(115200);
 
 pinMode(PIN_LED1, OUTPUT);
}

void loop() {
   digitalWrite(PIN_LED1, LOW);
 
  if (Serial1.available() > 0)
  {
     data[0] = Serial1.read();
     Serial.print(data[0]);
     //Serial.print(', ');
     //Serial.print(data[0] - '0');
     
     Serial1.print(count);
     Serial1.println(" rx. ");

     digitalWrite(PIN_LED1, HIGH);     
     delayMicroseconds (100);
    
     count++;
    }
    
    if(count == 10){
      count = 0;
    }
}

majenko

Tue, 30 Dec 2014 17:04:04 +0000

That's fairly normal for a Fubarino - especially in Windows. Because the USB serial connection is direct into the main chip, when the chip is reset it resets the USB connection. Windows doesn't like that much.

One thing you can do is to add a bit to your setup() so the Fubarino does nothing at all until you have connected your serial terminal to it. Adding this:

while (!Serial);
delay(100.);

will make it wait until you have opened the serial connection, and also a small delay to allow the screen to be ready to display the data it's getting (not really needed, but I find it helps).

Becherraecher

Tue, 30 Dec 2014 18:34:10 +0000

Hi majenko

Thank you for the detailed answer. Always nice to learn more about the backgrounds. I will try the fix with the delay in the setup.

But when I understood you correctly it is normal for a fubarino to disappear after an upload from the device manager? It is expected that it also looses it's USB connection, block that USB port to the system and it is mandatory to connect it to another port? Little bit strange and not very inviting for newcomers.

I personally think the Fubarino would be an exellent board and has a lot of potential also because of 32bit and speed, but that programming behaviour is a real disadvantage compared to other boards like Arduino.

majenko

Tue, 30 Dec 2014 19:15:12 +0000

My personal favourite fix for it is to not use Windows :)

So yours is allocating a different COM port for the two modes of operation? Runtime and bootloader?

That is something that it shouldn't be doing. Take a look in the device manager and check the details of the device in the two different modes. Especially details from the USB descriptor, such as the iManufacturer, iProduct and iSerial. they should match between the two. If there is a difference (especially in the serial number) Windows will allocate a new COM port. It's a bit retarded like that...

majenko

Tue, 30 Dec 2014 20:04:48 +0000

Actually, looking at it, there may be a subtle difference between the two modes... In bootloader mode the device is known as an Stk500v2. In running mode it's known as an stk500v2 - small difference, but it might upset things.

Look for the file [color=#408000]hardware/pic32/cores/pic32/HardwareSerial_cdcacm.c[/color] and find the line:

#define CDCACM_PROD "stk500v2"

and change the s to an S to see if that helps things be a little better.

Becherraecher

Tue, 30 Dec 2014 22:51:26 +0000

Hi majenko

Thank you again for your fast answers and your effort.

I have modified sketch and c-file in hardware folder of IDE. Not better.

And I think I have explained the problem not well enough: I can program fubarino one time and access [color=#A0A0A0](strange dec-style)[/color] serial output [color=#A0A0A0](but only with Arduino IDE serial console. MPIDE serial console is always crashing)[/color]. And when I try to upload the next sketch and press program and reset buttons on Fubarino then the board is not reachable by MPIDE. I get a "choose serial port for upload" window after some seconds and after some more seconds windows is reporting that usb device could not be recognized correctly. Error: 'The USB device returned an invalid USB configuration descriptor' Additional info of device manager: 'Unknown USB device (device descriptor request failed)' device ID: USB\VID_0000&PID_0002\6&1EF937C0&1&2

I think it looks really more like a windows driver issue relating to the 'USB programming device <-> main chip device' behaviour after resetting Fubarino into program mode several times when connected to the same USB port. (vendor = 0000 doesn't look like a correct value)

My old laptop with parallel windows/linux travelled to the kids of my brother 3 weeks ago. So I guess I'm stuck with win8.1 because no stable linux for uefi 32bit bootloader of my tablet. (Yeah, virtual machines... maybe on the next holidays)

mikes

Wed, 31 Dec 2014 01:00:40 +0000

Are you pressing reset while the Serial terminal is open?

I know that problem if I reset the board with the port open, I need to unplug and replug in the USB for the computer to recognize it again. If I close it first no problem.

Becherraecher

Wed, 31 Dec 2014 17:23:06 +0000

To be honest: I don't know. Thanks for the tip. Will leave an eye on that and report back my experiences.

GrahamM242

Thu, 01 Jan 2015 10:32:44 +0000

Yes, making the USB serial port go away (by resetting/unplugging), while an app has it open causes much weirdness on Windows. I have found I've had to terminate the application that had the port open, replug the USB device, and then restart the app in order to get communication to occur again.

This seems to be a general rule for USB serial, not just Fubarino!

pito

Thu, 01 Jan 2015 12:47:31 +0000

I am using XP with fubarino SD. After Upload I have to reopen ie. TeraTerm as the connectivity is lost (but reopen it after the connectivity is on again, it takes few seconds). I must not reinsert the usb plug or mess with coms . It will stay at the same comX. With uecide you have to close the terminal, upload to fub, reset fub, open the terminal. You must wait until win recognizes the usb is up again (after fub is reset), before opening the terminal. I did it in summer last time and getting senile, so take it without warranties of any kind :P PS> I would avoid 8.1 as it seems to me it has got problems with "older" HW (ie 8y old PC amd64 dual core, works great with W7 32/64b).

madias

Thu, 01 Jan 2015 15:37:12 +0000

If you have on the PC one USB Port left and on the fubarino two pins left, buy a cheap (1-2USD) TTL-USB Converter from aliexpress/ebay. Define the two pins as Serial1 or Serial2 and get rid of the annoying opening/closing/connect/disconnect procedure :)

pito

Thu, 01 Jan 2015 16:53:21 +0000

Do we have an "arduino like" serial (not usb) based bootloader? That would be nice to have, indeed.. For a standalone apps you do not need usb running, moreover, switching the usb module off may conserve power a little bit. :)

majenko

Thu, 01 Jan 2015 16:54:25 +0000

Yes of course we do. All the chipKIT boards with an FT232 chip use it.

pito

Thu, 01 Jan 2015 16:57:32 +0000

REALLY?? I've never tried that, grrh.. :shock: :o I am using HC-05's 3 pins Tx/Rx/100nCap for uploading to arduino. Will it work with fubarino as well?

majenko

Thu, 01 Jan 2015 17:00:08 +0000

If you change the bootloader, it might. You should try it sometime. The MAX32 bootloader might work if you're lucky - or compile your own using the bootloader sources from the github repo.

pito

Thu, 01 Jan 2015 17:05:04 +0000

Do you mean this? https://github.com/chipKIT32/PIC32-avrdude-bootloader That is an Xmas project, and Xmas is over, so I have to wait.. :D

PS: it will not work, we miss Reset on the header.. And playing the "hit the reset button at the proper time" game is something I would not recommend, I did it before the itead found the HC-05 trick with a module setting for 100n cap (wired to reset) pin.

majenko

Thu, 01 Jan 2015 17:10:20 +0000

Which header are you missing reset on?

pito

Thu, 01 Jan 2015 17:12:30 +0000

Yes, SD has got the reset pin on the header.. :lol: (not only senile but blind..) So it may work..

madias

Thu, 01 Jan 2015 17:28:52 +0000

If you change the bootloader, it might. You should try it sometime. The MAX32 bootloader might work if you're lucky - or compile your own using the bootloader sources from the github repo.

Does the compile of bootloaders work with the free version of XC32? I think you will run out of memory because there are no optimizations.

majenko

Thu, 01 Jan 2015 17:33:08 +0000

Some work, but not all. The smaller chips (150/250 etc) need the mips16 option which isn't in the free version in order to fit in the boot flash.

pito

Thu, 01 Jan 2015 17:37:13 +0000

The only board missing with async UART mode is our Fub SD 512k, of course :) BTW, does the loader work via resetting the cpu?? I see a "virtual program button" in the config file, assigned to an i/o pin instead.. So, do I need to press both of the buttons in order to start the upload?? That is not good, if it works that way.. :? The avrdude creates a reset signal (dtr/rts) at the dongle, that shall reset the pic32 and the upload shall start..

majenko

Thu, 01 Jan 2015 17:42:02 +0000

The virtual program button is for running the bootloader after a soft reboot, yes.

You can use it through the executeSoftReset() function:

executeSoftReset(ENTER_BOOTLOADER_ON_BOOT);

The virtual program button should be an IO pin that's not otherwise assigned, or wouldn't normally be used as an output (it uses the LAT register).

pito

Thu, 01 Jan 2015 17:50:09 +0000

Hmm.. My fub is running, blinking the green led and I want to upload a new sketch blinking the yellow led instead. So I compile and upload. The avrdude resets the pic32 (dongle's rts/dtr wired via 100n cap to pic32' reset pin) and uploads the new yellow sketch into, it resets automatically afterwards, and yet pic32 blinks the yellow led. Why shall I press any button then? That may work without any manual intervention (mind my fub is placed in a remote location).. 7.5 billions of happy arduino users are doing it that way.. I would go with a higher baudrate (ie 230k or 460k) as the sketches are usually larger, though. :)

majenko

Thu, 01 Jan 2015 18:44:28 +0000

You have a choice of LEDs to blink on the SD?

230400 is the fastest you will get out of avrdude IIRC. It's hard coded with that as a limit. Bit stupid really, but then that's avrdude for you.

Still, better than pic32prog that is still hard coded for only 115200 baud despite me pestering Serge to add a baud rate option to the option flags.

pito

Thu, 01 Jan 2015 18:45:16 +0000

You have a choice of LEDs to blink on the SD?

Yea, a showstopper, indeed :D

pic32prog that is still hard coded for only 115200 baud

Is it? Usb does not matter.. Does it support uart serial?

majenko

Fri, 02 Jan 2015 10:36:47 +0000

Serial is serial whether it's USB or real UART. On your inferior (outdated) windows XP machine they are all COM: ports. The software doesn't care.

As you note, with USB serial it doesn't "care" about the baud rate. Well, that's not strictly true. The CDC/ACM stack in the Fubarino doesn't care about the baud rate, but other USB serial systems do, such as any board with an FT232 (or equivalent) chip where the USB specified baud rate dictates the speed its external UART pins are set to. And of course that has to match the speed set in the bootloader for its UART communication.

GrahamM242

Fri, 02 Jan 2015 11:48:15 +0000

The avrdude creates a reset signal (dtr/rts) at the dongle, that shall reset the pic32 and the upload shall start..

On the Leonardo, which uses CDC over USB natively, avrdude opens the CDC and sets the baud to 1200. It then closes the CDC, which signals to the USB stack that a reset into the bootloader is required.

That might well ease some (not all!) of the issues that come up with serial ports being held open, as well as providing an automated reset process for any USB connected PIC32...

majenko

Fri, 02 Jan 2015 12:35:27 +0000

That relies on the USB stack always being loaded and active whether you are actually using it or not. We have discussed this very problem at length in the steerage group and decided in the end that it's not the best way of dealing with it, especially if your sketch should crash the chip and thus stop the whole USB system working - you still need a manual way to enter the bootloader. It's a common problem with said Leonardos etc that once the sketch has crashed the chip getting it to load the bootloader again can be a pain and is a matter of getting the timing right - something that is quite hard with Windows' shoddy USB system that takes so long to re-detect the board after any form of a reset. Best to lock it into the bootloader mode with a separate button. You can still remote-boot it by using the software reset and the virtual program button, should you want that facility, by programming support for it in your sketch.

pito

Sat, 03 Jan 2015 14:55:33 +0000

When talking back the original arduino concept with serial Rx/Tx and RST signals. Would that be a problem with a pic32 bootloader?? That works fine, cannot imagine a better approach.. (Not discussing how you get serial rx/tx signal - that is a different topic..)

majenko

Sat, 03 Jan 2015 14:58:04 +0000

Since that's exactly what the Uno32, Max32, WF32, WiFire, UC32, etc do... problem? I very much doubt it...

pito

Sat, 03 Jan 2015 17:15:11 +0000

Ok, I own Fub and a few dyi boards. I'm an uneducated hobb(y)i(s)t then.. So, with enough effort we may build a bootloader for FSD, which uses rst, tx/rx and does not need to mess with buttons.. :geek: