Banging my head with AT90USB162 and Flip and AVRDude

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

Ok,

I got my AT90USB162 recognized by Flip, but I have a couple problems:

1. I can't read any from Flip because of "Device protection is set" crappy thing keeps preventing me from reading the device.

2. Using the ASPUSB programmer, AVRDude can't read the fuses. It keeps saying "Yikes" wrong device id, BUT Flip is able to see the device id without problem!

So where is what I have done.

-Start up Flip. It shows the device id correctly. Attempted to read. Got the "Device protection is set" error. See the AT90USB162_Device_protection_is_set.jpg image attached.

-Fine. Do an erase from Flip. Now, I am able to read within Flip, but note of the device id is now all 0xFF values. See the AT90USB162_Erased.jpg image attached.

Unplug the USB cable and plug in the USBASP programmer. Attempted to read the fuse bits via AVRDude but got the below.

c:\AVR\projects\fuses>avrdude -p usb162 -c usbasp -u -U lfuse:r:lfuse.txt:h -U h
fuse:r:hfuse.txt:h -F

avrdude: error: programm enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for AT90USB162 is 1E 94 82

avrdude done.  Thank you.

-Unplugged USBASP programmer and plug the back USB cable and start Flip. Flip now shows the correct device id again AND I again can't read the device.

BUT...I am able program a blinking LED program via Flip and run it. Obviously the AT90USB162 built-in bootloader is still there. But, once I unplugged the USB cable and exited Flip, the blinking LED is not running as 8Mhz, because the gap between blinking is very long, unlike previously when it was blinking at a 1.5 sec programmed interval. Plugged back the cable and started Flip again. Now the uC is not recognized by Flip. And blink program runs, BUT again not with the 1.5 sec programmed interval but some long interval! :evil:

What's going on? Please advise. So close to start writing some firmware for the AT90USB162. I want to be able to change the fuse bits to use 16Mhz and without the DIV8 bit turned on and turn off all lock bits. I want to be able to NOT use Flip if I want to, e.g., using LUFA, etc.

Thanks.

Attachment(s): 

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

Surely you need to get familiar with using FLIP properly.

No bootloader can change fuses. They can however set lockbits. You clear the lockbits with an Erase operation.

You will have an equal difficulty with LUFA or anything else. i.e. you have to learn how to use FLIP.

Of course you can always trash all bootloaders and treat your USB chip as if it is only capable of blinking LEDs. i.e. program via usbasp or other ISP programmer.

But this requires you to learn how to use avrdude.

I am sure that avrdude -c usbasp will connect quite happily with your AVR if you wire it correctly and give the correct command.

David.

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

david.prentice wrote:
Surely you need to get familiar with using FLIP properly.

No bootloader can change fuses. They can however set lockbits. You clear the lockbits with an Erase operation.

Right. That's why I used my USBASP programmer via AVRDude to try to change the fuses.

Quote:

You will have an equal difficulty with LUFA or anything else. i.e. you have to learn how to use FLIP.

I have the AVR282 (Flip's user manual pretty much) right in front of me, and, frankly, that thing is not much to use.

Obviously, I have cleared the lock bits repeatedly, but Atmel's bootloader keeps putting it back.

Quote:

Of course you can always trash all bootloaders and treat your USB chip as if it is only capable of blinking LEDs. i.e. program via usbasp or other ISP programmer.

But this requires you to learn how to use avrdude.

Uhm...Please see my original post where I included the AVRDude command used. How could I program my AT90USB162, when AVRDude fails even reading the fuse bits? That is the dilemma that I am encountering.
I am sure that avrdude -c usbasp will connect quite happily with your AVR if you wire it correctly and give the correct command.

I have checked the MOSI/MISO/SCK/RST connections to the uC. Everything is in placed.

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

> I have checked the MOSI/MISO/SCK/RST connections to the uC.

Check the signals with an oscilloscope.

Try reducing the ISP clock speed. Not sure though how this is to be
done in USBASP, IIRC you have to change a jumper.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

You alter the ISP speed of usbasp by -B# where # is the clock period in us.

David.

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

Hello,
(sorry to hijack this thread a little)

Ive got an xplain board, and I get this "device protection is set" message when using flip too, and I'm not sure why, I've always got a little confused to why this was. I've checked the fuses with my Dragon (using jtag) and no lock bits are set on the AT90USB1287.

So am I right in assuming its the bootloader which locks the chip out in software? I can perform an erase, and then upload a program (both using Flip), and then I am able to do a read, but as soon as I cycle power (unplug and replug the usb connector on the Xplain board) and try to do another read I get the "device protection is set" message. Again checking the lock bits with my dragon after, shows no lock bits set.

Again sorry to hijack, but this has been buggin me for a while (and it seemed a bit relevent to this thread)

.... and I hope you have some joy getting avrdude to work correctly.

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

I had Flip 3.2.0 on my machine. This seems to work quite effectively with the AT90USB1287 on a USBkey. I have also used it with AT89C5131 devices.

Sure enough, the USBkey firmware is "device protection is set" when you try to read it.

But you can erase the chip.
Blank check.
Program with firmware.hex (available on the FLASHDISK)
Verify the firmware.
Run the application.

Everything works fine. In fact I am very impressed with the 120kB of flash being written in 1 second.

You can upload any other program / read the contents etc quite happily via FLIP. Of course this all depends on you not interfering with the bootloader or fuses.

If you have messed up the bootloader, you need to use JTAG or ISP to restore it. And preferably lock the programmer away afterwards.

Just to check that the current FLIP is not broken, I uploaded FLIP 3.4.2. Sure enough, it looks and works exactly the same as 3.2.0.

I am using XP. But since FLIP is a Java program I can see no reason for it to fail with any O-S.

I can see every reason for problems after ISP. What do you have your fuses set to? What are the Lockbits?

David.

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

Oops. If you cycle the power, the AVR becomes 'protected'. OTOH, you can simply re-program the device with FLIP when you want a new application. After all, you have no need to read the flash again after the initial Verify.

Dean may be able to explain this behaviour. I have not got the energy to trawl through the data sheet this evening.

David.

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

piperazine wrote:
Hello,
(sorry to hijack this thread a little)

Ive got an xplain board, and I get this "device protection is set" message when using flip too, and I'm not sure why, I've always got a little confused to why this was. I've checked the fuses with my Dragon (using jtag) and no lock bits are set on the AT90USB1287.

So am I right in assuming its the bootloader which locks the chip out in software? I can perform an erase, and then upload a program (both using Flip), and then I am able to do a read, but as soon as I cycle power (unplug and replug the usb connector on the Xplain board) and try to do another read I get the "device protection is set" message. Again checking the lock bits with my dragon after, shows no lock bits set.

Again sorry to hijack, but this has been buggin me for a while (and it seemed a bit relevent to this thread)

.... and I hope you have some joy getting avrdude to work correctly.

Dude! you're hijacking this thread! Just kidding! Yep, that's exactly the problem I have with Flip (the latest version that I use on Vista) and my AT90USB162's getting the "device protection is set" as soon as I cycle power (unplug and replug the usb connector). My AT90USB162 is on a PDIP-32 adapter on a breadboard.

Yeah, like any new member of Atmel uC's, one has to go through the same learning trials, just like I did with ATMEGAs. Now with USB support uCs.

Thanks all for the suggestions and answers. I'll those a try.

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

There's two gotchas here that you need to be aware of:

1) Atmel's DFU bootloader has its own software level device protection bit, which is not linked to the physical fuses. On reset, this protection is enabled, locking out all functionality other than erase in FLIP. Once the device is erased, all the features should work until the next reset. This is designed as a security measure, so bad people can't read out your device's FLASH/EEPROM memory once you've built and shipped them.

2) The WTDON fuse and DIV8 fuses may or may not be set. These can be altered via software until the next reset (all LUFA firmware does this) but if not altered, you might have your bootloader working fine, but your loaded application running very slow or resetting continuously. Make sure both fuses are cleared, or turn off both features in your app via the appropriate registers.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

david.prentice wrote:
You alter the ISP speed of usbasp by -B# where # is the clock period in us.

David.

Unfortunately, AVRDude's -B or -i option does not work. I tried with 20us to 2000us, but no avail.

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

Oh yes, it does work with usbasp.

Any AVR running at 1MHz (period 1us) will need a clock period of 4us or greater e.g. -B5 .
Some AVRs have a 128kHz oscillator. They need -B280 if CKDIV8 is set.
A 32kHz + CKDIV8 needs -B1200.

