AT90USB162 work incorrectly, sometimes.

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

Hi, Sorry for my bad English.
My products, using AT90USB162, is HID mouse, keyboard, and CDC composite device.
The state of produce, the device works correctly.
But, 1~3 months later, 10% of products don't work.
The main source is AVR272.
The circuit is attached.

Fuse setting is
- BOD 4.3V, 16MHZ Crystal.
- SPIEN, BOOTZ $1800
- SUT_CKSEL 16CK + 65ms
- Use Bootloader and FLIP 3.4.2

The case of incorrect working is
- The state of inserting to USB port, jumping to
bootloader is 10%
- No enumeration of one device is 30%
- No enumeration of all device is 50%.

When C1 AND C2 use 4.7uF, or 10uF, or 20uF, or not use
of Cap, the result is same.

When use below code, 10% is that the device goes to bootloader.
Usb_detach();
Usb_disable();
Usb_disable_reset_interrupt();
Usb_disable_sof_interrupt();
TIMSK1 = 0;
cli();
asm("JMP 0X00000000"); // 10% is going to bootloader
// $1800

When rewrite firmware with ISP, the case of correct working is 50%.

Please help me!!

Attachment(s): 

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

Hardware and/or software bugs can corrupt EEPROM. Does the program rely on the content of EEPROM?

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

Yes, EEPROM is used, in booting mode, in the main.....

int main(void)
{
DDRB =0;
DDRD =0;
adr = 30;
temp = eeprom_read_byte((uint8_t *)adr);
temp1 = eeprom_read_byte((uint8_t *)adr + 1);
if (temp1 == (temp ^ 0x5A)) Descriptor_Mode = temp;
else Descriptor_Mode = 0;
........
}

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

6k2bun wrote:
Yes, EEPROM is used, in booting mode, in the main.....

int main(void)
{
DDRB =0;
DDRD =0;
adr = 30;
temp = eeprom_read_byte((uint8_t *)adr);
temp1 = eeprom_read_byte((uint8_t *)adr + 1);
if (temp1 == (temp ^ 0x5A)) Descriptor_Mode = temp;
else Descriptor_Mode = 0;
........
}

I have the same issue. I once read about a bug in the controller at certain voltage supply brown out scenarios (losing the flash content).
It does help using a good cable to connect the device to the PC - but this is not a help for you I am afraid..
I will consider using an external reset generator for the next designs to force the whole controller to reset before the internal brown out detection circuit is triggered.
Tell me if you found a different solution..
Juergen

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

Juergen,

Your code, by manually specifying location 30/31 should be avoiding location 0 which is the one susceptible to damage when BOD is not used (though BOD should always be used anyway).

Cliff

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

Quote:

which is the one susceptible to damage when BOD is not used (though BOD should always be used anyway).

Well, in practice you will find that the "corrupted" location tends to be the location that EEAR is set to.

Also, depending on the AVR model and phase of the moon, EEAR [apparently] may drop to 0 as supply voltage declines, while the AVR is still trying to run. (In general, it [apparently] is the address registers of the AVR that appear to give up the ghost first.) (Are there enough weasel-words in the above? All is based on ~10 years of trying to instrument and track down this sort of thing.))

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I have the same issue, with a product in mass production, a lot of return.
I don't understand, using flip.exe, we keep the Extended Fuse Byte in the default value F4, this mean 3.0V? In that case, why did we lost the memory

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

Quote:

using flip.exe,

Surely Flip does not have any possibility of changing fuses anyway?

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

Yes, I use flip

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

With Flip, it's impossible to change the fuse setting, we need a hardware programmer, so is the fuse in the default value? If yes, the BOR is on, so why did we have the memory corruped?

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

To double-check, I have read the state of the fuses with JTAGICI:

BODLEVEL = 3V0
HWBE = [X]
DWEN = [ ]
RSTDISBL = [ ]
SPIEN = [X]
WDTON = [ ]
EESAVE = [ ]
BOOTSZ = 2048W_1800
BOOTRST = [ ]
CKDIV8 = [X]
CKOUT = [ ]
SUT_CKSEL = EXTXOSC_8MHZ_XX_258CK_65MS

EXTENDED = 0xF4 (valid)
HIGH = 0xD9 (valid)
LOW = 0x5E (valid)

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

Hi,
I am using AT90USB162 in several product.
Now, the rate of return under garantee is 20% due to a ATMEL issue.
- No enumeration of the usb device, due to the FLASH ERROR
- EEPROM corruped.

I have seen some post in the same direction, involving the BOR.

