ATXMEGA32E5 atprogram tries to program user signature

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

Hi Freaks,  I am setting up production tools to program devices with ATXMEGA32E5 embedded.  I am using "atprogram" CLI from AS7 to program the units.  My problem is that the atprogram is apparently trying to program a user signature when my .elf file doesn't specify one.  I am not using the user signature (at least intentionally).  I am new to using the atprogram CLI but I don't see any flags in the help file to suppress writing a signature in the user signature block.  Below is the command line that I have been using.  Any of you experienced folks see something I should change to eliminate the error?  The devices program fine with the flash, eeprom, and lockbits that I have in the ELF file, but I still get this error that I would like to eliminate.  No user signature file was specified when I created the production ELF file.

 

C:\MRC Python GUI>"c:\Program Files (x86)\Atmel\Studio\7.0\atbackend\atprogram" -t atmelice -i pdi -d atxmega32e5 chiperase program -f C:\WLXS\Releases\VCU\VCU_V1.0.52\VCU_V1.0.52.elf verify -f C:\WLXS\Releases\VCU\VCU_V1.0.52\VCU_V1.0.52.elf
Firmware check OK
Chiperase completed successfully
[ERROR] Failed to write segment at 0x0 to target for memorytype signatures. (TCF Error code: 131103)
C:\MRC Python GUI>

This topic has a solution.
Last Edited: Tue. May 17, 2016 - 09:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know.  I use avrdude.  I don't think you can assume it has to do with the user signature.  Here's another post that had this problem.

 

https://www.avrfreaks.net/forum/device-programming-issues

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

Steve,  Thanks for the reply.  The reason I think is has to do with the user signature is because the user signature is the only signature that is writable.  The error message states that it encounters the error writing to memorytype signatures.  "[ERROR] Failed to write segment at 0x0 to target for memorytype signatures. (TCF Error code: 131103)" or I maybe misinterpreting that?  I guess I'm not sure what "memorytype signatures" are.  I had looked at the other posting you referenced and it is a different issue.  Thanks for taking time to reply.

 

Chapster911

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

Can you or have you tried using Studio? I use ATXMEGA32E5 and I don't have THAT problem, lots of others however. sad

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:

Can you or have you tried using Studio? I use ATXMEGA32E5 and I don't have THAT problem, lots of others however. sad

 

John,

  Thanks for responding.  Yes, in fact all of the development for this project has been done using AS6.1 and AS7 and CVAVR.  Programming through Studio works fine.  It's only the command line "atprogram" where I have the issue.  I am trying to use the command line version so I can call it from a Python script on a production line test and programming station.  The error itself doesn't affect the operation of the units that are programmed.  The problem for me is that the command line program returns an error status to the OS after running and if I ignore that error then I can't detect other errors that may be genuine errors.  Make sense?  It seems to me that AS uses the command line program under the hood?? so I'm wondering if I need another flag in my use of "atprogram"? or is there a way to see what command AS passes to the CLI program?

 

Thanks again.

Chapster911 (Marty)

 

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

AS7 is still broken for me. Got some boards from the assembly house (using XM32E5) and, just for "fun", tried to use Studio to program them.

 

Spent some time trying to get the JTAG Mk3 to do anything and then I remembered: AS7 defaults to 4MHz but PDI doesn't work (for me at least) unless I go down to 1MHz.

Then there is the problem that if I try to reprogram the chip AS crashes and restarts. Supposedly there is a fix in the new version of studio but I'm not waiting with "a bad breath" for it. smiley

 

Got a US$50 "keyfob" programmer from one of the residents here AlanK2 a couple of weeks ago that you just load up the code, lockbits and fuses, plug the programmer in, turn on the power and the board is programmed and it just works! Now Alan will be bashful but it's a great programmer for a production environment.

https://www.avrfreaks.net/forum/w...

 

I will have to build a little enclosure so that I don't blow it up but otherwise excellent.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Fri. May 13, 2016 - 10:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John, 

    Again - thanks for follow up.  That keyfob programmer is a great idea.  Had I known about it about 3 weeks ago I probably would have purchased three right off the bat.  At this point I have the "pogo-pin" (bed of nails) test fixtures built and have already equipped them with the AtmelICE programmers.  What AlanK2 has there makes me want to put a programming port right on the back panel of new products to allow easy updating!  Cool to think about in the future.  Sorry to hear of your troubles with the XMEGA32E5 and AS7.  It seems really odd, but I have had nothing but success and consistency with AS7 and the XMEGA's!  The differences may be in the fact that I am using the AtmelICE programmer and also am using the CVAVR compiler.  I leave the interface for the AtmelICE at 4Mhz for the PDI with no issues and haven't had to try any other settings.  I'm real impressed with both of those and the AS7 has been such a huge step up in speed and reliability for me from AS6.2.  My client is having the units I designed, built in China and I don't want to have their assemblers or techs messing around with AS7 (AS-anything) just to program the units.  That's where I started to pursue the CLI to "atprogram" and call it from my test software.  It is a bit of a chore to install "atprogram" separate from AS, but to make the user interface for the test stations simple I think it's the way to go.  If I am not able to resolve the error of it thinking it needs to write to the user signature area, I may give AlanK2's product a try.  It wouldn't be too big of a deal to update the fixtures.

 

