AVR32DA28 interrupt vector size - discrepancy between data sheet and real chip

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

Does anybody use AVR32DA28?

According to the datasheet vector size is 2-words (4 bytes), AS7 with AVR-Dx_DFP 1.5.74 generate code with such vectors (2-words).

 

But in real chip, vector size is only 1-word (2-bytes).

I tested it with NMI interrupt (small program in ASM), after invoke interrupt program jumps to PC=0x0001 not 0x0002.

 

Can anyone confirm this?

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

Contact Microchip support with your issue.

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

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


 

Not sure where you are seeing this. I built a test:

 

 

Admittedly -mrelax (the default) means the JMPs have been relaxed to RJMPs so from 2 word (4 byte) to 1 word (2 byte) opcodes but the space has been filled with 00 00 so they are spaced 4 bytes apart.

 

If I disable -mrelax then:

 

 

but the actual locations of the jumps (now JMPs) hasn't changed - they are still 0:, 4:, 8:, c:, 10: ...

 

EDIT: forgot to include this...

 

Last Edited: Tue. Oct 20, 2020 - 05:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

He is seeing this with the sample he has acquired.

 

@TeleVox, just contact support and they will sort you out.

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

I made the case in Microchip Technical Support.

But I thought maybe someone had already solved this problem.

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

There are two 1word instructions per vector. The rjmp is first one word instruction followed by nop (second 1 word). It doesn't have to 2word instruction like jmp.