I have read the fuse state with JTAGICE to be sure (see below, and the BOD seems OK.

Do somebody have an idea?

Thanks in advance.

[i]BODLEVEL = 3V0
HWBE = [X]
DWEN = [ ]
RSTDISBL = [ ]
SPIEN = [X]
WDTON = [ ]
EESAVE = [ ]
BOOTSZ = 2048W_1800
BOOTRST = [ ]
CKDIV8 = [X]
CKOUT = [ ]
SUT_CKSEL = EXTXOSC_8MHZ_XX_258CK_65MS

EXTENDED = 0xF4 (valid)
HIGH = 0xD9 (valid)
LOW = 0x5E (valid)[/i]

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

there can be zillion issues here....

on the units that you receive, If you re program them is hte contents then as expected?
Did you do a test to see that the controller has actually failed and thus the eeprom is defective?

Not sure what defice you use, but I guess you need minimum of 12MHz clock speed to de abel to run USB.
there is no atmel processor that you can connect a 70MHz to...
You need to change the CLK/8 fuse bit I guess.
Or does the spec state that USB is not affected by this fuse and that it will always run on the given clock.

Can it be that power is removed at the moment a eeprom write is done? I can imagine the EEProm getting corrupted then.

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

Note that the OP has asked the smae question here:
https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=103072

[moderator: two threads now merged]

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

I saw this post, but I'am not sure that the same issue.

Here is some information about the system:

Detected device
Device name AT90USB162
Device signature 0x1E9482

BODLEVEL = 3V0
HWBE = [X]
DWEN = [ ]
RSTDISBL = [ ]
SPIEN = [X]
WDTON = [ ]
EESAVE = [ ]
BOOTSZ = 2048W_1800
BOOTRST = [ ]
CKDIV8 = [X]
CKOUT = [ ]
SUT_CKSEL = EXTXOSC_8MHZ_XX_258CK_65MS

EXTENDED = 0xF4 (valid)
HIGH = 0xD9 (valid)
LOW = 0x5E (valid)

LB = PROG_VER_DISABLED
BLB0 = NO_LOCK
BLB1 = SPM_DISABLE

LOCKBIT = 0xEC (valid)

If i make a reset with HWB, I can reprogram the AT91 with flip, and after the system work propely.

We have sold more than 1000 device, and now, after few month, we receved a lot of defective one (20%).

My first idea ws the BODLEVEL issue, but it seems to be somethings else.
I have found a way to protect the EEPROM, but what can i do for the flash error?

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

You say:

6k2bun wrote:
Fuse setting is
- BOD 4.3V, 16MHZ Crystal.
- SPIEN, BOOTZ $1800
- SUT_CKSEL 16CK + 65ms
- Use Bootloader and FLIP 3.4.2
... but then:
Quote:
To double-check, I have read the state of the fuses with JTAGICI:

BODLEVEL = 3V0

... which is consistent with:
Quote:
With Flip, it's impossible to change the fuse setting, we need a hardware programmer, so is the fuse in the default value? If yes, the BOR is on, so why did we have the memory corrupted?
In any case, from page 265 of the datasheet, you see that at 16 MHz you should operate at 4.5V or higher, so the BOD fuses should be set for 4.3 V. If your batch of 1000 was delivered with BOD 3.0 V, a 20% failure rate wouldn't surprise me.

Does your code self-program? If so, is it possible you're exceeding the endurance? What about the code that writes to the EEPROM?

Even if you've handled this correctly, with BOD set to the wrong level anything could happen when removing the device from the USB port.

Without seeing code, we can't say much. In any case, the code that writes to EEPROM (or flash) could monitor Vcc and belay any pending writes.

You may monitor Vcc by connecting the positive input of the analog comparator to the internal bandgap reference voltage, and the negative input to the output of a simple voltage divider. You could then poll ACO in ACSR for the state of Vcc, and execute appropriate code. I would set the threshold to at least 4.5V (Use E96 10K 1% and a 30K9 1%. Alternatively, from E48 use 36K5 2% and 115K 2%, or from E24 use 22K 5% and 68K 5%).

Even the BOD set to 4.3V can trip as low as 4.1V, which is nevertheless 'unsafe' at 16 MHz.

You could also add an ultra capacitor across Vcc and ground to allow more time between comparator detection of low Vcc and execution failure.

JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Thanks for your help, in fact the first message was not from my side, that why the BOD was not the same.
In fact the AT91USB is powered by a 4.50V via a regulator the have a good stability for the analog part.
The program do not write on EEPROM, neither in flash (ONLY FACTORY SETTING).
I though that the figure (speed vs VCC) was more the termical issue rather then EEPROM/FLASH issue.

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

Hi!

I have the same issue.

Its about 15 to 20% of devices returned.

I use the AT90USB162 with 8Mhz clock and with BOD at 4.7v

I also have the Atmel USB Bootloader.

I think the power is not the issue because it happend with stable 5v power supplies (like USB without cable or internal disk drive power cables).

There more information about the cause of the issue?

thanks

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

Quote:

it happend with stable 5v power supplies

That were never turned off/on? (even by the insertion/removal of a USB cable).

The power may be as smooth and constant as you like but if you yank a power/USB cable then capacitance in a circuit usually means that the voltage slowly dies away and ramps down. As it's on the way down it passes into "danger territory". Only if you have BOD will it mitigate this risk (by pulling _RESET before things get really dangerous).

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

The Power supply is from the internal IT server and is connected directly to the board, i have only two capacitors more in the circuit. The Atmel is only "detached" when the server is powered off, or reset.

I dont use the power from the USB conection, but i tried and the issue is the same.

I had in the past (when i had the first simptoms) the BOD off. In the last two years i have programmed the BOD with 4.7v and the issue is the same.

This not happend in the first months. Only after 3 or more months.

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

Oh then could it be EEPROM wear? Are you inadvertently erasing/writing too often? The stated life is 100,000 erase cycles. Experimenters here have shown that at room temp it's more like 5,000,000 but it's easy to do something 5,000,000 times in a micro in a very short space of time. Certainly in 3 months.

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

More observations:
- Some cases i see the atmel in bootloader mode (without my trigger command), I detach and attach again the device and everything return OK.
- The issue may happen without power plug/unplug because I have a 24/7 system.

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

I use the EEPROM to read some settings, but It is not writted their anything afer the factory configuration.
I rad the EEPROM from a "damage" item and happear to be OK.

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

Quote:
Its about 15 to 20% of devices returned.

Oops.
Ok, so you are talking about spurious "jumps to bootloader".
Are you suggesting that after 3 months some percent of uCs do not meet Atmel's specification any more?
Can you reproduce the "jumping" behaviour? If not then it is most likely a buggy software.

No RSTDISBL, no fun!

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

Quote:
Its about 15 to 20% of devices returned.

Let me explain better, the 15-20% returned devices is from my clients to me.

The real issue may be the spurious "jumps to bootloader", but i dont have certain. But make sense if it jumps to the erase function.

I cant reproduce the "jumping" behaviour. I tried plug/unplug for several times.

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

Desperate OP wrote:
Let me explain better, the 15-20% returned devices is from my clients to me.

Yes, that is how I understood that initially.

You didn't provide any concrete pieces of information that would allow us to help you to solve the problem.
You also didn't answer to my question if you believe these uCs do not meet atmel's specification after 3 months of operation.
Frankly, I do not believe in such possibility (and 20% coincidence).
If you still suspect that mass failing of uCs is possible I suggest making a "bye world" abusing application and test some uCs of those 20% returned, IOs under high load, memory read/write, USB communication etc with wider voltage and temperature ranges. I bet all the conclusion you get from the investigation is that uCs work as specified in a datasheet.

The second possibility is that it is the elf problem (yes, including toolchain, USB library, fuses etc).

The only way to find a bug is to debug.

No RSTDISBL, no fun!

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

my flash used to get corrupted (three chips went to dustbin) when I was switching between 5v and 3.3v for programming the chip, once I moved all the components to 3.3v the issue disappeared .

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

You also didn't answer to my question if you believe these uCs do not meet atmel's specification after 3 months of operation. 

I dont have 100% certeain, because i dont use all the uC features, but I can reprogram the uC and use it again without any issues.

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

Brutte wrote:

The second possibility is that it is the elf problem (yes, including toolchain, USB library, fuses etc).
The only way to find a bug is to debug.

For now I think we have comething in common. I'm also using for basis the Atmel USB Library/Framework.

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

Quote:
but I can reprogram the uC and use it again without any issues.

Then that looks like there are no problems with uC hardware.

In case it is the Atmel USB Library then I suggest checking the release notes, perhaps there was some nasty bug discovered recently. You could contact Atmel but you do not even have the test case to report a bug.

And there is another possibility this is not the USB stack but your own firmware problem. In such case - attach a uC to a debugger, run it and periodically make a snapshot of SRAM to HDD.
Of course you could also ship some -DDEBUG versions of firmware to the end customers but I suppose that would have required using some m32U2.

No RSTDISBL, no fun!