XMEGA E

Go To Last Post
143 posts / 0 new

Pages

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

Quote:
was the webinar worth watching?
I was up at 1am :cry: but could not log on until after the webminar was finished and posted.

It is only about 30 minutes long and availbale on demand now from the training page of the Atmel site.

One of the thing I had missed was the fact that the bootloader flash is ADDITIONAL to the user flash, so the 8E5 has in fact a 10K flash device while the 16E5 is 20K and the 32E5 is 36K.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I wrote above

Quote:
DHL delivered a couple of the new Rev B Xmega32E5
But the chip still shows up as rev A in the progammer and the "undocumented features" present in the older chips are still there in the new chip :roll: (different markings on the chip) I tink I have been flimflammed..... :lol:

I'll email Atmel with details for an explanations.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

And for the unbelievers that the chip really exist. :-) (the rest of the board is top secret :wink: )

Attachment(s): 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:

And for the unbelievers that the chip really exist

Hmmm--to this old bit-pusher, it could be an ATtiny48... :twisted:

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

But it isn't, it's a Xmega32E5. :wink:

Not the greatest photographer in the world I know. Not very happy with the quality of the silk screen on the board either, the 2nd time they have messed things up.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Very Nice!

Hand assembled or machine assembled?

The parts look pretty small and pretty precisely oriented to be done by hand, but maybe you are just that good at it!

JC

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

Hand assembled....with one semibad eye. (floaters)

Quote:
but maybe you are just that good at it!
What can I say. :lol:

Too early for machine assembly, may still need to do some small mods to the board once I get some prospective clients feedback.

How is your "problem" coming along? Got flashing LEDs yet?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
..But the chip still shows up as rev A in the progammer and the "undocumented features" present in the older chips are still there in the new chip ....

What do the marking underneath say ?
Should have a Die ID and a Die revision letter ?

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

Quote:
How is your "problem" coming along? Got flashing LEDs yet?

Short answer: "No".

I can do lots, but not yet Interrupt driven.

I think my Dragon is flaky. I tried to learn about debugging in Studio 6 and sometimes I can read the Xmega's Signature, sometimes I can't. Once or twice I thought I was debugging, but things locked up... My AVR ISP mkII always connects flawlessly, but it isn't a debugger, and I don't have a JTAG device.

I think I have the Vector Table correct, in the def.dat file, but I don't think the (Bascom) compiler is routing the interrupts to the correct vector address. I'm sure this is my mistake, I just haven't tracked it down, yet. To be fair, Bascom doesn't officially support the E series yet.

Blinking in the Main Loop, running the LCD, and as of this evening running the 7-Segment display all work. I had to simulate Interrupts in the Main Loop to trigger the 7-Segment LED Driver, however.

This test project was going to be a GPS clock to drive the 7-Segment display, but its tough to do an Interrupt Driven Ring Buffered USART when you are having Interrupt difficulties. I haven't used a 7-Seg LED display in many years, but thought it would be a good test of the new chip to write a driver for it.

The 7-Seg is so bright the LCD display doesn't show up well in the photo, but they both look good on the real hardware.

I'll tell you, however, some days I really think I ought to trade in my O'scope for some golf clubs!

JC

Attachment(s): 

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

Quote:
I think I have the Vector Table correct, in the def.dat file
Unless you have changed it from the one you sent me before it is not correct.

You still had the TCC0 vectors in there and the new vectors for TTC4 and TCC5 were all the way on top of the table away from where they should be.

The Dragon seems to work well with the E5, I'm switching between it and the JTAG Mk3 when I think something is fishy...but it is still fishy with the Mk3 :-) let's wait until AS6.1 full gets released before complaining too much. Shouldn't be too far away.

Quote:
What do the marking underneath say ?
T47 Philippines.

The top markings:

The new chip has the following markings:
Xmega32E5-UES
1312B PH
A3U1146-1

The older chip and the chip on the Xplain board have the following markings:
Xmega32E5-U
1240A PH
2X1036-3

The programmer still shows them both as Revision A. I have emailed Atmel about this.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I solder TQFP parts from time to time, including the XMEGAs. The 0.8mm pitch ones are fine, 0.5mm could be tricky.

I was working on a break-out board for the 64 pin parts but might switch to the 32 pin ones now. As well as the usual caps and an inductor for AVCC I think an LM4040 2.048V reference would be handy. Maybe squeeze a micro USB socket on as well.

One nice thing about adapter boards is that if you solder the pins in "upside down" so they poke up it is easy to get probes on to them.

Maybe someone (me? nah) should do a little Kickstarter project or something to do a run of DIP converter PCBs with the smaller MLF package parts professionally soldered on.

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

Quote:

The new chip has the following markings:
Xmega32E5-UES
1312B PH
A3U1146-1

The older chip and the chip on the Xplain board have the following markings:
Xmega32E5-U
1240A PH
2X1036-3


Back when I was your age :twisted: the letter at the end of the second line on an AVR indicated the die revision. But there has been a lot since then, including the fab outsourcing.

From a traditional point of view, it looks like date codes of Week 40, 2012 and Week 12, 2013 so the "new" chip appears ... newer.

The new chip has an ES -- I'd guess Engineering Sample.

The letter after the date code -- A, B -- could be the die rev? It would seem to correspond to the Errata section of the datasheet.

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:
the second line on an AVR indicated the die revision
OK but the programmer tells me Revision A, maybe I don't understand what the programmer is saying. :-)

Attachment(s): 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

If the original silicon was not publicly sampled and was revised, the public silicon will probably have a revision A monkier as well. Your top-markings seem to indicate it's physically revision B silicon.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Since XMEGA chips have a separate revision byte in the signature row I doubt that the programmer would be reading it wrong, so chances are Atmel forgot to increment it in this revision :-)

The rev. C change list will be:

- Fixed incorrect chip revision byte

Speaking of which, I wonder if they fixed the bug with reading back the signature row values with EEPROM power saving enabled.

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

Quote:

Since XMEGA chips have a separate revision byte in the signature row I doubt that the programmer would be reading it wrong, so chances are Atmel forgot to increment it in this revision

There's a difference when the device hasn't been released; if it's an internal-only version the silicon revision might not be incremented when the device goes public, so that the first shipped silicon is revision A to prevent customer confusion (not very well in this case, since some non-final silicon got into John's hands :P).

- Dean

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Apparently there will be an updated Studio "part pack" for rev B released shortly, so we wait until then. :-)

Everything is working pretty well though even if I have to do a bit of contortionism with the timers (as Dean may remember among millions of other things he needs to remember) possibly due to incorrect Studio files or me not understanding how the "new" timers are supposed to work.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Perhaps someone can enlighten me as to how the new EDMA data match feature works.

The XMEGA E manual states that it will end the EDMA transfer when data matches. The data to be matched is placed in the memory address register, which suggests that the memory address register is not being used to actually store the data in SRAM. Is that a fair assumption?

I was thinking about using this feature for receiving data from a GPS module. It sends sentences over a USART that start with a $ sign and end with a newline (\n) character. Ideally the EDMA controller could trigger when the $ character arrives and automatically end the transaction when the newline arrives and generate an interrupt. Is that sort of thing possible?

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

The above E5 breakout board built. https://www.avrfreaks.net/index.p...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I think you accidentally a word :-)

Looks good though. How does it work?

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

Ha, looks like I accidentally a word too :-)

I should have asked "how well does it work?"

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

Haven't tried it yet, I have been busy dismantling my test jig and figure out what I did 20 years ago! :roll:

I put the test jig diagram in a safe spot so I wouldn't lose it..I know I did....

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Well it works, just hacked some code from another project to generate a sine wave and it's sineing.

At least I know that 1 pin is working along with the PDI pins. :-)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I really can't wait to have a play with one now. Unfortunately it usually takes the UK a loooong time to get any stock.

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

How are the ADC's performing?

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

