AVR Freaks

He is seeing this with the sample he has acquired.

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

I have a physical AVR32DA28, will test tomorrow.

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).

> 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?

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.

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

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.

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. 

 @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...

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...

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

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?

Not that I know of. :-)