atprogram AS6.2 v AS7?

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

A system that the company I currently work for buys in from a third party company, supplied us some time ago with a .cmd file for programming their hardware with their bootloader and setting relevant fuses. It was written originally for AS6.2, however I'd like to use it with AS7 and not have to go back to an older version, but it seems to be giving me issues.

 

This is the line in the .cmd file which I strongly believe is causing the error

 

    atprogram -t jtagice3 -i jtag -d at32uc3a0512 program -o 0x80000000 -f at32uc3a-isp-1.0.3.bin --verify write -fs -o 0xfffe1410 --values 0xFC07FFFF

 

and a screen shot of the command prompt showing the error...

Now I'm already expecting that someone's going to politely tell me to use the help commands to see whats going on, and I have indeed done that. But I know that this worked with AS6.2 so I'm hoping that it's something simple that's changed between AS6.2 and AS7 and someone who has more experience with atprogram can point me in the right direction...

This topic has a solution.
Last Edited: Tue. Mar 14, 2017 - 02:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which bit of that command is trying to do the fuse writing? I assume it is the "-fs" in:

 

-fs -o 0xfffe1410 --values 0xFC07FFFF

 

The error seems to be that it is reading 0xfffe1410 (which I take to be the address of the fuse?) as if it were 0x1fffc2824 according to the actual detail of the error.

 

EDIT: I love the fact that Atmel don't put the help/manual for this online so if you aren't sat in front of a copy you cannot work out how to use it. However as a "guess" I supposed the -o after -fs might mean "offset". The leading 0xFFF on that suggest it might be interpreted as a signed value by accident perhaps?

 

Last Edited: Tue. Mar 14, 2017 - 01:39 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I remember vaguely a discussion about this offset. Since the user can specify -fs, which means fuses, then the offset should mean an offset in fuses and not in the whole address range.
Try removing "-o  0xfffe1410".

 

-Jan Egil

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

clawson wrote:

Which bit of that command is trying to do the fuse writing? I assume it is the "-fs" ... ... as a "guess" I supposed the -o after -fs might mean "offset". The leading 0xFFF on that suggest it might be interpreted as a signed value by accident perhaps?

 

the '-fs' is indeed the fuse writing part, and the '-o' indeed means offset. I haven't looked into the fuse values for the device in question or how the memory is arranged but my guess would be that it's something to do with where atprogram is taking the offset from maybe?

 

Either way;

je_ruud wrote:

Try removing "-o  0xfffe1410".

 has fixed it. Thank you Jan!

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

I did wonder about the -o. In examples of -fs I can find online there is no sign of -o so clearly it just writes them to the "right place" anyway.