The ADC seems to work well. I haven't yet carried out a very strict test (or calibration) but I'm happy enough with it's performance for my application to lead me to remove the external 12 bit ADC I fitted as back up in the first prototype.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Have you tried the oversampling functionality? I'm very interested in that and what the noise is.

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

I believe the Rev. A E series has two Errata, (silicon bugs), regarding the ADC averaging feature.

Of interest, neither is still listed in the Rev. B chip's Errata list.

It should, therefore, work as per the data sheets.

JC

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

But js told us he had "rev A"...

Quote:

I wrote above
Quote:
DHL delivered a couple of the new Rev B Xmega32E5
But the chip still shows up as rev A in the progammer and the "undocumented features" present in the older chips are still there in the new chip Rolling Eyes (different markings on the chip) I tink I have been flimflammed..... Laughing

I'll email Atmel with details for an explanations.

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

The code I had before (non E5) does multipe ADC reads and average them so I haven't tried the oversampling (too busy with other things).

There also seems to be some automatic interrupt which can be set when the ADC value reaches some point which could simplify things but again I'm playing safe for now and use what I know has worked before.

Once I get on top of things and have more time I'll be more adventurous, by then more people should have some chips in their hands so that we can bounce things off each other.

I'm still at a loss believeing that only 2 people in this forum have the E5.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Well I got my own Xplained board on Friday for it, so you're not totally alone now...

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Well start working on the timer flags issue (or most likely misunderstanding on my part). :wink:

https://www.avrfreaks.net/index.p...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I'm not familiar with ADC's of XMEGA and certainly not of the E version. I've some questions:
* what would be the sample rate in 16 bit mode (1024 times oversampling) on 4 differential + 2 single ended channels (scanning those 6 inputs).
* can this scanning be done by DMA?

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

jan_dc wrote:
* what would be the sample rate in 16 bit mode (1024 times oversampling)

ADC in XMEGA is 12-bit. 1024 times oversampling gives additional 5 bits, as of 1024=2**10 and it gives the squre root of that. So with 1024 times oversampling it would be 17-bit mode.
But it will have large nonlinearity, which is not so depend from oversampling, and the precision will be not much better than in 12 bit mode.

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

maksim wrote:
jan_dc wrote:
* what would be the sample rate in 16 bit mode (1024 times oversampling)

ADC in XMEGA is 12-bit. 1024 times oversampling gives additional 5 bits, as of 1024=2**10 and it gives the squre root of that. So with 1024 times oversampling it would be 17-bit mode.
But it will have large nonlinearity, which is not so depend from oversampling, and the precision will be not much better than in 12 bit mode.

oops, I ment 256 times. The 1024 is from the averaging specification. I need about 10 measurements per channel per second at 1.8MHz clock frequency. According to the specifications it should be feasable but I have no idea of the stability of the ADC when it's continuously switching/scanning.

Yes, you're right about the non linearity. I forgot that one.

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

Good afternoon everybody.
I was asked to develop a new project with this uC. I was searching for the first info and I see there's no support for it in avr-gcc. just avr studio have it. and I don't use windows... :P
Do you know how long I should wait for have it supported by avr-gcc on linux?

I can start developing in a virtual machine. no problem with it. But I want to leave it as soon as possible.
thank you for any info you can do.
A

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

It's supposed to work with the latest Atmel toolchain. There is a stand alone version for Windows and one for Linux.

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

Oh! great. So there's an Atmel toolchain on the website? I always used avr-gcc shipped with the distribution. Need to find it :)
Thank you for your reply
Andrea

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

Quote:

So there's an Atmel toolchain on the website?

See this thread:

https://www.avrfreaks.net/index.p...

To avoid Atmel's registration rubbish use the links in the post from SprinterSB.

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

Thank you clawson,
I installed it. Need to wait for my new demo uc and socket for stk600 for testing it. :)

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

looks like my samples will be here at the end of august... I asked for them on june 15th... 75 days for 3 samples is not too much?

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

If I try to get production signatures (Xmega16/32 E5 Rev. B) using AvrIsp mkll error message appears "memory read fails at offset 0x35". Other successfully read Registers contain 0. Any ideas why?

Pages