Reading the Xmega32E5 Signature Row with an AVR ISP mkII ? <Solved>

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

I have an AVR ISP mkII connected to the PDI interface on an Atmel Xmega E5 Xplained board.  (Xmega32E5)

I am using Studio 6.2.1548 Service Pack 2

 

Power is via the USB interface.

I can read the uC's Device Signature, and I can program the uC just fine.

 

I can't seem to read the Production Signature Row.

 

It starts off reading the registers just fine, with the message box saying Reading register XYZ... OK

Then I get an error message:

 

Memory read failed at offset 0x35  (Flagged as a "warning")

 

Unfortunately, Studio then "cancels" reading the registers, and doesn't display the ones it read correctly.

It just quits the process.

 

I think I am reading the ADC Calibration 0 and 1 Registers in my software correctly, but I wanted to verify my results by reading them through the programmer.

No such luck.

 

Any thoughts would be appreciated!

 

Thanks,

 

JC

 

Edit:  I guess this could go under the Programmers sub-forum, but I think it might get more attention form Xmega users here.

 

This topic has a solution.
Last Edited: Sat. May 16, 2015 - 07:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Doc,

 

No solution for you sorry, but I also experience this problem. Hoped it might have been older silicon on my E5-Xplained board but a subsequent custom board (some 1-2 years later) didn't make any difference.  I was then hoping an upgrade to Studio 6.2 might do the trick. (I'm using 6.1.2730 SP2). Guess that's not going to happen either.

 

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

It is still good to know it isn't just my setup...

 

Thanks,

 

JC

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

Do you have any other programmers at your disposal?  I've had success using PDI with both an AVR JTAGICE mkII (Rev. 1) and an AVR JTAGICE 3 to communicate with XMEGA32E5's.

 

Note: AVR JTAGICE mkII Rev. 0 will not work with PDI. http://www.atmel.com/webdoc/jtagicemkii/jtagicemkii.introduction_hardware_revisions.html

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

Hi talllankybastard,

 

Thanks for the interest!

 

Atmel responded to my Tech Support question today, acknowledging that this is a Studio bug, and Studio, (at least with the AVR ISP mkII), can't read the Production Signature Row.

 

I don't have any JTAG devices, as I've always debugged with an LED and an LCD.

Actually, I take that back, I have a Dragon, but I was never impressed that my Version I Dragon could reliably connect to an Xmega.

 

I do have an STK600 collecting dust in the basement.

I may have to dig it out and give it a try, but this was suppose to be a weekend, quickie, project... (Best of plans).

 

At this point, this entire project, reading the E5's internal temperature, (in Basic), might get put on the back burner.

 

I did play around with Studio and found a E5 Xplained board read the internal temp project / example.

I figured out to get it loaded, clicked the right buttons to download it to the board, and I think, (maybe), it ran.

Reading the provided code, the temperature is provided as a variable, which one can read  (watch ?) with the debugger.

 

That assumes, of course, that one knows how to add a variable to the Studio IDE to watch it.

(Needless to say I'm not a Studio user...)

 

I guess it would have been too difficult to just show the result on the Xplained board's GLCD...

 

And it would have taken a lot to flash an on board LED when the project ran and the result was available.

 

I guess neither of those are necessary if one is actually stepping through the program using the debugger, but I've not gotten that far yet, and really didn't want to learn the IDE and debugger basics at the moment.

 

Add it would have taken a lot for Atmel to have a document, somewhere, that described, step by step, what it takes to read the internal temperature.

(A description of the ADC setup to read the value, which is WRONG in the Atmel ADC App Note which refers to the Xmega A series...)

And a description of which registers have to be preloaded to enable and set up the internal calibration system.

I'm still counting , but I think I've found four, plus another one that has to have an enable the internal calibration system bit set,

all in addition to the normal ADC register setup.

 

The info isn't in the Xmega32E5 data sheets, (either one of them, but don't get me started on that!), and it isn't in a separate App Note.

 

The E5 Internal Temperature is a pretty useless feature when its inner workings aren't documented...  (IMHO).

 

Take care,

 

JC

 

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

No,  I have not checked.

 

Reading the Temperature on most AVRs is nothing more than reading a 'special internal channel' with ADC.    An earlier message suggested that the ADC should use a 'slower' clock than for external channels.

 

Regular Mega and Tiny give some pretty unreliable values until you calibrate them.

The Xmega comes from the Factory with Calibration data.

 

So I can't see much problem in reading Temperature at runtime.

You can read the Calibration values at runtime.

You adjust the ADC reading with the Calibration values and hopefully get a reliable result.

 

