signature-row reading issue

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

I seem to be having a problem with the factory signature-row memory locations here, or the data sheet is wrong.

Can you try looping through your Production Signature Row and see what values you get? Especially the address offsets for the ADCxCALn values.

I seem to have an off-by-one issue!?

Here's what I get:

    0x1e = 0xff
    0x1f = 0xff
    0x20 = 0xff <--- ADCACAL0 ??
    0x21 = 0x0 <--- ADCACAL1
    0x22 = 0x9
    0x23 = 0xff
    0x24 = 0xff <--- ADCBCAL0 ??
    0x25 = 0x0 <--- ADCBCAL1
    0x26 = 0x1
    0x27 = 0xff
    0x28 = 0xff

And this occurs on all three of my Xmega-Xplained boards.

Last Edited: Tue. Jan 15, 2013 - 02:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Here's what I get:
Does it show the same values when you read the signature values with the programmer?

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:
Does it show the same values when you read the signature values with the programmer?

I'm using avrdude and from what I've seen, it doesn't support reading them from there.

dump prodsig 0 50
avrdude: stk600_xprog_read_byte(): unknown memory "prodsig"
error reading prodsig address 0x00000 of part ATXMEGA128A1
read operation not supported on memory type "prodsig"

Though it works with usersig, signature, flash, fuseN etc.

I had put this in with the ADC code since I was wondering if others had been having problems with their calibrations because of this same issue.

Notice that I am using the basic ReadCalibrationByte(ADC-offset) routine. I just looped it to try to see WTF was going on since I kept getting 255 and 0 for values.

This seems to indicate why...

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

If you post your code snippet I can plug it into my current test program and try it out.

You may have noticed I split the thread for you, I'm not being snobbish, it may have some values for others as a separate thread. :)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Not much to it...

just loop from 30 to 40 with a printf of ReadCalibrationByte(i);

This !@$%#$^ editor won't let me post real code!!!! WHAT GIVES?

Last Edited: Tue. Jan 15, 2013 - 02:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You must have % signs, just use a space after that.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
inline uint8_t read_calibration_byte( uint8_t index )
{
    uint8_t result;

    /* Load the NVM Command register to read the calibration row. */
    NVM_CMD = NVM_CMD_READ_CALIB_ROW_gc;

    result = pgm_read_byte(index);

    /* Clean up NVM Command register. */
    NVM_CMD = NVM_CMD_NO_OPERATION_gc;

    return( result );
}

for (int i= 30; i <= 40; i++)
    printf("0x% x = 0x% x\r\n",i, read_calibration_byte( i ));

OK, spaces after '%' I gotta remember that...

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

Don't know how you read you bytes :-) this is what I get with the Xmega256A3BU and your code

0x1e = 0xff
0x1f = 0xff
0x20 = 0x0
0x21 = 0x0
0x22 = 0x0
0x23 = 0xff
0x24 = 0x0
0x25 = 0x0
0x26 = 0x0
0x27 = 0xff
0x28 = 0xff

Are you sure you have the correct chip selected?

edit haha but that's different from what the JTAG reads so there must be some timing issue or something.

2nd edit I have run the code 3 times with the same results. :roll:

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 tried reading, (viewing), the Sig Row fuses using my AVRISP mkII and Studio 6, on an Xmega32A4, (Has the new USB module).

I have 00's for my ADC Calibration Bytes.
I do have what appears to be real data for several other fields.

Two images, as one can't see the entire list in one image alone.

I figured I'd read them with true Atmel hardware, as this removes my programming (in)abilities from the test ;)

JC

Attachment(s): 

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

Well I have four Xmega128a1's and the above code shows these:

    0x1e = 0xff | 0x1e = 0xff | 0x1e = 0xff | 0x1e = 0xff
    0x1f = 0xff | 0x1f = 0xff | 0x1f = 0xff | 0x1f = 0xff
    0x20 = 0xff | 0x20 = 0xff | 0x20 = 0xff | 0x20 = 0xff
    0x21 = 0x0 | 0x21 = 0x0 | 0x21 = 0x0 | 0x21 = 0x0
    0x22 = 0xfc | 0x22 = 0x5 | 0x22 = 0xfa | 0x22 = 0x9
    0x23 = 0xff | 0x23 = 0xff | 0x23 = 0xff | 0x23 = 0xff
    0x24 = 0xff | 0x24 = 0xff | 0x24 = 0xff | 0x24 = 0xff
    0x25 = 0x0 | 0x25 = 0x0 | 0x25 = 0x0 | 0x25 = 0x0
    0x26 = 0x1 | 0x26 = 0xf0 | 0x26 = 0xfe | 0x26 = 0x1
    0x27 = 0xff | 0x27 = 0xff | 0x27 = 0xff | 0x27 = 0xff
    0x28 = 0xff | 0x28 = 0xff | 0x28 = 0xff | 0x28 = 0xff
