Announcement

Collapse
No announcement yet.

"USB Device Not Recognised" part-way through upload

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • "USB Device Not Recognised" part-way through upload

    Hi Guys,

    A little help please...

    I have two 4Duinos. If I use a single Arduino sketch and upload it to one of the 4Duinos, it uploads fine, no problem. If I upload the exact same sketch to the other 4Duino, it crashes part way through the upload and windows gives me a "USB Device not recognised" pop-up. This same code has uploaded to and worked perfectly on the same board which is now giving the error. (exact same code on exact same board)

    I then have to double-click the reset button and upload a short sketch, like "Blink" and this 'unbricks' the 4Duino. The led on pin13 blinks as expected, showing that the code has completely uploaded. All seems fine... board is visible under 'tools' and the com port shows up correctly... but then, if I try upload my sketch again, it crashes part way through the upload. I plug in the Second 4Duino again, and it uploads fine.

    It's very strange... It almost looks like the upload is forcing the 4Duino into 'bootloader' mode, which stops the sketch uploading. I'm wondering if it's a VID/PID problem in the bootloader??

    Is there any instruction or support on how to re-flash the bootloader to the Atmega32u4? Or otherwise, just a download link for the 4Duino-specific bootloader?

    I consider myself an 'intermediate-advanced' user and this has got me stumped. Not sure if it's something obvious which I'm missing? Night-release of Arduino perhaps?

    Any help would be much appreciated.

    Thanks!

  • #2
    Hi AMMS

    Sorry to hear you are having problems, certainly seems strange what you are describing, I haven't seen/heard of this issue before.

    Are you using Workshop4 or are you using the Arduino IDE to upload to your 4Duino?
    What is the version of the IDE you are using?

    You have only 1 4Duino plugged in at once, correct? Or do you have both 4Duinos connected at the same time, and you are just choosing which one to upload the sketches to?

    Does the Arduino IDE see them both the same, both showing as 4Duino?
    Can you successfully upload sketches just via the Arduino IDE with the Workshop4 IDE closed (ignore if this is irrelevant and you are not using WS4)?

    If you can double click the reset, then the correct bootloader seems to have been loaded in. And if the board is showing in device manager as a 4Duino, then the VID/PID must be right, as the 4D drivers for the 4Duino only look at our VID/PID combo. But you are welcome to try and upload them again if you want. The hex file is included in the JSON file download of the board, so you can just load the bootloader from the Arduino IDE like any normal Arduino board, using the ICSP header.
    Specifically the file is loaded here after you load up the JSON from the Arduino IDE:
    C:\Users\[USERNAME]\AppData\Local\Arduino15\packages\4D Systems\hardware\avr\1.6.12\bootloaders\caterina-4Duino\Caterina-4Duino.hex

    Keep us in the loop of how you get on

    Regards
    James

    Comment


    • #3
      Hi James,

      This is Graeme, by the way. Thanks for the reply.

      To answer your questions:

      a.) I am using Arduino IDE directly... version 1.6.12. And your JSON install files that I've installed are version 1.6.12. (I've tried all other 4Duino versions, ie 1.6.10 and 1.6.7 and they do the same thing)

      b.) Only one board plugged in at a time. To the same port. USB cable is in Com9 and I'm unplugging and plugging back in at the board end. I've tried this exercise both with and without a USB hub... same result.

      c.) I was previously able to upload the EXACT same sketch, through Arduino IDE, with this config, multiple times, without any problem.


      I think that I may have noticed something... So, the bootloader port usually enumerates one port number higher than the ordinary USB port, right? I'm on Com9, so bootloader goes to Com10.

      1.) I 'brick' the board.
      2.) I double-press reset for bootloader mode.
      3.) I quickly upload the blink sketch.
      4.) Sketch uploads fine, so all good. (No more "USB Device Not Recognized" error)

      BUT... Even though the board now seems to be detecting fine, the port number in Arduino IDE is still Com10, instead of Com9...

      So, the inference is that the chip is still somehow stuck in bootloader mode. If I unplug the board, leave it a while, then plug it back in, it still enumerates to Com10 (Bootloader port) instead of Com9, or gives me the "USB Device Not Recognised" error. No logical pattern.

      My next step is going to be to attempt to reflash the bootloader file and see if it makes any difference at all. I will also check the PCB for any dry joints, dodgy connections, etc. (I'm sure it's fine, but the problem is still so random.

      Any further advice/direction will be much appreciated.

      Thanks!

      Comment


      • #4
        Hi Graeme,

        No other ideas at this stage unfortunately.
        So you are using the production 1.6.12 release of the IDE, or have you loaded the Nightly? There are a few issues with the main release which the nightly fixed, but I am guessing they keep changing the nightly until the next release comes out. If you are still using the main release, maybe try downloading the nightly and overwriting the files with that, and see if it helps.

        You said you were using this board fine for a while, and then it stopped working right. It seems it would have failed in some way, but how exactly I am not sure.

        I guess if you cannot get it to work right, even after reflashing the bootloader etc, then you can always apply for an RMA, and get it replaced.

        Keep trying though and see if you can figure out what it could be, but if you still have no luck, you can start the RMA process by raising a ticket on our support page of our website.

        Keep us in the loop though as to what you try and if it works or not.

        Regards
        James

        Comment


        • #5
          Hi James,

          Yes, that is correct... I'm using the base install, not the nightly release.

          The board externally looks fine to me... no sign of shorts, bad joints, etc. I'm about 99% sure it's a software/firmware thing at this point, in which case, no need for an RMA yet. That's always my last point of call. Would much rather find the glitch so that us humans make forward progress

          I'm currently busy with the bootloader re-flash and will then look at the nightly release of Arduino. (Although it was working fine with the current release)

          I'm wondering if by some chance I ended up selecting the wrong board file at some point and tried to flash it without realizing. I know that causes 'bricking' on the Sparkfun Pro Micros if the clock speed fuses are then set incorrectly, so that's why I'm going the bootloader route first to make sure it hasn't somehow been corrupted.

          Do you know what the VID/PID codes should be returning as? That may give another clue why it is stuck in 'bootloader' port number 10.

          Best Regards

          Comment


          • #6
            Hi Graeme

            Yeah get the nightly, that could be the ticket, as I cant even load to the board with the base 1.6.12 install, known arduino ide BUG.

            From our boards.txt file:

            #Bootloader
            duino4.vid.0=0x04D8
            duino4.pid.0=0xF113
            #Runtime
            duino4.vid.1=0x04D8
            duino4.pid.1=0xF110

            Hope that helps

            Regards
            James

            Comment


            • #7
              James,

              An update...

              I have flashed your original bootloader to the Atmega32u4, which uploads perfectly. So, chip looks ok. I can go into Arduino IDE and upload to the bootloader driver (Com9 actually), but the second the sketch finishes uploading, I get the USB Driver error.

              I think I know what's going on here....

              I have a feeling that somehow I previously selected the wrong board file and flashed it, unwittingly changing the fuse bits of the chip... So the upload works fine, but as soon as the chip re-initializes after flashing, it has a timing mismatch with the USB and bombs the driver out. I can verify that the code does upload correctly, via a simple blinking LED on Pin13, but as soon as the chip resets and restarts it's USB, the port drops. The only thing that I can think would cause that is a timing mismatch with the clock fuses.

              I can confirm this, but I need you to please list/send me the full fuse bit settings for the Atmega32u4, as shipped from factory so I can reflash the entire chip to default.

              I have a feeling that this should solve it.

              It can't be an Arduino bug issue, as the exact same code worked flawlessly with the same Arduino setup as I have now.

              Thanks in advance!

              Comment


              • #8
                Hi Graeme,

                Fuse bits - hmm, I thought the fuse bits were all set by the bootloader in all honesty.
                Let me do some investigating and ill see if I can find this out for you.
                Alternatively, you could connect your good 4Duino to an AVR programmer and sniff out the fuse bits and compare it to the bad 4Duino, and see if there is a difference? That might be faster.

                Regards
                James

                Comment


                • #9
                  James,

                  Apologies for the delay in response. I have been in the UK on a business trip.

                  I think we have solved this problem. I did as you suggested and checked the fuse bits on the good 4duino and compared them to the fuse bits on the bad one.

                  There was no difference in the fuse bits, BUT, the lock bits were different. The bad 4duino had no lock bits set, particularly the BLB1 lock bit was set to "No_Lock". On the good 4duino this was set to "SPM_Disable". That was the ONLY difference between the two chip settings.

                  So, I changed the bad 4duino lock bits to match the good 4duino (Have to disable "Erase device before programming", then program the lock bits.)

                  And now, all seems to be working fine.

                  Maybe you can elaborate more, but as I understand it, the SPM lock bit is related to the bootloader. However, I am not sure of the interaction. If you could clarify this, I'm sure it would conclusively close this thread.

                  Many thanks
                  Graeme

                  Comment


                  • #10
                    To elaborate on the previous post...

                    If Interrupt Vectors are placed in the Boot Loader section and Boot Lock bit BLB02 is programmed, interrupts are
                    disabled while executing from the Application section. If Interrupt Vectors are placed in the Application section and
                    Boot Lock bit BLB12 is programed, interrupts are disabled while executing from the Boot Loader section. Refer to
                    the section “Memory Programming” on page 353 for details on Boot Lock bits.
                    Regarding BlB1 Mode...

                    SPM is not allowed to write to the Boot Loader section, and (E)LPM executing from
                    the Application section is not allowed to read from the Boot Loader section. If
                    Interrupt Vectors are placed in the Application section, interrupts are disabled while
                    executing from the Boot Loader section.

                    Comment


                    • #11
                      James,

                      My apologies again... False alarm... the problem is still there. Possibly still some latent defect with the bootloader, however...

                      I have this exact same problem with the Sparkfun Pro Micro, which also has an ATMega32u4 processor. Under their product comments, Sparkfun have posted...

                      Interrupts Atmega32u4’s built in CDC driver for USB communication can have timing issues when messing with the watchdog timer, sleep modes, and timer interrupts. I am unsure of how to fix this issue if you continue to use code that interferes with the CDC. I recommend trying a different method than using the interrupt timers.

                      Wrong Bootloader It’s possible to brick your Pro Micro 3.3V/8MHz if you used the wrong board selection with the wrong frequency. If you upload the wrong frequency, the IC will not be able to understand any new code that is being uploaded. It expects to have code that is compiled for another bootloader, instead of using the 8MHz frequency with the oscillator.

                      When either of these cases happens, the device manager is not able to recognize the device and is usually seen as an “unknown device” when the microcontroller runs the sketch. There are ways to recover the an Atmega32U4 (i.e. LilyPad Arduino USB - Atmega32U4 board, FioV3 - Atmega32U4, Pro Micro 5V/16Mhz, Pro Micro - 3.3V/8Mhz, etc) if this happens.
                      The remedy for this is still the same... reflash the bootloader. I have done this now several times on the 4duino, and I have double-checked the fuse bits and lock bits each time using AVR Studio from Atmel. The outcome is that I get the 4duino board back to a good working state. I can flash "Blink" to it with no problem. Works fine.

                      The second I upload my code to it, which uses Timer1 and an overflow compare interrupt, then "USB not Recognized" again.

                      So, I commented out parts of my code, line-by-line, bricking the 4duino every time, then recovering it and commenting out the next line.

                      UNTIL

                      When I comment out the following line of code...

                      ISR(TIMER1_COMPA_vect)
                      Which is the Timer1 interrupt call, then the upload works perfectly, with no "bricking". I did this multiple times, with and without the line of code, and it is a pretty clear result.

                      Line included... bricked.
                      Line excluded... fine.

                      I have also checked the Atmega32u4 datasheet, and the USB section of the chip does not use Timer1 at all. It has a complete set of it's own interrupt vectors.

                      Any ideas why the interrupt would be messing with the USB? I have an overflow of 1second... so it's only calling the interrupt every second. shouldn't mess with the USB at all, seeing as it is clocked separately on chip and should be independent of the application code anyway...??

                      Alternatively, could it be something along the lines of the interrupt not being handled correctly through the bootloader at upload? I'm quite confused now as it looks like the bootloader is somehow getting corrupted by this line, or the interrupt itself is interfering with the USB??

                      Come on James, you guys are ninjas... lets get to the bottom of this...

                      Comment


                      • #12
                        Hey Graeme,

                        Quite a puzzle you have discovered.

                        If it is a problem with the atmega32U4 caterina source from Sparkfun, then I guess a way to test it would be to use the original Arduino source and see if the bootloader generated from there has the same problem or not. If it does, then it comes back to the caterina source itself I guess.

                        Just looking in the source folder, and there were a few versions we were playing with.
                        If you can, can you try uploading each of these and just see what the results are. If we can narrow it down, then we can do something more official to try and fix it.
                        Now, the file names, I cannot remember the specifics for right now, but I can certainly look it up on Monday, but see if any of these work for a start, and we can go from there.
                        Try the 'original' one first, then 'first official' then 'sparkfun fixed'. The one in our JSON download came after these 3. I cannot vouch for stability with these, but at least see if it solves some problems and we can move forward.

                        Appreciate your input on this.

                        Regards
                        Attached Files
                        James

                        Comment

                        Working...
                        X