If AS6 has a 'feature' in its Programming Dialog,   you would just read the values at runtime.   (until AS6 gets fixed)

 

I don't have an Xmega8E5.

 

David.

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

David, I guess I didn't describe my issue very clearly.

 

There isn't any short, concise, accurate, description of HOW to use the Xmega E5 series internal temperature "feature".

 

Why include it if there isn't any description of its inner workings?

 

For the E5 one has to decide whether to set up the ADC in signed or unsigned mode, and in single ended or differential mode, and if in differential mode, which of several possible grounds to use as a input for the negative input.

The ONLY published info on this is roughly one sentence or two, about the Xmega A series, and it is WRONG for the E5 series, and doesn't answer all of the other pertinent questions.

 

Then the calibration issue.

It says it is calibrated, (IIRC).

It doesn't say one has to turn ON the internal calibration system to be calibrated.

And its not just a matter of reading the Cal L and Cal H bytes and stuffing them into the ADC registers, one also has to load the Offset correction and Gain correction registers, as well.

 

And what, pray tell, is loading the offset correction actually doing?

How does this differ, if at all, from using a "spare" ADC input to read the Xmega's internal Ground, (OH, which one to use?), and measuring the Offset directly.

Is this just a production line process and aimed at also saving one from using an extra pin for this process, or does it do something else?

 

Same question about the gain correction register, and function.

If one loads the gain correction does it automatically correct for the ADC's internal gain?

Is this better or identical to reading the room temp and 85'C ADC readings that are suppose to be pre-stored in the Signature Row and calculating the gain oneself?

Does preloading the gain correction negate one needing to do that?

 

Gee, a simple explanation of the inner workings would go a long way here.

 

It is nice that the designers presumable know how the system works.

 

It is, (again, IMHO), a worthless feature without the supporting documentation to know how the system works, and lay out the framework for a customer / designer to use the "feature".

 

BTY, I'm venting at Atmel, not you!

 

Take care,

 

JC

 

Edit: typo

 

Last Edited: Mon. May 11, 2015 - 06:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

a simple explanation of the inner workings would go a long way here.

WHAT?? Then people would know how the chip works and they would copy it..... devil

 

I wish they would just go back to putting a line or 2 of code for each peripheral like in the old days, now they rely on the ASF which covers everything...so deep that normal people have no idea. angry

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Naturally my JTAGICE mkII is a Rev. 0  crying

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

How come all these issues end up on my desk...

 

Anywho, this is fixed for the next version of studio, and if you want a workaround, then open the device xml file (C:\Program Files (x86)\Atmel\Atmel Studio 6.2\devices\ATxmega32E5.xml probably), and find this block

<address-space name="prod_signatures" id="prod_signatures" start="0x0000" size="0x0035">
  <memory-segment start="0x0000" size="0x0034" type="other" rw="R" exec="0" name="PROD_SIGNATURES" pagesize="128"/>
</address-space>

Change it to

<address-space name="prod_signatures" id="prod_signatures" start="0x0000" size="0x0036">
  <memory-segment start="0x0000" size="0x0036" type="other" rw="R" exec="0" name="PROD_SIGNATURES" pagesize="128"/>
</address-space>

I.e address-space/@size from 0x0035 to 0x0036, and memory-segment/@size from 0x0034 to 0x0036.

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

this is fixed for the next version of studio,

Which will be available when? I'm running out of things to complain about......

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

laugh HAHAHAHAHA!

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

Well the work around works nicely.

Ta Muchly.
 

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

Gee, is there a button to mark a Topic "Pseudo-Solved"?

 

Actually, Thank you to Morten for taking a look at this and posting a fix pending the new Studio version's release.

My version 6.2... of Studio will now read the Production Signature Row for the Xmega32E5. laugh

 

Unfortunately, the ADCACal0 and ADCACal1 bytes are both 0x00  angry

 

Hard to imagine that that is actually the case...

 

Some days I think I should just trade in my O'scope for a set of golf clubs and take up a new hobby...

 

I wonder what has a steeper learning curve, gold of "C"?

 

JC

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

Alright, it was unfair to slam Atmel for having ADC A Cal Low = 0 and Cal High = 0 in the Production Signature Row.

Sorry, Atmel.

 

The actual ADC raw reading offset for a Grounded input is 0 on this particular chip. (Not a big sample size)

 

And even better news, scratch reading the XmegaE5's Internal Temperature off the project list.

It now works.

 

When the chip is "cold", and hasn't been turned on for a few hours, the temperature reads about 4 'F above ambient.

When the chip has been on for hours it reads about 8 'F above ambient.

I'd guess those are reasonable numbers.

 

JC