Confused: PDI Access of Signature Row

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

Confused: PDI Access of Signature Row

I am looking for a little guidance, (not code), as I think I am off track.

I am using a M168 to PDI program an Xmega64A1.
(Not there yet, but that is the goal.)
I am doing this for my own academic interest, to see if I can do it. I am aware of Atmel's programmers and Dean's LUFA as PDI options. My goal is to see if I can do it.

My current references are the Xmega A Manual, the Xmega64 Data Sheet, and Application Note AVR1612: PDI programming driver. (Should be easy with all of that :) )

The system runs at 3 V, the Mega and Xmega pins are tied directly together, there are no pull up resistors or caps on the reset line. Both uCs can be programmed and run programs just fine. Next version will have a series resistor in the Data line for bus contention protection, but that hasn't been a problem thus far.

I can "Enable" the PDI Hardware interface in the Xmega.
I can "Enter External Programming Mode", which accesses the NVM Controller.
(Send Reset Signature, Key Command, the 8-byte Xmega Key, and poll the NVMen Bit)
I successfully get to this step. :)

My next step, and current hurdle, is simply to read the Device ID, (Signature).
The Signature for the Xmega64A1 should be: 1E 96 4E where 1E is consitent for all Atmel uC's.

I believe that the PDI interface should make the entire memory structure of the Xmega accessible as a single array, 0x0000000 to 0x1FFFFFF, as shown on Figure 30-4. Memory Map for PDI accessing the data and program memories, (A Manual).

I think I ought to be able to use the PDI commands to send a read memory command to read the Device ID (Signature) Bytes.

My thought was that the SROW, Product Signature Row has a base address of: 0x008E0200 (From the Memory Map diagram sited above).
The MCU Control Register, which contains the Device ID Registers, has a base address of: 0x0090.
The MCU Device ID Register 0 has an address offset of 00.

So I thought reading, via the PDI interface, memory address: 00 8E 02 90 would provide me with the Device ID (Signature) byte value: 1E.

To read this memory I used the PDI LDS Command, configured as:
LDS, Address Size: Long (4 bytes), Data Size: One Byte: 0000 1100

Send 0x0C
Followed by:
00
8E
02
90

Then I read a byte back, obtaining 0, not 1E

I was successful in using the PDI LDCS and STCS commands to enter the PDI programming mode, but this was my first use of the LDS Command, and of attempting to read from the PDI memory mapped Xmega.

Clearly I am not doing it correctly, and I would be thankful for any guidance in the right direction. I am certainly not a programmer, and at times like this it shows...

JC

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

Hint 1: The Device ID is not within the product signature row, it is in the MCU control register in datamem, which starts at 0x01000000 plus offset 0x90. Yes, the datasheet is misleading.

Hint 2: Little-endian

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

I appreciate the guidance!

I had difficultly determining where the registers are located, obviously...

Little-Endian... Kind of like the Xmega Key ???
Gotta love it.
The A Manual says:

Quote:

The key that must be sent using the KEY instruction is 64 bits long. The key that will enable NVM Programming is:

0x1289AB45CDD888FF

But you have to send the Key in reverse order... That, it doesn't say...

I appreciate the help!

JC

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

Got it!
Nice when it works!
Thank you, again.

JC

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

Don't foregt to look into the REPEAT instruction when doing multiple sequential reads or writes, to lower the overhead of the protocol (also, turn down the guard bits if your setup allows it). You can see an example of how to do that in my LUFA AVRISP-MKII clone code.

- Dean :twisted:

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

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

Hi Dean,
Thanks for the suggestions. I do understand the concept behind them. Tweaking the Guard Time looks easy. I haven't worked with the REPEAT Instruction yet.

I am still workng on getting individual components of my software to work. It is slowly growing one subroutine at a time. I've not yet actually Flashed the Xmega. (But I'm getting Closer! :) )

I can now enter PDI programming mode, Read the Device ID, (Signature), Read the Application Section, and do a total chip Erase. Sounds easy, but I had a few hurdles along the way. Once you understand the methodology it becomes trivial... Getting to the point of understanding is the challenging part.

A step backwards tonight when I realized the order in which I called some routines made the Chip Erase fail... Not sure why, yet. I have a work around, but I want to know why it failed...

I am still trying to conceptually get the burn (program the flash memory) concept sorted out in my head. I haven't found a simple pseudo-code example of the entire process to work from.

It isn't yet clear if I can just set the NVM Controller Instruction to "Flash Page Write", and then Load data with the PDI commands into the PDI Memory Map of the chip, or if I have to load data into the Flash Page Buffer and burn it page at a time... Clearly more learning to do.

JC

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

You guys are all crazy. How do you find the time for all this fun stuff?

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

HI Gordon,

Just reprogram the clock for 25 hours in the day, of course!

JC