Btw PC might be counting words not bytes (usually it's not possible to have instruction in seconf half word)

 

There is also some note:  devices with 8 KB of Flash or less use RJMP instead of JMP, which takes only two clock cycles.

Computers don't make errors - What they do they do on purpose.

Last Edited: Tue. Oct 20, 2020 - 05:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

KIIV_cz wrote:

There are two 1word instructions per vector. The rjmp is first one word instruction followed by nop (second 1 word). It doesn't have to 2word instruction like jmp.

Btw PC might be counting words not bytes (usually it's not possible to have instruction in seconf half word)

 

There is also some note:  devices with 8 KB of Flash or less use RJMP instead of JMP, which takes only two clock cycles.

 

The problem is that Vector Adresses are wrong:

After compilation:

RESET Vector 0x0000 (word)

NMI Vector 0x0002 (word)

BOD Vector 0x0004 (word)

...

 

But proper adresses (tested in real chip) are:

RESET Vector 0x0000 (word)

NMI Vector 0x0001 (word)

BOD Vector 0x0002 (word)

 

The similar problem for another AVR family was discussed here:

https://www.avrfreaks.net/forum/...

 

 

 

 

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

I have a physical AVR32DA28, will test tomorrow.

 

TeleVox wrote:

The similar problem for another AVR family was discussed here:

https://www.avrfreaks.net/forum/...

 

That one is the reverse, 4 bytes when it should be 2. It's mostly an inconvenience. But for the avr32da28 it's a serious problem, 2 byte rjmp vectors can't reach the whole memory of this chip (32KB).

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

At least I have already made products with DA28 and DA32.

This is the vector table for the product.

No matter what you think of op, it is a fact that it works normally.

 

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

> Can anyone confirm this?

 

I can confirm at least strange behavior...

 

I have a design with an AVR32DA28. The RTC CMP interrupt triggers the ISR(BOD_VLM_vect) instead of ISR(RTC_CNT_vect).

 

My vector table:

00000000 <__vectors>:
   0:	0c 94 58 00 	jmp	0xb0	; 0xb0 <__ctors_end>
   4:	0c 94 6a 00 	jmp	0xd4	; 0xd4 <__bad_interrupt>
   8:	0c 94 94 00 	jmp	0x128	; 0x128 <__vector_2>
   c:	0c 94 c2 00 	jmp	0x184	; 0x184 <__vector_3>
  10:	0c 94 6a 00 	jmp	0xd4	; 0xd4 <__bad_interrupt>

I isolated the code to an LED-blink application:

#define F_CPU 400000UL
#include <stdbool.h>
#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>
#include <avr/sleep.h>

volatile bool _interrupt = false;

int main(void) {

	PORTD.DIRSET = PIN5_bm;

	while (RTC.STATUS > 0)
		;
	RTC.CLKSEL = 0x00;
	RTC.CNT = 0;
	RTC.INTCTRL = RTC_CMP_bm;
	RTC.CTRLA = RTC_RUNSTDBY_bm | RTC_RTCEN_bm;

	set_sleep_mode( SLEEP_MODE_IDLE);
	sei();

	while (1) {
		sleep_mode();
		PORTD.OUTTGL = PIN5_bm;
	}
}

ISR( BOD_VLM_vect) {
	RTC.INTFLAGS = RTC_CMP_bm;
	RTC.CMP = RTC.CMP + 0xffff/4;
	_interrupt = true;
}

//ISR( RTC_CNT_vect) {
	////RTC.INTFLAGS = RTC_CMP_bm;
	////RTC.CMP = RTC.CMP + CMP_FREQ;
	//_interrupt = true;
//}

ISR( BADISR_vect) {
	_interrupt = true;
}

 

I played around to catch every other interrupt. But with the code above, the LED blinks perfectly, without any bad ISR.

 

Any ideas?

 

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

It's really strange.
My DA28 does not trigger BOD_VLM_vect.
Difference in DFP version?

 

TEST code

 

Test view

Last Edited: Wed. Oct 21, 2020 - 09:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@kabasan

 

What chip (AVR32DA28, AVR64DA28, AVR128DA28) are you testing on ?

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

My chip is 128DA28.
Is it the same problem as ATmega809?

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

I confirm the bug on AVR32DA28. Test code (Atmel assembler):

 

.include "AVR32DA28def.inc"

  rjmp  start 

.org RTC_PIT_vect/2
  rjmp  bug_isr

.org RTC_PIT_vect
  rjmp  no_bug_isr

.org INT_VECTORS_SIZE
start:
  ;set PA6 and PA7 as output
  ldi   r16, 0b11000000
  out   VPORTA_DIR, r16
  ;setup PIT to generate periodic interrupt every 1/4 s
  ldi   r16, RTC_CLKSEL_OSC1K_gc
  sts   RTC_CLKSEL, r16
  ldi   r16, RTC_PI_bm
  sts   RTC_PITINTCTRL, r16
  ldi   r16, RTC_PERIOD_CYC256_gc | RTC_PITEN_bm
  sts   RTC_PITCTRLA, r16
  ;setup working register for ISRs
  clr   r17
  ;setup a blink pattern
  ldi   r16, 0b01010011
  ;enable global ISrs
  sei
end:
  rjmp end

bug_isr:
  ;blink LED on PA6
  bst   r16,7
  rol   r16
  bld   r16, 0
  in    r17, VPORTA_OUT
  bld   r17, 6
  out   VPORTA_OUT, r17
  ;clear ISR flag
  ldi   r17, RTC_PI_bm
  sts   RTC_PITINTFLAGS, r17
  reti

no_bug_isr:
  ;blink LED on PA7
  bst   r16,7
  rol   r16
  bld   r16, 0
  in    r0, VPORTA_OUT
  bld   r0, 7
  out   VPORTA_OUT, r0
  ;clear ISR flag
  ldi   r17, RTC_PI_bm
  sts   RTC_PITINTFLAGS, r17
  reti

I observe blinking on pin A6, correct behaviour would be blinking on A7.

 

edit: I will now test on AVR128DA28.

Last Edited: Wed. Oct 21, 2020 - 10:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see

if interrupts are skipped to half 0x06 instead of vector address 0x0C, it can trigger BOD_VLM_vect with "Relax".

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

I confirm no bug on AVR128DA28. This one is blinking PA7 as expected.

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


So this is a case for the microchip support? @TeleVox, you already contacted them?

 

Any ideas for a workaround? In C? We have some nice fresh boards here in the lab assembled with AVR32DA32 waiting for software...

 

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

volkerk wrote:
Any ideas for a workaround? In C?

 

Regarding the vector table size, I'm sure it's possible, but not exactly how. You can always create your own.

Regarding how to make sure the ISRs are in the accessible region, if they are less than 4KB in size you can place them in one of the user reserved init sections. See  https://www.nongnu.org/avr-libc/user-manual/mem_sections.html

You probably need to call main() from another, previous init section to avoid the ISRs being all executed on startup.

 

edit:

for example, add this code to your program

void main_jmp() __attribute__((naked, used, section(".init7")));
void main_jmp() {
  asm volatile ("call main");
  asm volatile ("jmp _exit");
}

then all the ISRs need to go to section init8 or init9. This should solve the ISR placement problem.

The difficult part for me is to make the vector table be 2 bytes.

 

volkerk wrote:
So this is a case for the microchip support? @TeleVox, you already contacted them?

I suppose. IMO these chips should be recalled and replaced at Microchip's expense. After all they claim:

 

Functional Safety:
This product is recommended for safety critical applications targeting both industrial and automotive products (IEC 61508 and ISO 26262). Necessary documentation such as FMEDA report and Safety Manual can be provided on request. Certified development tools are also available for this product. Please contact your local Microchip sales office or your distributor for more information.

when in reality they don't even work correctly. 

Last Edited: Wed. Oct 21, 2020 - 12:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

volkerk wrote:
So this is a case for the microchip support? @TeleVox, you already contacted them?

Yes, I'm waiting for replay.

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

 @el-tangas Thanks a lot for your suggestions! I will try to find a way around the problem in the next days...

 

One more simple idea:
In the CPUINT-module there is a bit called CVT (Compact Vector Table).
This can be used to reduce the vector-table to three entries: NMI, HIGH and LOW.

 

I've tried this and it seems that all LOW interrupts go into the ISR(BOD_VLM_vect). Since my application is not very critical in timing, this may work for me as a temporary workaround. I hope that Microchip will come up with a more professional solution in the next DFP. Don't want to re-work all my boards...

 

 

 

 

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

This issue only affects the AVR32DA-devices, with 32kb flash. They are being recalled, and will be replaced.

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

volkerk wrote:

I've tried this and it seems that all LOW interrupts go into the ISR(BOD_VLM_vect). Since my application is not very critical in timing, this may work for me as a temporary workaround.

 

Yes that should be a way out. There is an appnote with example code on how to do this. The code needs to be changed to account for the bug, but nothing major.

http://ww1.microchip.com/downloa...

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

je_ruud wrote:

This issue only affects the AVR32DA-devices, with 32kb flash. They are being recalled, and will be replaced.

 

What does it mean?

Can I return faulty chips, but to whom ?

How to identify defective by production date?

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

Contact support, they will get you going wink

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

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

Does it change if there is a bootloader section?

 

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

Is this confirmed as hardware or toolchain bug? List of chips affected? I was about to start a project with these chips.

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

It is an issue in the device, which has been identified and fixed in production. It only affects the 32k flash variants of AVR DA, the AVR32DA48, AVR32DA32 and AVR32DA28 devices. The devices already in the market are being recalled and replaced. If you have any of these devices please contact Microchip Support.

 

It is safe to start projects with these chips. If you need samples really fast for testing and prototyping you can use the AVR128DA or AVR64DA variants until the AVR32DA arrives.

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

je_ruud wrote:

It is an issue in the device, which has been identified and fixed in production.

 

Already fixed? That means you knew about the problem and still did not inform your customers? Really?

 

Are there any other problems with these chips we don't know?

Last Edited: Thu. Oct 22, 2020 - 07:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

volkerk wrote:

Already fixed? That means you knew about the problem and still did not inform your customers? Really?

The issue hasn't been known for very long. As soon as we became aware of it we analyzed it, found the source and fixed it.
It was decided to recall and replace all samples already shipped. How that will be taken care of is a part of the business I'm not familiar with, which is why I recommend anybody with these samples to contact support.

 

volkerk wrote:

Are there any other problems with these chips we don't know?

Not that I know of. :-)

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

je_ruud wrote:

Not that I know of. :-)

 

