Xmega128D4 still broken!

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

I have updated, yet again, Studio to see if this problem had been fixed but it hasn't yet. It was broken in the previous version of Studio but worked well about 2 or 3 versions ago. The project was finished and the board has been working for several months but can't rebuild the project.

 

 

This topic has a solution.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Sun. Aug 19, 2018 - 03:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By the way I have 3 back ups of the successfully built project, can't find the Studio version number but I can see the device pack version as being XMEGAD_DFP/1.1.52 and this WORKED.

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 never used a D4.   I have only used A1 and A4.  

 

Looking at the iox124a4u.h header:

/* Compare or Capture A Interrupt Level */
typedef enum TC_CCAINTLVL_enum
{
    TC_CCAINTLVL_OFF_gc = (0x00<<0),  /* Interrupt Disabled */
    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
    TC_CCAINTLVL_MED_gc = (0x02<<0),  /* Medium Level */
    TC_CCAINTLVL_HI_gc = (0x03<<0),  /* High Level */
} TC_CCAINTLVL_t;

...

/* TC0.INTCTRLB  bit masks and bit positions */
#define TC0_CCAINTLVL_gm  0x03  /* Compare or Capture A Interrupt Level group mask. */
#define TC0_CCAINTLVL_gp  0  /* Compare or Capture A Interrupt Level group position. */
#define TC0_CCAINTLVL0_bm  (1<<0)  /* Compare or Capture A Interrupt Level bit 0 mask. */
#define TC0_CCAINTLVL0_bp  0  /* Compare or Capture A Interrupt Level bit 0 position. */
#define TC0_CCAINTLVL1_bm  (1<<1)  /* Compare or Capture A Interrupt Level bit 1 mask. */
#define TC0_CCAINTLVL1_bp  1  /* Compare or Capture A Interrupt Level bit 1 position. */

...

This header looks logical.   i.e. xxxxINTLVL_xx_gc values in an enum with specific defines for xxxxINTLVLxx_bm bitmasks.

 

How are you using symbols like TC_TC0_CCAINTLVL_LO_gc ?

 

I suspect that your earlier "working version" had inconsistent header files.

 

But most importantly,  please click on the errors.   And paste the offending lines from main.c and on.c

 

David.

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

Your symbol is surely misnamed?

D:\atmel_avr\avr8-gnu-toolchain-win32_x86\avr\include\avr>grep CCAINTLVL_LO_gc iox128d4*.h
    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */

So there is a TC_CAINTLVL_LO_gc but no version with "TC0" in the name (presumably so that the same can be used for multiple TCn ?). It's not just the 128D4, seems fairly consistent:

D:\atmel_avr\avr8-gnu-toolchain-win32_x86\avr\include\avr>grep CCAINTLVL_LO_gc iox*.h
iox128a1.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox128a1u.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox128a3.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox128a3u.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox128a4u.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox128b1.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox128b3.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox128c3.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox128d3.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox128d4.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox16a4.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox16a4u.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox16c4.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox16d4.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox16e5.h:    TC45_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox16e5.h:    TC45_LCCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox192a3.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox192a3u.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox192c3.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox192d3.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox256a3.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox256a3b.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox256a3bu.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox256a3u.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox256c3.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox256d3.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox32a4.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox32a4u.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox32c3.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox32c4.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox32d3.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox32d4.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox32e5.h:    TC45_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox32e5.h:    TC45_LCCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox384c3.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox384d3.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox64a1.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox64a1u.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox64a3.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox64a3u.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox64a4u.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox64b1.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox64b3.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox64c3.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox64d3.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox64d4.h:    TC_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox8e5.h:    TC45_CCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */
iox8e5.h:    TC45_LCCAINTLVL_LO_gc = (0x01<<0),  /* Low Level */

E5s have a variant with "TC45" in the name though.

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

@david.prentice wrote:

I suspect that your earlier "working version" had inconsistent header files.

Or Atmel decided to drop the TC0/TC1 designation from the header files as there is no difference between them.

 

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

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

