Urgent - Dev Team PLS Respond - Debug boot and app code

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

Studio Development Team,

I have an urgent need to continue my project which consists of a boot section and application section. So far, no one has provided a satisfactory method for symbolic debug of these two seperately created sections using an ImageCraft C complier. Each section has their own COFF and HEX files.

It seems as though combining these files into a single file for upload into Studio is not possible, nor is uploading them seperately for a single debug session.

I can combine the boot and application HEX files into a single file and upload this into Studio, but I will have no symbolic debug information for either section. Or, I can upload the COFF file for either section to get symbol information, BUT, the portion of the combined hex file without symbol information from the COFF does not get loaded.

It seems as though there may be several ways to handle this. Here's a list of my thoughts.

1. Create a utility that would combine the symbol information from two or more COFF file (where addresses did not overlap) into a single file so that studio will have all of the information that it needs from both sections. In addition, this utility should also combine the seperate hex files into a single file.
2. Change studio to allow more than one symbol file (COFF or other) to be loaded into a debug session. As long as there is no overlap or conflict, there would be no problem.
3. Change studio to allow more that one hex file to be uploaded into a debug session. Once again, as long as there were no overlap of addresses being loaded, there would be no problem.
4. It appears as if studio erases the entire flash memory in the micro every time new code is uploaded using JTAGICEMKII. Although there are some setup features for the MKII under Debug>JTAGMKII Options>Debug>Program Download, they are not clear. The "Only reprogram device if object file has changed" selection does not keep the boot code from being erased. If Studio only erased pages where code has changed while leaving unchanged pages intact, then boot code could be uploaded through a programmer, locked with the lock bits, and kept in the micro. Application code could be changed and uploaded and debugged as required through Studio. Of course, using this method, there would not be any symbol debug of the boot section, but the code would still be there.
5. Even if I program the boot code and protect it with the bootlock bits, Studio/JTAGICEMII still overwrites (erases) that section when I upload application code. This is verfied by examining the code space and fuses after the application code was uploaded. My boot "protection" fuse has been erased and my boot code has been erased. If this didn't occur, I could debug application code while leaving the boot code intact. Once again, this would mean no symbol debug of boot code, but it would still be there.

Summary:
It appears that Studio and the MKII are trying to "do me a favor" and make sure there is no left over code in the processor when a new debug session is started. There must be a method for doing either or both of these functions:
1. Keep a section of code intact without Studio/MKII overriding/overwritting the protection bits -OR-
2. Combining the two COFF and HEX files into single file(s) for debugging -OR-
3. Having the ability to load multiple HEX and COFF files into a single debug session.

I hope that I've given you enough information of my intent and needs. If there is any way of performing these functions today, please let me know.

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

If you're in such a hurry why don't send an email to Atmel?
You're answers won't come faster at this site just because you start three threads at two different forums...

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

Thanks Lennart,

I just submitted a support ticket with Atmel on this subject.

It was my sincere hope that someone else in the world had come across this seemingly obvious problem with debugging and would have found a solution(s) or workaround by now. But I guess not.

In any case, I'll post Atmel's response on this thread only (just in case anyone is interested).

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

Btw., COFF is outdated, and I believe no longer maintained by the
AVR Studio dev team. You might as well urge your compiler vendor
to eventually switch to ELF/DWARF-2, at the advantage for you that
(ELF being rather well standardized) a number of tools exist to
manipulate ELF files.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Atmel has responded to my support request.

Symbolic debugging is possible on one of the sections (boot or application) but not both simultaneously at this time. This will at least get me going again.

The procedure involves uploading a section of hex code (boot) while erasing the device, then uploading a section (application) of hex code WITHOUT erasing the device.
Studio is launched and the project selected. The "Don't reprogram device" option is selected. This uploads debug info for the selected section without changing any code in the device.

Here is the text of Atmel's response.

Quote:
Dear Mr Helton,

I got this back from the tools department:

Hi,

It is correct that AVR Studio does not presently have a convenient way of
debugging multiple FLASH images simultanously. It has been our intention for
a long while to implement such a feature, but it has not been given
priorities agains other important features and continous device support.

There is one backdoor to overcome the problem, but it require some work each
time the object files changes, and it only provides symbolic debugging of
either the application or the bootloader.

1. Open the programming dialog, erase the target device, and upload both the
application and the bootloader separately. This requires the hex files to be
built. Make sure that the 'erase device before programming' option is not
selected.

2. Select 'project wizard' from the project menu, select the project for
either the application or the bootloader (the one you want to debug with
symbols)and click next. Select the JTAGICE mkII and the device, and tick
'open platform options'. This will force the platform options to be
displayed when debugging starts. Click finish.

3. The options are displayed, open the debug tab, and select "Don't
reprogram device". Click OK. The object file will now be loaded into AVR
Studio, but the device will not be reprogrammed. Code in both sections will
execute as normal, but high-level run control and symbolic debugging will
only be available for one of them.

As I said, better support for bootloader debugging is already on our
todo-list, but unfortunately I cannot say when it will be implemented.
Hopefully the above can help.

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

Confused now - how exactly does that procedure differ from what I suggested to you almost a week ago? :?

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

Disregard the last post. This method does not work either.

When "Don't reprogram device" is selected, the device is not reprogrammed - BUT ITS STILL ERASED !

Looking at a program memory window shows the device has no code in it all.

Houston, we "Still" have a problem.