I am very sceptical that anything ever needs -B2000.

Quite honestly, if your AT90USB162 will run with FLIP, it must already have at least a 1MHz clock. So -B5 is fine. Without checking, I would guess that avrdude will be using this as a default anyway.

Please post the exact command that you are using.
And the response from avrdude.

It would also be useful to post a photo of the wiring on your breadboard with its connection to the usbasp board.

David.

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

david.prentice wrote:
Oh yes, it does work with usbasp.

Any AVR running at 1MHz (period 1us) will need a clock period of 4us or greater e.g. -B5 .
Some AVRs have a 128kHz oscillator. They need -B280 if CKDIV8 is set.
A 32kHz + CKDIV8 needs -B1200.

I am very sceptical that anything ever needs -B2000.

Quite honestly, if your AT90USB162 will run with FLIP, it must already have at least a 1MHz clock. So -B5 is fine. Without checking, I would guess that avrdude will be using this as a default anyway.

Please post the exact command that you are using.
And the response from avrdude.

It would also be useful to post a photo of the wiring on your breadboard with its connection to the usbasp board.

David.

In the past, I also use the -i option to slow down the ISP speed when attempting to reviving a dead ATMEGA8 pumping a 1Mhz square wave into the XTAL2 pin. Trying to use the -i here to slow down the ISP does not seem to work either.

I have made sure the slow SCK is jumper set on the ASPUSB programmer as well.
(Heck, I tried both normal SCK and slow SCK. Same results. See below.)

The default fuse bits, according to the AVR fuse calc I found on the net ( http://www.engbedded.com/fusecalc/ ), is 8Mhz with the external crystal with the DIV8 bit enabled. So, yes, it's 1Mhz for certain. In fact, without the AVR calc telling me, I pretty sure the AT90USB162 is set up by the factory to use an external crystal, because there is no way on earth an internal RC of 8Mhz can work with USB, per their documentation.

I would like to try dl8dtl@'s suggestion by looking at a scope, but I don't have one. :)

Command:

c:\>avrdude -p usb162 -c usbasp -u -U lfuse:r:lfuse.txt:h -U hfuse:r:hfuse.txt:h -F -B5

avrdude: error: programm enable: target doesn't answer. 1 
avrdude: initialization failed, rc=-1 
avrdude: AVR device initialized and ready to accept instructions 
avrdude: Device signature = 0x000000 
avrdude: Yikes!  Invalid device signature. 
avrdude: Expected signature for AT90USB162 is 1E 94 82 

avrdude done.  Thank you. 

Last Edited: Sat. Nov 27, 2010 - 06:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

I am using XP. But since FLIP is a Java program I can see no reason for it to fail with any O-S.
David.

I think very likely not on the above point. Sure, Java's byte codes is machine/platform independent, you would need the USB drivers for a given platform in order for Flip to communicate via a USB port.

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

Why not say what O-S you are using?
I would be confident that Java will be using working USB drivers. After all, you claim to be able to upload applications via FLIP

Re usbasp: If you use the slow_clock jumper, you cripple the whole device. Remove it. Then do:

avrdude -c usbasp -P usb -p usb162 -B5 -v

and copy the response.

I presume that avrdude -c usbasp works perfectly for all other AVRs.

David.

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

david.prentice wrote:
Why not say what O-S you are using?

Vista. I mentioned that a couple times in the thread. Also, my posting of AVRDude command prefixed with "C:\" means WINDOWS platform.

Quote:

I would be confident that Java will be using working USB drivers. After all, you claim to be able to upload applications via FLIP

Yes, java will run on any commercial platform. My point was that for Flip to run on Linux, for example, it will need a the Linux native USB driver implementation. Even the javac executable itself needs to be compiled on the native platform in order to run the java classes.

Per your mentioning "Java will be using workign USB drivers." There is a USB JSR then.

Quote:

I presume that avrdude -c usbasp works perfectly for all other AVRs.
David.

You bet. :)

g2g now, but will give ur suggestion a try. Thanks for your time/help.

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

On "Virgin" avr's i have to set the USBASP to "slow Clock" via the jumper/dipswitch , as the avr runs 1Mhz.
Then i can set the fuses to a higher speed , and disable the "slow clock".