:cry:

I went so far as to read ALL the values from 0x00 up to 0x38 and matched them up to the data sheet. Most of the reserverd spots read as 0xff.

offs. val - offset & name from data-sheet
0x0 = 0xc - 0x00 RCOSC2M
0x1 = 0xff - 0x01 Reserved
0x2 = 0x45 - 0x02 RCOSC32K
0x3 = 0x8 - 0x03 RCOSC32M
0x4 = 0x5b - 0x04 Reserved
0x5 = 0xff - 0x05 Reserved
0x6 = 0xff - 0x06 Reserved
0x7 = 0xff - 0x07 Reserved
0x8 = 0x30 - 0x08 LOTNUM0
0x9 = 0x4a - 0x09 LOTNUM1
0xa = 0x37 - 0x0A LOTNUM2
0xb = 0x34 - 0x0B LOTNUM3
0xc = 0x31 - 0x0C LOTNUM4
0xd = 0x30 - 0x0D LOTNUM5
0xe = 0xff - 0x0E Reserved
0xf = 0xff - 0x0F Reserved
0x10 = 0x19 - 0x10 WAFNUM
0x11 = 0xff - 0x11 Reserved
0x12 = 0x14 - 0x12 COORDX0
0x13 = 0x0 - 0x13 COORDX1
0x14 = 0x4 - 0x14 COORDY0
0x15 = 0x0 - 0x15 COORDY1
0x16 = 0xff - 0x16 Reserved
0x17 = 0xff - 0x17 Reserved
0x18 = 0xff - 0x18 Reserved
0x19 = 0xff - 0x19 Reserved
0x1a = 0xff - 0x1A Reserved
0x1b = 0xff - 0x1B Reserved
0x1c = 0xff - 0x1C Reserved
0x1d = 0xff - 0x1D Reserved
0x1e = 0xff - 0x1E Reserved
0x1f = 0xff - 0x1F Reserved
0x20 = 0xff - 0x20 ADCACAL0
0x21 = 0x0 - 0x21 ADCACAL1
0x22 = 0x5 - 0x22 Reserved
0x23 = 0xff - 0x23 Reserved
0x24 = 0xff - 0x24 ADCBCAL0
0x25 = 0x0 - 0x25 ADCBCAL1
0x26 = 0xf0 - 0x26 Reserved
0x27 = 0xff - 0x27 Reserved
0x28 = 0xff - 0x28 Reserved
0x29 = 0xff - 0x29 Reserved
0x2a = 0xff - 0x2A Reserved
0x2b = 0xff - 0x2B Reserved
0x2c = 0xff - 0x2C Reserved
0x2d = 0xff - 0x2D Reserved
0x2e = 0xff - 0x2E TEMPSENSE0
0x2f = 0xa - 0x2F TEMPSENSE1
0x30 = 0x49 - 0x30 DACAOFFCAL
0x31 = 0x5 - 0x31 DACAGAINCAL
0x32 = 0xa - 0x32 DACBOFFCAL
0x33 = 0x12 - 0x33 DACBGAINCAL
0x34 = 0xff - 0x34 Reserved
0x35 = 0xff - 0x35 Reserved
0x36 = 0xff - 0x36 Reserved
0x37 = 0xff - 0x37 Reserved
0x38 = 0xff - 0x38 Reserved

Maybe 0xff is a valid calibration value, but something just doesn't seem right with those ADCxCAL and TEMPSENSE values.

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

I just noticed the following quote in comment 7 with regard to the broken Xmega128A1 ADC at http://blog.frankvh.com/2010/01/03/atmel-xmega-adc-problems-solutions/ where others have noticed this same behavior, so this seems to be common among the 128A1 chips.

Quote:
I notice with interest your comments that the Calibration bytes have no appreciable effect on your results. I notice that all of the XMEGA xhips I have tested so far have these calibration bytes set as ADCACAL0=ADCBCAL0=0xff and ADCACAL1=ADCBCAL1=0×00

Since the new -U versions have improved the ADC (many of the errata have been erased--but not all) maybe this is something they fixed too.

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

The ATxmega256A3BU still has both calibration bytes as 0.

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 128A3U and the calibration values look valid. My guess would be that some parts are close enough to ideal to not need any calibration so it is disabled in hardware, while others are not.

Might as well just load the calibration data, at least that way if they change something in the future your code will continue to work. Having the option to use calibration probably increases yields significantly by allowing parts that would have failed the ADC test to pass.

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

Just as a final follow-up to this issue, I contacted Atmel about it and they looked into it all the way down to the production line.

The response was:

Quote:
As I get confirmation from our calibration & characterization team, calibration values 0x00 0xff ( CAL1, CAL0) are correct in ATXMega128A1 devices. You can use this value and hence you can get better ADC results.

As others have tried, I loaded various values into the cal registers and didn't get anything more than +/- 1-bit of difference.