problem with a HID project (Arduino micro Pro)

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

good afternoon.
I am doing a HID project with an arduino Micro pro (ATmega32u4).
The problem arose when I wanted to test if it works, when loading a .Hex file from the Mplab X IPE.
I have taken a file that creates a HID of a Mouse and now I cannot reload any more programs in it, since it only detects me as if the arduino were a mouse.
I have tried to access it by JTAG and ISP and have not had a satisfactory result.

Any solution to delete bootloader?

This topic has a solution.
Last Edited: Thu. Sep 24, 2020 - 10:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why do you want to erase the bootloader? That would be the last thin I'd want to do. You really want to erase the application, or load another. I recall in the distant past I had the same problem and so did many others. The solution is on the interwebs - at least that's where I found it.

 

What was the problem you had using ISP? That should not care about the application running.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Isn't the bootloader supposed to have changed? Making the pc detect the mic as a mouse.

The problem is that I can't do anything with it when I try to access the program gets caught and I can't do anything.

Last Edited: Tue. Sep 15, 2020 - 11:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you used the bootloader to program the application in the device, then there must be a way to get back to the bootloader as it will still be there. You will have to search the web on how to get your specific board back to bootloader mode.

 

If you have used an external programmer to load the application into your device, there is a very slim chance the bootloader is still present, so that might cause your board not to go back to bootloader mode.

In that case again you have to search the web for a bootloader hex file that belongs to your board.

As you state to have had an ISP / JTAG attached my first guess is that you by loading the application have done a full chip erase and as such have erased the bootloader.

As you will not be the first to have done that, best first go to the web find the bootloader belonging to the board and use the ISP/JTAG connections to flash that.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, so you loaded a USB application to a Arduino that uses USB to load apps, and now it will not load apps....  Hmmm.

 

Using an ISP device (USBasp, AVRisp mkii clone, or another Arduino as ISP) in the Arduino IDE, select your board, then select your ISP device, then burn bootloader!

That should restore normal operation to your Pro-micro, and allow you to load via the bootloader, new applications. 

 

Hope that helps.

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

borxo wrote:
I have tried to access it by JTAG and ISP and have not had a satisfactory result.
Just a thought for the future - don't use JTAG/ISP with Arduino's - just program them through their bootloaders. As soon as you go in with ISP/JTAG there's a strong chance you wipe the chip and in the process you wipe the bootloader that has been used previously for programming code into the Arduino.

 

You should be able to get a copy of the 32U4 bootloader and use ISP/JTAG to put it back and restore things.

 

I *think* the bootloader to use is probably arduino-1.8.13\hardware\arduino\avr\bootloaders\caterina\Caterina-Micro.hex but you should probably just select the right board in the IDE, the right programmer and "burn bootloader"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

borxo wrote:
I have tried to access it by JTAG and ISP and have not had a satisfactory result.
Just a thought for the future - don't use JTAG/ISP with Arduino's - just program them through their bootloaders. As soon as you go in with ISP/JTAG there's a strong chance you wipe the chip and in the process you wipe the bootloader that has been used previously for programming code into the Arduino.

 

You should be able to get a copy of the 32U4 bootloader and use ISP/JTAG to put it back and restore things.

 

I *think* the bootloader to use is probably arduino-1.8.13\hardware\arduino\avr\bootloaders\caterina\Caterina-Micro.hex but you should probably just select the right board in the IDE, the right programmer and "burn bootloader"

 

The idea of the project was to use Arduino Micro pro with LUFA, to make a HID device.

 

When I went to load the file by JTAG, it has replaced everything, but in my opinion that is fine, because I no longer wanted the arduino but for example in this case a mouse.

The problem that then I have not been able to load the file again. The program crashed and it did not work, I have also tried to reset the device, to see if I could recover it.
But in the end I have not succeeded.

I leave you a project similar to the one I am doing.
https://www.engineersgarage.com/...

Last Edited: Tue. Sep 15, 2020 - 04:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A bit puzzled on what you have done here:

borxo wrote:
I have also tried to reset the device, to see if I could recover it. But in the end I have not succeeded.

 

please state every step....

it should have been

- find bootloader on web and download

- connect ISP or programmer and see that you can connect to the chip, that should be always possible as you should have either the JTAG or the ISP interface available

- Do a full chip erase

- load the downloader bootloader

- disconnect the programmer

-power cycle the device with atleast 2 seconds power off before applying power again

 

now you should be back at start and have an active bootloader, unless...............

you have also changed the fuse settings of your chip, then you might have given yourself a bit more to find out as you then not only have to find a bootloader, but also a description of the fuses needed for your board.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meslomp wrote:

por favor indique cada paso ...

debería haber sido

- encuentra el gestor de arranque en la web y descárgalo

- conecte el ISP o el programador y vea que puede conectarse al chip, eso siempre debería ser posible, ya que debe tener disponible la interfaz JTAG o ISP

- Hacer un borrado de chip completo

- cargar el cargador de arranque del descargador

- desconectar el programador

- Apague el dispositivo con al menos 2 segundos antes de volver a encenderlo.

 

ahora debería volver al inicio y tener un gestor de arranque activo, a menos que ...............