Have you tried that ? , or are you sure the avr runs more than 1Mhz ?

/Bingo

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

Oops. I have just looked at the usbasp source code.
The default ISP speed is 375kHz. So is inappropriate for virgin AVRs.

Personally, I find it no great imposition to specify -B# in the avrdude command. -B5 will produce an ISP speed of 187.5kHz on a standard usbasp hardware with 12MHz crystal.

I would guess that usbasp would be better to default to 187.5kHz. After all, you can always specify -B0.5 to speed up ISP on a 8MHz chip to 1.5MHz.

David.

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

Ok, finally getting back to this...I am encountering the exact problem below described from the FAQ of the Atmel's Flip manual.

I really don't know how to do the "the user must apply hardware conditions to force the execution of the bootloader." part. How would I initiate it or trigger it? Thanks!

The AT90USB162 is such a nightmare for me, but, I have no choice but to use this thing, because I am too loyal to Atmel, and don't have time to learn how to use PIC's uCs that support USB.

FAQ

Question:

Programming an Atmel device only works the first time.

Symptom:

The first firmware upgrade done with FLIP was OK and my program runs fine but I am not able to program the part again.

Answer:

Default factory settings force the device to enter the embedded bootloader program on first power up with BLJB = 0  (checkbox set in Flip GUI) and BSB != 0.

On firmware upgrade completion, Flip sets the BSB (Boot Status Byte) to zero so that the device executes the downloaded firmware on reset. In order to reprogram the part, the user must apply hardware conditions to force the execution of the bootloader.

Please note that both BLJB and BSB settings may be changed manually through the GUI of FLIP to give you total control over the boot process.

Refer to the part data sheet for detailed information about the boot process.


"Please note that both BLJB and BSB settings may be changed manually through the GUI of FLIP to give you total control over the boot process."

There is no !@^&$ (expletives) GUI in Flip that let me do this. I am running Flip 3.3.4 and just downloaded Flip 3.4.2. Same thing!

And...Finding more info...

Setting Special Bits and Bytes

In the device frame of the main window, you can read/write or clear/set some bytes and bits.

The following table summarizes the main bits and bytes as well as their status (Read / Write).

Unless I am totally losing my mind, there is NO menu to set all these bits.[/b]

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

Yes, those aren't available (for the USB DFU devices, at least). The USB AVR parts have the physical HWBEN and BOOTSRT fuses that have to be changed with an external programmer.

To re-enter the bootloader, hold HWB low and pulse /RESET.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

abcminiuser wrote:
Yes, those aren't available (for the USB DFU devices, at least). The USB AVR parts have the physical HWBEN and BOOTSRT fuses that have to be changed with an external programmer.

To re-enter the bootloader, hold HWB low and pulse /RESET.

- Dean :twisted:

Thanks. Here is what now I have.

Ok, I have two buttons (active low) wired to the HWB and /RESET. I hold down the HWB button and repeatedly pressing the /RESET button, but the AT90USB's built-in bootloader is not activated.

Either I wired the buttons wrong, which I have checked over and over, or something else is missing.

The blink led program, which was compiled with F_CPU=8000000L, that I had Flip programmed into the uC is working, although at very low speed, blinking once every 8-10 seconds or something, once I disconnected the USB cable. But, while the USB was still in right AFTER Flip programmed the uC, the blink led program worked properly, blinking at 8Mhz, which is, the crystal I am using for the uC.

Last Edited: Sat. Dec 25, 2010 - 12:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm - that's the correct procedure to enter the bootloader (hold HWB low, pulse RESET low and release both).

Perhaps the bootloader managed to corrupt itself somehow, although I don't believe that is normally possible, due to the default fuse settings. Might be a good time to give up on the one chip you have and swap it out for a new one to see if it's a fault in the chip or its bootloader.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Surely you need to read / set the fuses correctly via avrdude and the regular ISP header.
Verify the bootloader against the HEX from the Atmel website.
Re-program if necessary.

Remove your ISP connection.
Run Flip. Verify that things work ok.

Alternatively replace the chip with a brand-new virgin AT90USB162. This should already have the fuses and bootloader set up correctly.

