Switch off complete flash erase while JTAG programming

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

Load a program into the flash via JTAG ICE and AVR Studio automatically erases the whole Flash. That's fine if you have one piece of code, but is a mess if you play around with code sharing between bootloader and application. Programming via ISP gives the opportunity to select if the flash should be erased completely or not. Is there a way to prevent erasing of the whole flash while prgramming via JTAG and AVR Studio?

If I did not miss any switch is this feature a need by the CPU Hardware (Jtag I/F) or is it still not implemented in the AVR Studio?

Knut

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

Is it ELF or HEX files you are downloading over JTAG? If the latter then you could use a utility such as srecord to "glue" the two HEX files together before download as one possible solution

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

clawson wrote:
Is it ELF or HEX files you are downloading over JTAG? If the latter then you could use a utility such as srecord to "glue" the two HEX files together before download as one possible solution

Clawson, in AvrStudio you have a button "Build and Run" or the "Start Debugging" button. I have no idea what Atmel is loading but after gambling around with srecord it seems that AVRStudio is using something derived from the ELF file.

The work-aroud is of course to make a debug version of your program where the shared code and the application is linked with different section (GCC) into one ELF and load this. This gives problems with the interface BL / App because of doubled defined names. The end is for debugging and prduction you have different ELF files and that is what I hate. Having two files with the functionality will always a good source for an unrestricted number of problems and errors :x

I would like someone from Atmel to reply. If I don't miss any button to select the erase behaviour - like for ISP - all other functionality is covered by the GUI and therefore someone with a look to GUI-sources could shine some light on this issue.

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

But Atmel staff don't reply here - if you want an answer from Atmel you need to email to avr@atmel.com - when you do you are automatically issued a "ticket number" and the query/issue is tracked until the ticket is closed - so you are guaranteed an answer. If the issue is specifically about Studio then you may get more immediate access to the Studio team using avrbeta@atmel.com in fact

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

Thanks for clearing that "A forum for the AVR studio 4 release. Monitored by the devteam" does not mean "replies by the Atmel development team are given to some issues".

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

Or use this one:
http://support.atmel.no/bin/customer

/Johan

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

kschwiRG wrote:
Thanks for clearing that "A forum for the AVR studio 4 release. Monitored by the devteam" does not mean "replies by the Atmel development team are given to some issues".

Knut,

I dare say most developers stop by this forum several times a week. Speaking for myself, I sometimes reply if I know the answer off the top of my head and there aren't other good replies yet. I don't think we want to pretend that there are guaranteed response times on AVR Freaks.

As for your original question, there is no option in the GUI to do what you want. I recommend you do as the other posters suggest and send a mail to Atmel with a feature request. (I'm posting from home and will surely forget this when I get to work :-)

Tore
(working on AVR32 Studio these days)

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

I have a similar problem and have posted two threads (my apologies) in this forum on this subject.

https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=50924

https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=51492

In addition, a support ticket has been submitted with Atmel on this deficiency. I will post Atmel's response on the "Urgent..." thread. Hopefully, they will fix/improve this soon.

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

gahelton wrote:
In addition, a support ticket has been submitted with Atmel on this deficiency. I will post Atmel's response on the "Urgent..." thread. Hopefully, they will fix/improve this soon.

I've sent a request to avrbeta and the their answer was use hex files - but you loose the contact to your source :evil: :twisted:

I don't know why to spent some hundret bucks for a JTAG Ice if I loose the contact to my source.

They also wrote:

Quote:

We have no workaround for using only one file for both debugging and programming at the moment, but we are aware of the problem and we have plans to improve this design.

For me it says it's not an AVR problem but an AVRStudio problem. My workaround is have a debug programm consisting of both (application & BL) and a production version where both are separated. Hope I don't have to debug any device with the splitted SW.

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

Does Studio not allow you to do the following then...

First take your boot and app .hex files and join them together and then JTAG or ISP program the code into the AVR. Then go to the options for the JTAGICE and where it says on the debug tab:

(*) Always reprogram device when loading object file
( ) Only reprogram device if object file has changed
( ) Don't reprogram the device

chane this from the first to the third option. Then debug the ELF/Coff file for either the app or the BL. That way you get source level debugging of one or the other with the other "block" in place in code flash.

Or does this not work? (it's certainly the way I've been debugging ARM based systems for years - programming the flash first then effectively just "load symbols" from the .elf)

tur you can only debug boot or app but not both at the source level but, as I said in a previous post, you should be able to debug the BL in isloation first then later you don't need to source level debug it while working on the app as it's already proven.

Cliff

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

As far as I can tell, the program download options

(*) Always reprogram device when loading object file 
( ) Only reprogram device if object file has changed 
( ) Don't reprogram the device 

have no effect on programming/debug of an AVR when using the MKII. The entire flash memory is completely erased before each code upload to the device.

At the present time, there is no way to get any type of symbolic debug of either boot or app code when the sections are created seperately. Sure, the hex files can easily be merged and uploaded into the device. But now the project has to be treated like a dumbed down assembly project with no symbolic debug information at all. Not a pleasant prospect to debug.

Once again, if I could KEEP the bootcode (already debugged) in the device while having the ability to upload and symbolically debug the app code, I would be happy for now.

I suspect that the majority of the problem lies in the MKII. Looking at the command line interface for the device, I don't see an "Erase Page" command, but and "Erase Device" command is present. The "Program Flash" command gives no detailed description on it's function, but I suspect that it depends on the "device" being erased before the command executes - This is the root of the problem. I believe that Atmel wanted to speed up program upload to the device. By erasing the whole chip in a single operate instead of page by page while programming, the overall program upload speed would be greatly increased. However, this sacrifices the code that is already in the device (boot code).