Ok, sounds good!

 

But there are not only a few samples out there. There are still thousands of these parts waiting at digikey to frustrate your customers...

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

volkerk wrote:
still thousands of these parts waiting at digikey
I kind of doubt that. The ones at major distributors like Digikey/Farnell/RS will be the easy ones for them to recall (and I imagine they have already been told to not ship any for the time being). it's the ones that have "got out" into the wider world that will be more difficult to track I imagine.

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

The next question would be how do we tell which one is a good chip or a defective one?

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

So as I understand it these are sample chips?

 

...you may use the Samples only to evaluate them specifically for (i) qualifying one or more Microchip products for use in your existing product designs, or (ii) designing or developing your new products designs incorporating one or more Microchip products.

 

...so they shouldn't be in any finished products anyways.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Brian Fairchild wrote:
So as I understand it these are sample chips?

 

Mine are just samples (in fact I've decided to just keep them as souvenirs of this mess-up), but I think others have actual commercial chips.

 

Kartman wrote:
The next question would be how do we tell which one is a good chip or a defective one?

 

Well, if you can upload software, it's easy, I already posted a test program in #14. Visually, I can post pics of mine:

 

 

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

I have just received 225 assembled boards (PCBA) having the AVR32DA48 datecode 2021.

Now, in May 2022.

Guess what, they are not working. Of course.

I wonder how many AVR32 2021 chips did Microchip sell and how many did they get back.

 

 

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

rammon wrote:

Guess what, they are not working. Of course.

 

Where did the chips come from? An official source?

 

Have you tried the workarounds detailed above?

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

It should be simple enough to fix the code.   i.e. use a one-word RJMP table.   And trampolines if necessary.

 

Of course this is only good for a product that will NEVER be re-programmed in the wide world.   e.g. 99% of consumer devices.

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

Official source? Who's who official?

The source official or not was able to deliver 500 boards (chips), 225 of datecode 2021, and the rest of datecode 2141.

2141 work like a charm. 2021 not.

As for myself, I wasn't even aware of this potential problem. I am lucky that I found this thread, after hours of debugging defective chips. I was able to identify the problem being in the interrupt system, and this thread gave me some more info and workarounds.

I was also lucky that I have boards with good chips as a reference.

And BTW,

The problem  is not that simple as you may think. Indeed, the vectors are only one word long, but there is another issue: they work as expected (it seems) at address 0 and in boot mode. if you have a bootloader and an application at different address (I have, and the app is at 0x3000), the things are a bit weird. I'm experiencing a weird behavior right after startup, and I'm not able to explain it yet. The thing is this: I have some blinking led patterns at startup, one pattern for bootloader, and another one for app. The blinking patterns function on a timer interrupt. In the bootloader it functions correctly. In the app code the blinking is very fast, so there is a problem with the timer/interrupt. But only in the app, so with IVSEL=0 and vectors at 0x3000.

Weird enough, after this wrong blinking at startup, everything seems to work normally, even the timer/timing.

I'm using the CVT and I have only three interrupts, TCB0, and USART0 RXC and DRE.

So tell me you guys and/or Microchip: What can I do? Can I trust these AVR32DA48 2021 chips or not?

 

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

rammon wrote:
the problem being in the interrupt system,

...
So tell me you guys and/or Microchip: What can I do?

Create a technical support case.

Reason : customers do identify failures

This failure isn't obvious in my read of the errata.

AVR32DA Silicon Errata and Data Sheet Clarification

 


SupportService

 

"Dare to be naïve." - Buckminster Fuller

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

gchapman wrote:

rammon wrote:
the problem being in the interrupt system,

...
So tell me you guys and/or Microchip: What can I do?

Create a technical support case.

Reason : customers do identify failures

This failure isn't obvious in my read of the errata.

AVR32DA Silicon Errata and Data Sheet Clarification

 


SupportService

 

Microchip knows about the problem.

They identified it, fixed it, and decided to recall all shipped chips and replace them.

The problem never got in the errata sheet. They didn't bother to add it, even with a "workaround: none".

I don't have time for Microchip support in my case. And I don't feel it is right to wait NOW for a support that should have been known long time ago.

Shits happen, but they decided not to tell anyone about this problem.

I already have a messy workaround now. I use the vectors at 0x0000 in boot area, for both boot and app code. With a way to distinguish which is which.

The boards with the messy chips pass all the regular tests. You cannot tell what board has what chip.

But I know there are two kind of chips, and I know there are two firmware versions for the same pcb revision and the same chip.

Not to say that these two firmware versions are the 2nd and 3rd, because the first one is for ATmega3209...

Pin to pin compatible, yes. Firmware (binary) compatible... nope.

 

 

 

 

 

 

 

 

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

I thought the fault only appeared in sample chips?

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Presumably the whole batch with datestamp 2021 has the problem.

 

Surely you can identify the suspect boards by just looking at the datecode.   Program custom firmware on them.

As I said earlier this is only practical if the user is never going to re-program the boards.   Only you know your product.

 

You can probably identify the suspect batch from the Wafer Number.   i.e. electronically.

 

But if they are commercial chips,  Microchip should supply you with replacements and the cost of board rework.

 

David.

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

david.prentice wrote:

Presumably the whole batch with datestamp 2021 has the problem.

 

Surely you can identify the suspect boards by just looking at the datecode.   Program custom firmware on them.

As I said earlier this is only practical if the user is never going to re-program the boards.   Only you know your product.

 

You can probably identify the suspect batch from the Wafer Number.   i.e. electronically.

 

But if they are commercial chips,  Microchip should supply you with replacements and the cost of board rework.

 

David.

Complete compatibility is very hard to obtain. Not impossible though.

My board initially used atmega3209. When the 500x order came, I wasn't able to find 500 atmega3209 chips at the distributors. Not even atmega4809.

Atmega4809 is binary compatible with a firmware compiled for atmega3209. BUT, not 100%. Because there is no programming software that automatically detects what chip do you have onboard.

This is the Atmel/Microchip way. And so, you need two different programming scripts/procedures for the very same binary.

In contrast, I have a board with an STM8S207C6. This is very hard to find now/very expensive. But I can use an STM8S105C6, incidentally. Completely compatible in every way. Even you, as the factory/manufacturer don't need to know what chip do you stuff onboard. This is ST way. ST programming softwares never needs you to tell them what chip do you have. Everything is automatically discovered.

 

 

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

Yes,  ST is "friendly".    But the programming procedure still identifies the chip ID.   And they have Silicon revisions too.

 

I guess that an operator places the board onto a test-jig.   Programs, tests, ...

 

Either you read the wafer number / date as the first stage in the jig.   To determine the firmware.

Or you manually fill two bins.   Program custom firmware on the boards from the "special" bin.

 

Yes it would be a nightmare for random boards.   But you say that you have a stack of brand new boards fresh from the Assembly House.

I bet that the "suspect" boards are already grouped together in certain boxes,

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

david.prentice wrote:

Yes it would be a nightmare for random boards.   But you say that you have a stack of brand new boards fresh from the Assembly House.

I bet that the "suspect" boards are already grouped together in certain boxes,

Haha, they were "random" boards. The assembly house didn't care what chip revision was which. In the end they were the same chip weren't they?

 

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

Can you read the chip markings ?  e.g. with anglepoise lamp and magnifying glass.

 

Manually sort into two boxes.

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

david.prentice wrote:

Can you read the chip markings ?  e.g. with anglepoise lamp and magnifying glass.

 

Manually sort into two boxes.

I can read the chip markings easily, but I have found a better way anyway. I've programmed all the boards first with the good/normal firmware (the one for the good chips). Immediately after the programming, the chip is reset and does the led blinking pattern. This is a very fast sign what the chip is, because the "bad" chips don't do the blinking. Put the good boards in the good bin and the bad boards in the bad bin. Then took the bad bin and reprogram the bad boards with the bad firmware. And voila! A bad board with a bad firmware become a good board! wink

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

El Tangas wrote:

Brian Fairchild wrote:
So as I understand it these are sample chips?

 

Mine are just samples (in fact I've decided to just keep them as souvenirs of this mess-up), but I think others have actual commercial chips.

 

Kartman wrote:
The next question would be how do we tell which one is a good chip or a defective one?

 

Well, if you can upload software, it's easy, I already posted a test program in #14. Visually, I can post pics of mine:

 

 

TME has this chip in stock. AVR32DA28 datecode 2021. Well, not "KMW". You can look at it because they have pictures.

Or maybe there is only the picture wrong?

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


I'm checking TME and the picture there is actually 2021KMW, the exact same I have, but yeah, maybe it's just an old picture. Better confirm the datecode before buying though.

 

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

Is the "e3" indicating an engineering sample chip??

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly