MEGA165A PCINT frustration

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

Non newbie AVR developer here, but I am new to PCINTs. Been using INT* for most of my projects.

There is no joy in PCINT land on this prj. INT0 works fine, but I can't get PCINT to trigger at all.

main.c:

ISR(INT0_vect) {
  lcd_putc('j');
}


ISR(PCINT0_vect) {
  lcd_putc('k');
}

int main(void) {
  PORTE |= _BV(PIN3); 
  EIMSK |= _BV(PCIE0);
  PCMSK0 |= _BV(PIN3);
  //int0 setup omitted, since it works.
  //lcd setup omitted but works as well, I get 'j' when INT0 goes low.
  sei();
  while(1);
}

I have verified PIN3 is high, and I can manually force it low with no results. If I move my IO over to INTO0, I can get my 'j' on the LCD when I manually trigger the line.

I feel like I am missing some setup piece to enable the interrupts, but the code samples I have seen look the same to me. Some talk of a PCICR, but I don't seem to have that on the 165a, at least not according to the datasheet and GCC.

I've tried grounding all of the pins on PortE manually, to no avail.

I know it's not a neat problem, but help would be most appreciated.

Jim Brain

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

Your code looks fine. I would be suspicious of the GCC header files. e.g. check the spelling of PCINT0_vect and any Warnings.

David.

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

I built the code - no obvious errors or warnings.

Quote:

I have verified PIN3 is high

Let's not get confused here. When you say "PIN3" you really mean pin 5 don't you (which is PE3). That is the (AIN1/PCINT3) pin.

(personally I would use "PE3" not "PIN3" to avoid this kind of confusion - PINn sounds too much like the physical pin number and especially in this case when PORTE just happens to be on the low numbered device pins).

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

Adopting the name conventions certainly makes life less confusing.

INT0 is on PD1. PCINT3 is on PE3. The package pin numbers may be of interest to you, but not much good for describing a signal.

The code looks ok. Cliff has compiled it.
I don't have a mega165 so I can't try it in real life.

I would still be a little wary of Atmel's Toolchain. In the past, they have b*ggered up the interrupt vector names. So it would be wise to quote which AS6 build you are using, and which avr-gcc version.

David.

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

david.prentice wrote:
Your code looks fine. I would be suspicious of the GCC header files. e.g. check the spelling of PCINT0_vect and any Warnings.

David.

Header file notwithstanding, I compiled with -Wall with no warnings or errors

GCC is:

avr-gcc (GCC) 4.7.0 20120217 - by SRMeister
GNU assembler (GNU Binutils) 2.22.52.20120219

Jim Brain

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

clawson wrote:
Let's not get confused here. When you say "PIN3" you really mean pin 5 don't you (which is PE3). That is the (AIN1/PCINT3) pin.

(personally I would use "PE3" not "PIN3" to avoid this kind of confusion - PINn sounds too much like the physical pin number and especially in this case when PORTE just happens to be on the low numbered device pins).

Well, I used to use PE3 for this naming, but it seemed newer code samples and header files were recommending PIN3 as a best practice.

But, I do mean PE3 (pin5 on tqfp footprint)

Jim

Jim Brain

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

david.prentice wrote:
I would still be a little wary of Atmel's Toolchain. In the past, they have b*ggered up the interrupt vector names. So it would be wise to quote which AS6 build you are using, and which avr-gcc version.

David.


I am not using AS, just straight avr-gcc (WinAVR 2010 upgraded with 4.7.2 gcc)

Jim

Jim Brain

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

The only thing I can see is the analog comparator on those pins, which is enabled by default. I'm not good at reading the Overriding Functions table. Perhaps setting ACD is worth a shot?

And/or, perhaps enable the whole PCINT0 bank, or most of it. Do any of the pins fire the pin-change interrupt?

Actually, I'm surprised that you aren't getting "spurious" indication(s); I'd think the flag might be set while configuring.

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

Quote:
I am not using AS, just straight avr-gcc (WinAVR 2010 upgraded with 4.7.2 gcc)

I am not aware of any official WinAVR release since 2010.