This is the trouble with tools which keep updating themselves as you go along - it makes configuration control an absolute nightmare!!

 

surprise

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Look what I found in the DFP repository:

 

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

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

<sigh>... if only there was a device pack system that allowed you to lock your project to an older version of the headers....</sigh>

:: Morten

 

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

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

Is there such a system? And don't the device pack being updated delete the old packs?

 

And for the doubting Thomases that may think it never compiled or I used some wrong names wink

 

	TCC0_INTCTRLB &= ~ (TC_TC0_CCAINTLVL_LO_gc);	// Interrupt off
    b708:	e7 e0       	ldi	r30, 0x07	; 7
    b70a:	f8 e0       	ldi	r31, 0x08	; 8
    b70c:	80 81       	ld	r24, Z
    b70e:	8e 7f       	andi	r24, 0xFE	; 254
    b710:	80 83       	st	Z, r24	
	
	TCC0_INTCTRLB |= (TC_TC0_CCAINTLVL_LO_gc);	// Timer interrupt on
    d5b2:	80 91 07 08 	lds	r24, 0x0807	; 0x800807 <__TEXT_REGION_LENGTH__+0x700807>
    d5b6:	81 60       	ori	r24, 0x01	; 1
    d5b8:	80 93 07 08 	sts	0x0807, r24	; 0x800807 <__TEXT_REGION_LENGTH__+0x700807>	
	
			TCC0_INTCTRLB |= TC_TC0_CCAINTLVL_LO_gc;	// Low level priority
    d9e8:	80 91 07 08 	lds	r24, 0x0807	; 0x800807 <__TEXT_REGION_LENGTH__+0x700807>
    d9ec:	81 60       	ori	r24, 0x01	; 1
    d9ee:	80 93 07 08 	sts	0x0807, r24	; 0x800807 <__TEXT_REGION_LENGTH__+0x700807>	
	
// Timer4 compare tick every 5ms from 32MHz
	TCC0_CTRLA = TC_TC1_CLKSEL_DIV64_gc;		// clk/64
    d9d6:	85 e0       	ldi	r24, 0x05	; 5
    d9d8:	80 93 00 08 	sts	0x0800, r24	; 0x800800 <__TEXT_REGION_LENGTH__+0x700800>	

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

No, old packs are not necessarily deleted. But if you open a project with a version that you don't have locally then studio should offer to download it for you...

:: Morten

 

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

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

I found where to change the device pack and post a screen shot for others.

 

 

however there are no older device packs but just the current one and the one that worked correctly (XMEGAD_DFP/1.1.52) is NOT on the list of available DPs.

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Only local ones. Download the one you need and it will become available in the project list.

:: Morten

 

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

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

Yes, but where do I download it from? It's not on the list of available DPs (XMEGAD_DFP/1.1.52), it jumps from 1.0.32 to 1.1.57 and then the current one.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Then download 1.0.32 and see if it works...

:: Morten

 

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

Last Edited: Sat. Aug 18, 2018 - 01:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Neither 1.0.32, 1.1.57 or 1.163 work. I may have the working version on my laptop, I think I still have the old AS7 on it.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Found XMEGAD_DFP/1.1.52 on my laptop and copied the whole folder across but it is not visible in the drop-down menu as the pack is not "installed".

 

HOWEVER!! By just having that folder with the others in the device pack folder fixes the problem even compiling with 1.163, I removed the folder from the device pack folder and it failed with all 3 installed device packs, put it back and all is well with all 3.

 

So Studio must just search the other packs for definition even though not selectable??

 

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Sat. Aug 18, 2018 - 10:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmm, no... To make it visible you need to reindex (it's in a menu in the Device Pack Manager). However the project should not look inside it before it's selected...

:: Morten

 

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

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

you need to reindex (it's in a menu in the Device Pack Manager)

Can't see it.

 

 

Anyway it works now regardless of what fixes it. smiley I'm updating my laptop to see if the old device packs get deleted. I have saved that device pack elsewhere in case I need it.

 

EDIT rebuilt using 1.1.63 but as you can see both 1.1.52 and 1.1.63 are being included even though 1.1.52 does not officially exist except that the folder has been copied into the DP folder.