También ha cambiado la configuración de fusibles de su chip, entonces es posible que se haya dado un poco más para averiguarlo, ya que no solo tiene que encontrar un cargador de arranque, sino también una descripción de los fusibles necesarios para su placa.

 

Yes, that was clear to me. The problem arose that the program was blocking, because it did not detect the microcontroller or something like that.

The final outcome was that I fry the microcontroller, for a bad connection without wanting power.

I think the problem arose that the pins used were the ISP and JTAG. So I don't think it detected the information sent.

One question is it very difficult to activate on this microcontroller in DFU mode?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

borxo wrote:
One question is it very difficult to activate on this microcontroller in DFU mode?
Usually to do DFU you are going to have two almost completely separate USB programs in the AVR. One in the boot section is a bootloader that when run (usually with HWB) it takes control and enumerates as a USB DFU (Device Firmware Upgrade) and in this mode it can then be sent (usually via "Flip" for AVR) a new application program. The second program in the AVR will be whatever USB class application you actually want to use be it CDC, HID, MIDI, Audio, etc (or possibly come convoluted combination of those). So you build the bootloader and it maybe creates a DFU.hex and you build your HID application and it makes a HID_app.hex. So now comes the question of how you get those into the AVR. One way is to "glue" the two .hex images together and the program the whole thing as one so that in one session the DFU part goes up into the boot section and the HID app goes into the low memory application area. But the fact is that from this day on you are probably going to use DFU (+Flip) to keep delivering updates of HID_app.hex so you might as well start right now. So as a one time operation you program just DFU.hex into the AVR so it now resides in the upper boot section. And now you simply reset the AVR and trigger it into bootloader mode (HWB) and it will start up a a DFU. Now (just as you will do many times from now on) you actually deliver the "other program", the HID_app.hex using the DFU. At this point you can lock your JTAG/ISP programmer in a draw as you won't be going near them again. If you do then, because reprogramming also involves wiping the whole chip (which then removes the current DFU and HID_app) you have to at the very least use ISP to put DFU back or maybe the combined DFU+Hid_app if you want to do it all in one. But like before you can just put in DFU then trigger it to allow HID_app to be delivered. So the only time you ever get JTAG/ISP out of the drawer are on those rare occasion when you actually need to change something in DFU. Otherwise just always use DFU to program things in.

 

(this is not unlike Arduino - when they are made someone has a one-time session to put a bootloader into them but after that no one ever uses ISP on them because you always just deliver new app code by using the bootloader (though in this case it is not DFU protocol but actually does something using USB CDC+UART)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Hello,

  What is your basic level of experience in using microcontrollers,  using C with AVR microcontrollers, and using USB (in theory and in practice)?

 

People who are not experts in using C with AVRs, and are not experts in USB design and theory, should NOT do what every one seems to do, which is:

  

  1.  Get assigned by boss-at-work or professor-in-college to implement a USB project/solution on the ATmega32u4.

  2.  Get an Arduino Micro Pro with an on-board ATmega32u4.

  3.  (a)  Watch a ten minute YouTube video on AVR/USB. 

             -or-

       (b) find a web site that does what you want to do with the Arduino Micro Pro.

  4. Download a hex file from the video's comment section.  Load hex file in working Arduino and "Brick-it" [destroy its functionality].

 

  What you should do is:

  0.  Ignore LUFA.  It is too complex and underdocumented for anyone who is not already an expert in USB theory and operation.

  1.  Send MANY MANY hours watching YouTube videos on USB theory.

  2.  Send MANY MANY hours studying USB fundamentals from web site tutorials ranging from beginner to USB expert.

  3.  Get the Arduino library for the mouse/keyboard that uses the Micro Pro with mega32u4.

  4.  Load, run, and experiment with the Arduino Mouse/Keyboard USB demo.

  5.  Study its code until you can tell exactly why this library always works with Arduino Micro Pro (and the code that you found in the video link or website won't work).

  6.   IF POSSIBLE,  use ISP to erase all the flash in the mega32u4 and reload the Catrina bootloader.

     -or- If not  possible to reload the bootloader because you turned the mega32u4 into a "mouse" and forgot to implement a "backdoor" that turns the mega32u4 back into an Arduino Micro Pro,

            then accept that you screwed up, get another Micro Pro or an expensive Atmel hardware professional development tool that can use either high-voltage or some other advanced means        to recycle your mega32u4.

  7.  Don't attempt to learn microcontroller development by starting with the most complex and under-documented topic focus in the entire 8-bit CPU industry: USB interfacing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the help. The problem is solved.

Last Edited: Fri. Sep 18, 2020 - 02:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the help. The problem is solved.

 

Last Edited: Fri. Sep 18, 2020 - 02:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Then mark the solution, for future readers to see that this question has been solved.

 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simonetta wrote:
0.  Ignore LUFA.  It is too complex and underdocumented for anyone who is not already an expert in USB theory and operation.
Did you take a double dose of your spew the BS pills today?!? LUFA is one of the best pieces of software ever written for AVR and is exemplary when it comes to documentation! 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meslomp wrote:
Then mark the solution, for future readers to see that this question has been solved.

+1

 

If you need instructions to do that, see Tip #5 in my signature, below:

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...