So I would be wary of any 'unofficial' build. Even though I would trust many Linux enthusiasts over Atmel's Toolchain builders.

I would inspect the generated ASM. i.e. the ISR() existence.
I would study the "alternate-function" mapping rules as suggested by Lee.

David.

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

I've not used the mega165, but most mega's I use have a pin change control reg, PCICR that enables the pin change interrupt at the port level, I did not see that in the code above. I did see the port bit enable mask PCMSK0 above.
JC

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

Ok, I found a datasheet for the M165, it does not have a PCICR register, but uses two bits in the EIMSK register to do that. You also need to set which of the 4 types of PC interrupts you want to trigger on in the EICRA register, the default is a low level, you probably want a falling edge trigger instead, as the low level trigger must be low long enough for it to be detected.
JC

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

Quote:

You also need to set which of the 4 types of PC interrupts you want to trigger on in the EICRA register, the default is a low level, you probably want a falling edge trigger instead, as the low level trigger must be low long enough for it to be detected.

Ummm--that discussion is n.a. for pin-change interrupts.

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 realized when I wrote the question I had not actually tested polling the lines directly, so I will try that next. I'd be more wary of the build env if every other single project I have did not compile and run perfectly. Still, I'll check the ASM output tonight.

Jim

Jim Brain

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

Quote:

Ummm--that discussion is n.a. for pin-change interrupts.

