BIG BUG ON UC3A0512

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

Dear all,
I'm a developer and I'm using a ATMEL UC3A0512 micro.
I have found a big problem at the start up.
When you power up the micro and the VCC 3.3V go up you can found on the I/O lines some spikes.
The presence of this spikes depend from the slew rate of the power up, and depend from the delay between VCC and VCC_IO.
If the daley is = 0 the the presence of the spikes is guaranteed, if the delay is about 5 mS this spikes occours some times (1 times on 3).
If the delay is more then 5 mS the micro some time do not start and the power consumption are more then 200 mA.

THIS SPIKES OCCOURS BEFORE THE RAISE UP OF THE RESET SIGNAL WHEN THE CODE IS NOT STILL STARTED

This problem depend from internal power management of the micro (ATMEL said this).

After one years of discussion with AMEL, they admitted that there is a problem.
This is the answer of ATMEL:

ATTicket:631925

"Dear Mario,

We regret the delays in communication.

We had to get the confirmation from our internal team on issue.

The internal team has confirmed the issue and we were able to reproduce it in lab.

The workaround is to introduce a delay for VDDIO. We have tested it and it is removing the spike in GPIO pins.

In our tests, using external RC for VCC didn't work as expected(spike level was reduced but didnt remove it). We would recommend to use the workaround proposed.

Sorry for the inconvenience caused.

Best Regards,
Ram Raja Kumar
Atmel Technical Support Team "


After this I ask to ATMEL if is possible a new release of the micro, but the new answer of ATMEL is that the micro is OK and suggest me to put same filter on the I/O.
INCREDIBLE !!!!

I' hope that this message go in all corner of the world.

Ciao Marco
PS. I have changed the micro now !

Attachment(s): 

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

For what it's worth, Atmel definitely isn't alone in silicon errata like this. For example, the NXP LPC111x family of ARM Cortex-M0 parts are documented to exhibit a similar errata:
http://ics.nxp.com/support/docum...

Out of curiosity, does the power-on characteristic change at all if you attach external pull-up or pull-down resistors to the critical I/O pins?

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

Wait, isn't it unadvisable to have a large delay between core VCC and VCCIO? Why are they recommending that?

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

they recommending that, because they know where are the problems.
I have already tried to insert a pull-up or pull-down but doesn't change nothing!
This problem is present also on the EVK1100 demo board.
ciao
Marco

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

:oops: how is possible to resolve the problem ?

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

Hi maximillian,
you can solve the problem only if atmel change the chip.
for now you can only put filters on the I/O

Marco

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

So what exactly is the workaround they suggest? How do you implement the delay on Vccio? I don't think a big RC filter would work, or do you need to use a separate regulator with a shutdown pin to control...?

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

I have insert a dalay of about 5 mS with 2 CMOS, 2 resistors and 1 capacitors of 1 uF, between VCC_33 and VDD_IO. I have tryed to change this value between 2mS to 20 mS, but I do not resolve my problem. Some time at the start up the spike on I/O enters in the power module and causes shutdown of my device.
In this my case is impossible to use the filter. I have changed the micro.

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

What do you mean by "2 CMOS"? Are you using CMOS gates or something?

Also did they only admit to the flaw being on that one device, or multiple devices within the family? Is sounds like the kind of flaw which wouldn't be confined to a specific part...

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

I don't know, I have used only the 32UC3A0512 micro. But yes, sound like the bug is present on more micro.

http://www.spirometry.com/downlo...
This is the link where you can download the image of my modifications, The 2 CMOS are Q6 an Q7
ciao

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

Okay, I understand what you're trying to do and it makes sense. Maybe it has to do with how fast the rise on VCCIO is... I assume they didn't reveal exactly how they achieved the delay between VCC and VCCIO.

In any case it's extremely frustrating that these issues still persist.

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

Yes, but the worst thing is that ATMEL said me:
For 10.000pz/year that I buy we don't make a new revision of micro.
I have others type of board but with same micro, where the rise of VCC is more fast (1 mS) but the spike there is also smaller and shorter, but present.

They have recognized the problem and solve it never.
ciao Marco

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

Quote:
They have recognized the problem and solve it never.

No, that normally means that it is not getting top priority. They will fix it later with other issues in their normal revision cycles.

But also it is a clear and honest answer. Do you have an idea what such a revision costs? I work for a company where the price for a new revision of a much simpler chip was about $200.000 some years ago. For a AVR32 I assume the revision costs can easily go into millions.

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

I can understand, but do you know the cost of designing and to put on the marked a new medical device ?
plastic case about $280.000
working hours: $400.000 (3 years of work for 20 person)
bluetooth test: $ 40.000
GSM TEST (all world) : $120.000
general electric and material test: $50.000
preproduction: $100.000
clinical trials: $120.000

And after this you found a bug on the micro and the your new device automatically turns off when you try to switch ON.
You're a little angry with ATMEL, do not you think?

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

Of course I understand your anger, too. But I am a little surprised that such a big problem manifests after 3 years of work, electric tests, clinical trials etc. With what chips do you tested? Did they haven't the same spike problem?

In our company we make extensive functionality tests with prototype boards, and then repeat the tests with the release versions. There we test I/O behaviour (clean edges) of SPI and I2C devices, Ethernet, and especially the power source. Then EMV tests.

After all this comes the beta test with some special customers and then preproduction.

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

I don't think Atmel will ever fix this as the "problem" presented by the OP only exists when operating the device outside the published limits. The datasheet states that the minmum rate of rise of the supply voltage is 2.5 V/ms. If you look at the OP's scope plot he has a rise of roughly 0.33 V/ms! That's almost an order of magnitude out of spec! That's like trying to run a 5V rated part at 3.3V and then complaining when it doesn't work correctly.

Letting the smoke out since 1978

 

 

 

 

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

digitalDan wrote:
The datasheet states that the minmum rate of rise of the supply voltage is 2.5 V/ms. If you look at the OP's scope plot he has a rise of roughly 0.33 V/ms! That's almost an order of magnitude out of spec! That's like trying to run a 5V rated part at 3.3V and then complaining when it doesn't work correctly.
No, that's really not a good comparison, because a properly designed IC simply should not have problems with slow rate of rise on the supply. That's what brownout detectors are for.

Also the attached file with the scope capture won't download for me.

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

Bullshit, lots of chips have all sorts of restrictions on power up sequencing. If this was such a financial hardship for the OP why didn't he try to resolve the slow rate of rise of his power supply? He was willing to try the delayed I/O power up workaround but refused to address the root cause which could have been solved just as easily.

Letting the smoke out since 1978

 

 

 

 

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

I repeat that the problem is present also with a raise up in 1 mS. The ATMEL have admitted the problem.
Not all micro have the problem.
I repeat that I have found the problem also in EVK1100 evaluation board. Also ATMEL have found this problem in your evaluation boards "ATMEL: The internal team has confirmed the issue and we were able to reproduce it in lab. ".