Atmel Studio CLI 0.6.1.1042 failed to write fuse register

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

Atmel Studio Command Line Interface 0.6.1.1042(atmel studio 7) failed to write fuse register.
This tool failed to run:
>atprogram -t jtagice3 -i jtag -d at32uc3a1256 write -fs -o 0xfffe1410 --values 0x7c03ffff
Firmware check OK
Address 0x1fffc2824L is outside of maxaddress 0x100000000L for fuses
[ERROR] An unexpected error occurred when executing.
Traceback (most recent call last):
  File "__init__.py", line 55, in run
Exception

Atmel Studio Command Line Interface  0.6.1.944 (atmel studio 6.2) is working with this command perfectly:
>atprogram -t jtagice3 -i jtag -d at32uc3a1256 write -fs -o 0xfffe1410 --values 0x7c03ffff
Firmware check OK
Write completed successfully.

This topic has a solution.
Last Edited: Thu. Nov 3, 2016 - 12:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not 100% sure what you're asking here, but from the thread title I gather something's gone wrong when you tried to write a fuse register. Now I've never bothered to use the command line interface myself so I'm not going to comment as to what could have could have gone wrong, but if you have AS7 (and AS6.2) and a JTAGICE3, why not just use the Device Programming window to do this? It'll take care of all of this for you, and it also makes fuse set up far easier, and considering that setting the wrong fuses can actually brick your device (particularly when you change clock source!) it might be wise that you use the device programming window instead for now. 

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

Seems it is trying to write to address*2. Looking into it.

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

je_ruud wrote:
Seems it is trying to write to address*2. Looking into it.

In fact, this is error in the new version of the Atmel CLI tool. It's seen from the CLI's output.

Last Edited: Thu. Nov 3, 2016 - 10:10 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

This turns out to be a regression about where the offset starts from. In the current release, when you specify the fuse segment ("-fs" option) the offset starts to count from the start of the fuse segment, rather than from 0x0. This has already been corrected in the code and will be back to normal in the next release. Until then you can use the "-o 0x0" if you want to program the first fuse.

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

je_ruud wrote:
where the offset starts from.

You're quite right!

I have tested fuse register offset instead register address and it was success.

It's badly that Atmel didn't corrected command help in the new release of cli.

">atprogram help write

...

atprogram -t avrone -i jtag -d at32uc3b0512 write -fs -o 0xfffe1410 --values FFFFFFFE
  Program LOCK0 in FGPFRLO of an UC3B0512 device.

.....

 

Thank you for suggestion.

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

You made my day. Run into the same problem after setting up a fresh system. Did not update for years because "never change a running system"!

Flashing the ISP-Bootloader and reprogram fuses (need to do this after debugging) the new command is:

atprogram -t jtagice3 -i jtag -d at32uc3a3256 program --format bin -f Boot_at32uc3a3-isp-1.0.3.bin -o 0x80000000 --verify write -fs -o 0 --values 0x7FF7FFFF
(programming my AT32UC3A3256 with the ice3)
 

Last Edited: Sun. Feb 12, 2017 - 01:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I still see this issue in Atmel Studio 7.0 (build 1645), so "fixed for next release" seems to be not true.

 

@je_ruud:

Will this be fixed for future releases, or shall we stick with offset 0 ?