| Author |
Message |
|
|
 Posted: Jul 21, 2010 - 08:32 AM |
|
Joined: Jul 21, 2010
Posts: 3
|
|
Hello,
I have an MC320 motor development kit which comprises of an ATmega32M1 with a USB bridge for comms with a PC.
The USB interface used to enumerate as a CDC device which could be assigned a virtual COM port. I have reprogrammed the ATmega32M1 a couple of times, using the direct ISP connection with a JTAGICE-II and it works Ok.
Then, I noticed that the USB device will now only show up in DFU mode. It could be A result of, or just a coincidence with having programmed the other device but, it is probably a result of having pressed the RESET and PROG buttons for the AT90USB device.
However, it will not come out of DFU mode even with a power reset. Is this a normal result of entering DFU mode (PROG and RESET buttons)?
If so, what is the procedure to return to CDC?
Does the AT90USB device have to be reprogrammed?
Its bootloader appears to respond to FLIP, but where would I get the original code that provides the USB brige functionality?
Thanks in advance. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 21, 2010 - 11:43 AM |
|
Joined: Jul 18, 2005
Posts: 62310
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
If so, what is the procedure to return to CDC?
Does the AT90USB device have to be reprogrammed?
It'll only appear as a CDC if the application code in the AVR programs the USB to appear this way. Which USB software stack are you using? Atmel's or Dean's LUFA? |
_________________
|
| |
|
|
|
|
|
|
Posted: Jul 21, 2010 - 04:37 PM |
|
Joined: Jul 21, 2010
Posts: 3
|
|
Thank you for the reply.
If you are saying that the software in the ATmega32M1 influences the operation of the USB link in the separate AT90USB device, then that may explain things.
However, as far as I know, I have not programmed the USB chip at all. The development board came with a pre-loaded motor-drive application which was on the ATmega32M1 chip and the AT90USB1287 chip was pre-programed to act as a USB bridge to the other ATmega32M1. I have only changed the software in the ATmega32M1 by using the direct programming ISP connection. The AT90USB chip has its own JTAG connection and can also be programmed through the bootloader, but I have not programed it with any new software. What I did do, was to press the PROG and RESET buttons which are associated with the AT90USB. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 21, 2010 - 05:03 PM |
|
Joined: Jun 15, 2008
Posts: 1759
Location: North Carolina USA
|
|
Don't know the details of your board, but it seems the CDC enumeration is done in the application code and the AT90USB1287 is (perhaps wisely) deciding to stay in the bootloader on startup. The FLIP connection would allow you to force a jump to the application, or you could use a programmer to clear the BOOTRST fuse so it starts in the application.
If you connect a programmer you can save the flash for backup. FLIP might be able to save the flash as well, but in my experience it says the chip is locked until you erase it once. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 22, 2010 - 12:53 PM |
|
Joined: Jul 21, 2010
Posts: 3
|
|
Thanks, I'll try. The board does not have any socket fitted to the JTAG/ISP terminal for the AT90USB chip, but I can fit one and try to reprogramme the BOOTRST fuse.
The "Start Appication" in FLIP does seem to exit the DFU mode, but it does not enter CDC.
If the pressing of the PROG and RESET buttons permamently affects the state of the BOOTRST fuse, then this may be what has happened here. |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