Incidentally, you can read your fuse settings from a regular application. Later AVRs can even read their own Signature Row.

David.

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

david.prentice wrote:
Surely you need to read / set the fuses correctly via avrdude and the regular ISP header.
Verify the bootloader against the HEX from the Atmel website.
Re-program if necessary.

I am giving up on the AT90USB. No, AVRDude keeps giving me the "Yikes" message that it's not recognizing the device id.

ATMEL's support is like blank-blank-blank. FLIP's documentation is inconsistent with the software itself.

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

unebonnevie wrote:
david.prentice wrote:
Surely you need to read / set the fuses correctly via avrdude and the regular ISP header.
Verify the bootloader against the HEX from the Atmel website.
Re-program if necessary.

I am giving up on the AT90USB. No, AVRDude keeps giving me the "Yikes" message that it's not recognizing the device id.

ATMEL's support is like blank-blank-blank. FLIP's documentation is inconsistent with the software itself.

SUCCESS! AND SELF-FLOGGING ORDERED! :oops: Sorry to have taken you folks' times and thanks for your patience.

On the AT90USB162 there is an /RST pin, which is pin 12. I HAD mistakenly wire to this pin as the reset pin, because it is so close to the MOSI and SCK pins and, you have gotten to admit that its name is pretty close the "/RESET"; thus, my brain kept thinking that it's the RESET pin, but it's NOT. The /RESET pin is pin 24.
After connecting to the "correct" /RESET pin, I was able to read the fuses via AVRDude.

Still have not able to get the uC to re-enter the bootloader by holding HWB low, pulse RESET low and release both. But working on that...

c:\AVR\projects\fuses>avrdude -p usb162 -c usbasp -u -U lfuse:r:lfuse.txt:h -U h
fuse:r:hfuse.txt:h -F

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e9482
avrdude: reading lfuse memory:

Reading | ################################################## | 100% 0.02s

avrdude: writing output file "lfuse.txt"
avrdude: reading hfuse memory:

Reading | ################################################## | 100% 0.00s

avrdude: writing output file "hfuse.txt"

avrdude done.  Thank you.


c:\AVR\projects\fuses>echo LOW FUSE BYTE
LOW FUSE BYTE

c:\AVR\projects\fuses>type lfuse.txt
0x5e

c:\AVR\projects\fuses>del lfuse.txt

c:\AVR\projects\fuses>echo HIGH FUSE BYTE
HIGH FUSE BYTE

c:\AVR\projects\fuses>type hfuse.txt
0xd9

c:\AVR\projects\fuses>del hfuse.txt
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok, as mentioned in the previous post, I can read the fuses, which are 0x5e and 0xd9, low and high bytes, respectively. These look to be the manufacturer's (Atmel's) fuse values. However, I cannot change the fuses for the AT90USB162. AVRDude fails to do so. I really want to turn off the CKDIV8, thus, my attempting to change the fuse values.

c:\AVR\projects\fuses>avrdude -p usb162 -c usbasp -u -U lfuse:w:0xDE:m -U hfuse:
w:0xD9:m -F

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e9482
avrdude: reading input file "0xDE"
avrdude: writing lfuse (1 bytes):

Writing |                                                    | 0% 0.00s ***failed;
Writing | ################################################## | 100% 0.11s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xDE:
avrdude: load data lfuse data from input file 0xDE:
avrdude: input file 0xDE contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.02s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xde != 0x5e
avrdude: verification error; content mismatch

avrdude done.  Thank you.
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your data sheet will tell you the factory fuse values.
I do not think that the default values on the engbedded website look right.

I would guess that you want to use a crystal. It is very unwise to use a SUT of 0.

If you use avrdude, you should never use the -F flag.
There are ocasions when it is useful, but definitely not when changing fuses.

David.

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

david.prentice wrote:
Your data sheet will tell you the factory fuse values.
I do not think that the default values on the engbedded website look right.

They certainly different from the fuse values, which are 0x5e and 0xd9 for low and high bytes, respectively, that I read off the brand new AT90USB162.

Quote:

I would guess that you want to use a crystal. It is very unwise to use a SUT of 0.

Yea, currently the uC's SUT is 01, again from the above fuse values I read off the uC.

Not sure if you thought that I was using the fuse values from the embedded site or not. I am not.