Regards,

Marty

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

AS7 defaults to 4MHz but PDI doesn't work (for me at least) unless I go down to 1MHz.

And just an update for future readers on this: It seems that the problem is only present in an earlier production JTAG Mk3.

 

Updating to the latest AS7 4MHz PDI  works on a newer JTAG Mk3 and with the Atmel ICE.

 

See also https://www.avrfreaks.net/comment...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Your mkII no worky?

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

If you are referring to the JTAG Mk2 then yes, it worky, but with AS4.18. Not letting it near AS7.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Chapster911 wrote:

C:\MRC Python GUI>"c:\Program Files (x86)\Atmel\Studio\7.0\atbackend\atprogram" -t atmelice -i pdi -d atxmega32e5 chiperase program -f C:\WLXS\Releases\VCU\VCU_V1.0.52\VCU_V1.0.52.elf verify -f C:\WLXS\Releases\VCU\VCU_V1.0.52\VCU_V1.0.52.elf

 

Try running that same command manually from the Console Window (command prmpt).

 

Then try adding the -v (lower case v) for verbose output to see what additional info it provides.

 

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

Chuck99 wrote:

Chapster911 wrote:

 

C:\MRC Python GUI>"c:\Program Files (x86)\Atmel\Studio\7.0\atbackend\atprogram" -t atmelice -i pdi -d atxmega32e5 chiperase program -f C:\WLXS\Releases\VCU\VCU_V1.0.52\VCU_V1.0.52.elf verify -f C:\WLXS\Releases\VCU\VCU_V1.0.52\VCU_V1.0.52.elf

 

Try running that same command manually from the Console Window (command prmpt).

 

Then try adding the -v (lower case v) for verbose output to see what additional info it provides.

 

 

Here tis...  Nothing revealing....

C:\WLXS>"c:\Program Files (x86)\Atmel\Studio\7.0\atbackend\atprogram" -v -t atmelice -i pdi -d atxmega32e5 chiperase pro
gram -f C:\WLXS\Releases\CCU\CCU_V1.0.44\CCU_V1.0.44.elf verify -f C:\WLXS\Releases\CCU\CCU_V1.0.44\CCU_V1.0.44.elf
[DEBUG] Starting execution of "chiperase"
[DEBUG] Starting process 'c:\Program Files (x86)\Atmel\Studio\7.0\atbackend\atbackend.exe'
[DEBUG] Connecting to TCP:(removed :)
[INFO] Connected to atmelice, fw version: 1.1c
Firmware check OK
[INFO] Firmware check OK
Chiperase completed successfully
[DEBUG] Command "chiperase" finished with return code 0
[DEBUG] Starting execution of "program"
[DEBUG] Memory segment prog written at 0x00000000. Size = 0x00007f02.
[DEBUG] Memory segment eeprom written at 0x00000000. Size = 0x00000398.
[DEBUG] Memory segment lockbits written at 0x00000000. Size = 0x00000001.
[ERROR] Failed to write segment at 0x0 to target for memorytype signatures. (TCF Error code: 131103)

Thanks for the suggestions guys - keep em coming :)

 

Marty

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

Well I finally figured out a solution.  If I specify each of the memory segments in the command line and create a user signature file ( I re-created the ELF file &  included the new user signature file, even though it is all 0xFF's) it completes with success.

 

C:\WLXS>"c:\Program Files (x86)\Atmel\Studio\7.0\atbackend\atprogram" -t atmelice -i pdi -d atxmega32e5 chiperase program -fl -ee -lb -up -us -fs -f C:\WLXS\Releases\CCU\CCU_V1.0.44\CCU_V1.0.44.elf verify -f C:\WLXS\Releases\CCU\CCU_V1.0.44\CCU_V1.0.44.elf

Firmware check OK
Chiperase completed successfully
Programming completed successfully.
Verification OK

 

C:\WLXS>

 

Thank you to all who took time to read and make suggestions.  This forum is a great resource!

 

Last Edited: Tue. May 17, 2016 - 09:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:

Got a US$50 "keyfob" programmer from one of the residents here AlanK2 a couple of weeks ago that you just load up the code, lockbits and fuses, plug the programmer in, turn on the power and the board is programmed and it just works! Now Alan will be bashful but it's a great programmer for a production environment.

https://www.avrfreaks.net/forum/w...

I will have to build a little enclosure so that I don't blow it up but otherwise excellent.

 

I'm glad it is working for you John!!  I've thought about making an enclosure version, but I just never have the time!