Your are correct, my bad. I see PE3 (I think that is what PIN3 references, although I don't think that has been made clear) is also used by the analog comparator, if it is enabled, would that disable the digital input on PE3 or not and prevent the pin change interrupt from working?

JC

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

I can verify that a polling of the pin works fine.

I'm not sure the best way to show ASM, but this is what GCC and friends spit out:

144               		.text
 145               		.cfi_sections	.debug_frame
 146               		.section	.text.__vector_2,"ax",@progbits
 147               	.global	__vector_2
 149               	__vector_2:
 150               	.LFB20:
 152               		.loc 1 27 0
 153               		.cfi_startproc
 154 0000 1F92      		push r1
 155               	.LCFI0:
 156               		.cfi_def_cfa_offset 3
 157               		.cfi_offset 1, -2
 158 0002 0F92      		push r0
 159               	.LCFI1:
 160               		.cfi_def_cfa_offset 4
 161               		.cfi_offset 0, -3
 162 0004 0FB6      		in r0,__SREG__
 163 0006 0F92      		push r0
 164 0008 1124      		clr __zero_reg__
 165 000a 2F93      		push r18
 166               	.LCFI2:
 167               		.cfi_def_cfa_offset 5
 168               		.cfi_offset 18, -4
 169 000c 3F93      		push r19
 170               	.LCFI3:
 171               		.cfi_def_cfa_offset 6
 172               		.cfi_offset 19, -5
 173 000e 4F93      		push r20
 174               	.LCFI4:
 175               		.cfi_def_cfa_offset 7
 176               		.cfi_offset 20, -6
 177 0010 5F93      		push r21
 178               	.LCFI5:
 179               		.cfi_def_cfa_offset 8
 180               		.cfi_offset 21, -7
 181 0012 6F93      		push r22
 182               	.LCFI6:
 183               		.cfi_def_cfa_offset 9
 184               		.cfi_offset 22, -8
 185 0014 7F93      		push r23
 186               	.LCFI7:
 187               		.cfi_def_cfa_offset 10
 188               		.cfi_offset 23, -9
 189 0016 8F93      		push r24
 190               	.LCFI8:
 191               		.cfi_def_cfa_offset 11
 192               		.cfi_offset 24, -10
 193 0018 9F93      		push r25
 194               	.LCFI9:
 195               		.cfi_def_cfa_offset 12
 196               		.cfi_offset 25, -11
 197 001a AF93      		push r26
 198               	.LCFI10:
 199               		.cfi_def_cfa_offset 13
 200               		.cfi_offset 26, -12
 201 001c BF93      		push r27
 202               	.LCFI11:
 203               		.cfi_def_cfa_offset 14
 204               		.cfi_offset 27, -13
 205 001e EF93      		push r30
 206               	.LCFI12:
 207               		.cfi_def_cfa_offset 15
 208               		.cfi_offset 30, -14
 209 0020 FF93      		push r31
 210               	.LCFI13:
 211               		.cfi_def_cfa_offset 16
 212               		.cfi_offset 31, -15
 213               	/* prologue: Signal */
 214               	/* outgoing args size = 0 */
 215               	/* frame size = 0 */
 216               	/* stack size = 15 */
 217               	.L__stack_usage = 15
  28:src/main.c    ****   lcd_putc('k');
 218               		.loc 1 28 0
 219 0022 8BE6      		ldi r24,lo8(107)
 220 0024 0E94 0000 		call lcd_putc
 221               	.LVL0:
 222               	/* epilogue start */
  29:src/main.c    **** }
 223               		.loc 1 29 0
 224 0028 FF91      		pop r31
 225 002a EF91      		pop r30
 226 002c BF91      		pop r27
 227 002e AF91      		pop r26
 228 0030 9F91      		pop r25
 229 0032 8F91      		pop r24
 230 0034 7F91      		pop r23
 231 0036 6F91      		pop r22
 232 0038 5F91      		pop r21
 233 003a 4F91      		pop r20
 234 003c 3F91      		pop r19
 235 003e 2F91      		pop r18
 236 0040 0F90      		pop r0
 237 0042 0FBE      		out __SREG__,r0
 238 0044 0F90      		pop r0
 239 0046 1F90      		pop r1
 240 0048 1895      		reti
 241               		.cfi_endproc
 242               	.LFE20:
 244               		.section	.text.startup.main,"ax",@progbits
 245               	.global	main
 247               	main:
 248               	.LFB21:
  30:src/main.c    **** 
  31:src/main.c    **** int main(void) {
 249               		.loc 1 31 0
 250               		.cfi_startproc
 251               	/* prologue: function */
 252               	/* outgoing args size = 0 */
 253               	/* frame size = 0 */
 254               	/* stack size = 0 */
 255               	.L__stack_usage = 0
  32:src/main.c    ****   lcd_init();
 256               		.loc 1 32 0
 257 0000 0E94 0000 		call lcd_init
 258               	.LVL1:
  33:src/main.c    ****   PORTE = 255;
 259               		.loc 1 33 0
 260 0004 8FEF      		ldi r24,lo8(-1)
 261 0006 8EB9      		out 0xe,r24
  34:src/main.c    ****   EIMSK |= _BV(PCIE0);
 262               		.loc 1 34 0
 263 0008 EE9A      		sbi 0x1d,6
  35:src/main.c    ****   PCMSK0 =255;
 264               		.loc 1 35 0
 265 000a 8093 6B00 		sts 107,r24
  36:src/main.c    ****   sei();
 266               		.loc 1 36 0
 267               	/* #APP */
 268               	 ;  36 "src/main.c" 1
 269 000e 7894      		sei
 270               	 ;  0 "" 2
  37:src/main.c    ****   if(PINE & _BV(PE3))
 271               		.loc 1 37 0
 272               	/* #NOAPP */
 273 0010 639B      		sbis 0xc,3
 274 0012 00C0      		rjmp .L3
  38:src/main.c    ****     lcd_putc('E');
 275               		.loc 1 38 0
 276 0014 85E4      		ldi r24,lo8(69)
 277 0016 00C0      		rjmp .L6
 278               	.L3:
  39:src/main.c    ****   else
  40:src/main.c    ****     lcd_putc('e');
 279               		.loc 1 40 0
 280 0018 85E6      		ldi r24,lo8(101)
 281               	.L6:
 282 001a 0E94 0000 		call lcd_putc
 283               	.LVL2:
  41:src/main.c    **** 
  42:src/main.c    ****   DDRG|=(1<<PG4);
 284               		.loc 1 42 0
 285 001e 9C9A      		sbi 0x13,4
 286               	.L5:
  43:src/main.c    ****   while(1) {
  44:src/main.c    ****     PORTG^=(1<<PG4);
 287               		.loc 1 44 0 discriminator 1
 288 0020 84B3      		in r24,0x14
 289 0022 90E1      		ldi r25,lo8(16)
 290 0024 8927      		eor r24,r25
 291 0026 84BB      		out 0x14,r24
 292 0028 00C0      		rjmp .L5
 293               		.cfi_endproc

Jim Brain

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

Does PCMSK0 really correspond to port E?

Iluvatar is the better part of Valar.

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

Quote:

but this is what GCC and friends spit out:

Suggest you run that through this:

http://spaces.atmel.com/gf/proje...

It will remove all the .cfi/.loc nonsense leaving readable code.

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

Quote:
Does PCMSK0 really correspond to port E?
Yes. PCINT0-PCINT7 are on PORTE.

Regards,
Steve A.

The Board helps those that help themselves.

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

After spending 2 months on this, I am ready to claim there is either a bug in PCINT operation on ATMEGA165A units, or I have a defective part. To eliminate any of the concerns raised about my GCC environment, I have compiled the following code in AVRStudio v5.1.208:

#include 
#include 
ISR(PCINT0_vect) {  PORTG^=_BV(PG4); }

int main(void) {
  DDRG |= _BV(PG4);
  EIMSK |= (_BV(PCIE0));
  PCMSK0 = 255;
  PORTE = 255;
  sei();
  while(1) {}
}

There is no activity on PG4 when I bring any of the PCINT lines low (or high, anything).

No errors or warnings on either compiler, and I have -Wall set.  The following code works fine on ATMEGA1281:

ISR(PCINT0_vect) {
  PORTE^=_BV(PE3);
}

int main(void) {
  DDRE |= _BV(PE3);

  PCICR |= (_BV(PCIE0));
  PCMSK0 = 255;
  PORTB = 255;
  sei();

  while(1) { }
}

If someone has a spare ATMEGA165a sitting around, I'd appreciate some confirmation that PCINT is broken or confirmation that it must be my specific uC here on the bench.

Jim

Jim Brain

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

The program works fine for me on a ATmega165 16AI.

By the way, Atmel Studio 5.x is known to be very buggy.

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

snigelen wrote:
The program works fine for me on a ATmega165 16AI.

By the way, Atmel Studio 5.x is known to be very buggy.

So, when you ground a PCINT0 line, the PG4 toggles?

I did not know that about AS5.1, but I don't use it. I just compiled under it because earlier comments were suspicious of my AVRGCC 2010 with an upgraded GCC 4.7.2, and I agreed it might indeed be my toolchain.

So, is the M165 and M165A just a die shrink in difference?, or is there more?

I'm just leery of buying another M165A (or PA) desoldering this 64 pin from the converter board, soldering the new one on there, wiring it all up, and having it fail in the same exact way.

Jim

Jim Brain

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

jbrain wrote:
So, when you ground a PCINT0 line, the PG4 toggles?
Yes, and since it's Pin Change, it toggles on the way up too.
Quote:
So, is the M165 and M165A just a die shrink in difference?, or is there more?
I don't know, but that's usually the only difference between non-A and A-versions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
#include 
#include 
ISR(PCINT0_vect) {  PORTG^=_BV(PG4); }

int main(void) {
  DDRG |= _BV(PG4);
  EIMSK |= (_BV(PCIE0));
  PCMSK0 = 255;
  PORTE = 255;
  sei();
  while(1) {}
}

Just for kicks, post the output of avr-objdump -S for the above compiled under gcc.

Do the same for this:

ISR(PCINT0_vect) {
  PORTE^=_BV(PE3);
}

int main(void) {
  DDRE |= _BV(PE3);

  PCICR |= (_BV(PCIE0));
  PCMSK0 = 255;
  PORTB = 255;
  sei();

  while(1) { }
}

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

Isn't this the second thread on '165 pin-change recently?

Anyway, I've got a guess, based on a Forum search and my work in a previous thread:
https://www.avrfreaks.net/index.p...
https://www.avrfreaks.net/index.p...

Quote:
There is a migration app note, AVR529, that indicates that a few I/O bits have moved. they seem to be related to pin-change.

I pulled up the app note, and since the IE bits have moved one would need to be sure that the code is being built for the correct target and that the chip include file is proper with respect to those bits.
Quote:

34:src/main.c **** EIMSK |= _BV(PCIE0);
262 .loc 1 34 0
263 0008 EE9A sbi 0x1d,6


Mega165P: PCIE0 is bit 6.
Mega165A: PCIE0 is bit 4.

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

theusch wrote:
theusch wrote:
There is a migration app note, AVR529, that indicates that a few I/O bits have moved. they seem to be related to pin-change.
I pulled up the app note, and since the IE bits have moved one would need to be sure that the code is being built for the correct target and that the chip include file is proper with respect to those bits.
 34:src/main.c    ****   EIMSK |= _BV(PCIE0);
 262                     .loc 1 34 0
 263 0008 EE9A            sbi 0x1d,6

Mega165P: PCIE0 is bit 6.
Mega165A: PCIE0 is bit 4.

Good catch.

So the OP is building for the 165P, either:

    - by mistake - intentionally
      - not realising the difference - because the 165A isn't supported by his toolchain
    - his toolchain (WinAVR 2010 upgraded with 4.7.2 gcc) has an incorrect device header file for the 165A
Fair assessment?

"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

No matter whether I set MCU to 165, 165p, or 165a, I always get:


  EIMSK |= (_BV(PCIE0));
  72:	ee 9a       	sbi	0x1d, 6	; 29

In both avrstudio 5.1 and my WinAVR 2010 (GCC was the only thing changed, not the H files)

I never dreamed neither had an include file for 165a (I am compiling for 165a, but you are correct, neither has an include file for 165a, it's just 165.)

And, I read 529, but didn't think that section applied since I don't have a PA. Just a 165A.

So, since my trusty upgraded WinAVR has failed me after all these years, what do folks use nowadays if they don't need all of AVRStudio? (I use Eclipse for all of my projects)

Jim

Jim Brain

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

Quote:
what do folks use nowadays if they don't need all of AVRStudio?
I stil use Studio 4.18 unless I'm working with a chip not supported by that version.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I have a couple of toolchains installed.

$ cd /usr/local
$ grep PCIE0 *avr*/avr/include/avr/*165*
avr8-gnu-toolchain-3.4.1-linux_x86_64/avr/include/avr/iom165.h:#define PCIE0   6
avr8-gnu-toolchain-3.4.1-linux_x86_64/avr/include/avr/iom165pa.h:#define PCIE0   4
avr8-gnu-toolchain-3.4.1-linux_x86_64/avr/include/avr/iom165p.h:#define PCIE0   6
avr8-gnu-toolchain-3.4.2-linux_x86_64/avr/include/avr/iom165.h:#define PCIE0   6
avr8-gnu-toolchain-3.4.2-linux_x86_64/avr/include/avr/iom165pa.h:#define PCIE0   4
avr8-gnu-toolchain-3.4.2-linux_x86_64/avr/include/avr/iom165p.h:#define PCIE0   6
avr/avr/include/avr/iom165.h:#define PCIE0   6
avr/avr/include/avr/iom165p.h:#define PCIE0   6
avr-gcc-4.7.2/avr/include/avr/iom165.h:#define PCIE0   6
avr-gcc-4.7.2/avr/include/avr/iom165p.h:#define PCIE0   6
avr-gcc-4.8.0/avr/include/avr/iom165.h:#define PCIE0   6
avr-gcc-4.8.0/avr/include/avr/iom165p.h:#define PCIE0   6

So there is a iom165pa.h where PCIE0 is 4 instead of 6. This file does not exist in the official avr-libc release, it's added by Atmel in their toolchains.

Does it work if you set bit 4 instead of bit 6?

Nobody is (should be) using Atmel Studio 5.x, they (windows users) usually use version 6.1 (or maybe 4.18/4.19).

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

Quote:

usually use version 6.1

And not just 6.1 but 6.1.2674 (which is 6.1 with SP1.1).

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

It does indeed work if I use the sample code in AVR529 to handle the double case. I didn't like that, so I modded WinAVR's include files to add a iom165a and iom165pa include files, with the define corrected. (and the fixup in io.h).

And, dloading 6.1.2674 (or whatever was the newest today) I'll see if I can switch over to it while keeping my Makefiles and avrdude working...

Jim Brain

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

Interestingly, "Atmel Studio 6.1 update 1.1 (build 2674) Installer – Full" has the same issue :-) I'm looking at the toolchain dir for AVR8, and avr/iom165a.h just includes iom165.h, which has 6/7 for the bits, not 4/5...

Sigh...

iom165pa.h is OK, though.

A quick hack to #undef PCIE0/1 after including iom165.h and redefining them to be correct has fixed the issue. Not sure where such things get logged, if others see the same thing.

And, I checked my part number to make sure I hadn't misread it. atmega165a, Device signature 0x1e9410

Jim

Jim Brain

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

jbrain wrote:
Interestingly, "Atmel Studio 6.1 update 1.1 (build 2674) Installer – Full" has the same issue :-) I'm looking at the toolchain dir for AVR8, and avr/iom165a.h just includes iom165.h, which has 6/7 for the bits, not 4/5...
I can confirm that the issue exists with the Atmel toolchain 3.4.2 for Linux. The file iom165.h has (apart from comments) but one line in it:
#include "iom165.h"

Quote:
iom165pa.h is OK, though.
I would suggest including this file instead, but it has new bits in MCUCR that are not in the 165a (BODS and BODSE).

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

If anyone wants this corrected it must be reported to a Bugzilla. I guess you have two choices - if you want it in generic AVR-LibC which may eventually filter back to Atmel's version then report it to Savannah. If you want a more immediate fix in Atmel's toolchain but no guarantee that it might ever make it back to the main branch of AVR-LibC then use Atmel's own bug reporting system.

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

Saaadhu have made a bug report about this for avr-libc.

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

Quote:

A quick hack to #undef PCIE0/1 after including iom165.h and redefining them to be correct has fixed the issue. Not sure where such things get logged, if others see the same thing.

Indeed. Certainly "I feel your pain", and you must have had a lot of frustration to get to this point. It is good to get the situation reported, but once the cause was figured out put in the workaround and go forward. (In my toolchain the target AVR model is a preprocessor symbol, so conditional-compilation can be done in that to accommodate the various flavours of e.g. '165.)

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

It's been a learning experience, for sure. I suppose these should be a "stages" setup for forum posts of this sort:

Confusion: I am not a _n00b_, but this does not work
Frustration: OK, I've tried it all, and the uC must be wrong
Embarrassment: Um, well, I swear I *did* search the forum and Google for this before asking, my bad for not seeing AVR529 (wasn't searching for 165pa, though...)
Vindication (well, somewhat): OK, so I was an idiot for thinking the uC was borked, but the issue really exists on new tooling...

insert others as appropriate for other topics...

I suppose I should be grateful, that, probably because doing AVR is not my day job and such my use hovers midway between day job use and hobbyist, this is the first time my AVR tooling has failed me. And, I've gotten a ton of mileage out of WinAVR 2010, upgraded a few times via patching... But, all good things come to an end. I moved my setup over to 4.7.2 in AS6.1SP1.1 last night, and just copied avrdude and make into a sep dir to use. Makefiles are happy. But, kept the old toolchain on the PC, just in case... :-)

Above all, this breadboard prj sitting on my bench is now working (all the code was working all along, just waiting for a good trigger), and now I can finish the prj and get it in the store.

I sent a note about the bug to avr-gcc mailing list and it's been filed, as noted above.

Yep, I debated a number of ways to add the fix, but decided in the end to make a quick hack and save a better conditional for another day (I think m165pa should be reworked to be conditional, as it is *ALMOST* verbatim the m165 include, and then m165a would follow in the same vein)

Maybe I'll whip up a patch and send. Right now, am just excited that something is working, since I pored over that code for hours.

Jim

Jim Brain