Simultaneous debug of boot and application code with COFF

Log in or register to post comments
Go To Last Post
14 posts / 0 new
Author
Message
gahelton
gahelton's picture
Level: Resident
Joined: Wed. Mar 19, 2003
Posts: 738 View posts
#1
Posted by gahelton: Wed. Jun 13, 2007 - 02:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How do you simultaneously debug boot and application code created by a C compiler when the C compiler generates seperate hex and COFF files for each section ?

Can two COFF files be uploaded for symbolic debug ?

It seems as though this should be possible since the memory areas do not overlap. The tools (AVR Studio) would need a setup feature so the user could instruct the tools where the boot and application sections are located. When the tools have this information, then only the pages associated with that section would have to be erased when new boot or application code was uploaded. The other section would be left untouched. Of course, the user would have to tell the tool which section was being uploaded.

If someone know of a method for simutaneous, symbolic debugging of both boot and application code, please respond.

Tags:

Tools, Atmel Studio (AVR-related)
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 104948 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. Jun 13, 2007 - 02:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But at run time you won't have links between boot and app will you? Or, if you do, it'll presumably be very controlled via something like a dispatch table of function pointers - so can't you just "dummy" those in one half to debug it?

Cliff

Top
gahelton
gahelton's picture
Level: Resident
Joined: Wed. Mar 19, 2003
Posts: 738 View posts
Posted by gahelton: Wed. Jun 13, 2007 - 03:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The communications state machine always runs in the boot section. The interrupt vector for the TWI (in the app section) jumps to a fixed location in boot, which in turn jumps to the actual ISR for communications. This prevents duplication of this code in both sections.

Under "normal" circumstances, code from both sections are in operation. The only time this is not true is if the checksum for the application section has failed. Application section checksum is calculated on power-up. If a problem is detected, the code will remain in the boot section and boot interrupt vectors will be used. Boot code will wait for a communications command to update flash to repair the damage.

Top
EW
EW's picture
Level: Raving Lunatic
Joined: Thu. Mar 1, 2001
Posts: 4914 View posts
Location: Rocky Mountains
Posted by EW: Thu. Jun 14, 2007 - 01:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gahelton wrote:
How do you simultaneously debug boot and application code created by a C compiler when the C compiler generates seperate hex and COFF files for each section ?

Can two COFF files be uploaded for symbolic debug ?

It seems as though this should be possible since the memory areas do not overlap. The tools (AVR Studio) would need a setup feature so the user could instruct the tools where the boot and application sections are located. When the tools have this information, then only the pages associated with that section would have to be erased when new boot or application code was uploaded. The other section would be left untouched. Of course, the user would have to tell the tool which section was being uploaded.

If someone know of a method for simutaneous, symbolic debugging of both boot and application code, please respond.

What compiler are you using?

Eric Weddington
www.linkedin.com/in/ericweddington/

Top
gahelton
gahelton's picture
Level: Resident
Joined: Wed. Mar 19, 2003
Posts: 738 View posts
Posted by gahelton: Thu. Jun 14, 2007 - 01:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using the ImageCraft ICCAVR7 C compiler.

Support recommended that I compile the boot and application sections seperately. This is why there are seperate COFF and hex files for each section. Of course, the hex files can be combined, but I would lose the symbolic information contained in one of the COFF files.

Top
gahelton
gahelton's picture
Level: Resident
Joined: Wed. Mar 19, 2003
Posts: 738 View posts
Posted by gahelton: Sat. Jun 30, 2007 - 03:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Has anyone got any ideas on how to accomplish simultaneous debug of boot AND application code ?

Here is what I've tried and the results.

1. The boot and application code are compliled as seperate projects which create seperate COFF and hex files as previously describe.
2. The hex files from the two sections were merged by removing the end of record marker from one of the files and concatenating them together into a single hex file.
3. A third project was created which uses the concatenated hex file for debug upload. The project is setup so that the COFF file for the application section will be loaded into Studio for symbolic debug of the application code. All of the hooks are in place in the boot section to transistion to the application section. This is as simple as a jump to 0x0000 (reset vector in application section)

Results.
Since the initial reset vector is in the boot section, and since Studio has no know knowledge of what is in boot section, Studio is confused and the reset button in studio does not work.

Surely someone else other than me has found this tremendous, gapping hole in the debugging capability of using Studio where two projects must be combined.

Who has had experience with this ? Any thoughts ?

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 104948 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Sun. Jul 1, 2007 - 05:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess most people write and debug the boot and the app in isloation so don't face this.

Top
gahelton
gahelton's picture
Level: Resident
Joined: Wed. Mar 19, 2003
Posts: 738 View posts
Posted by gahelton: Sun. Jul 1, 2007 - 09:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Even though the boot code and application code was written seperately, they go into the same micro and at some point must be debugged. At some point, an interface has to be between the sections - either moving from the bootloader to app code or visa-versa. Normally, the reset vector is set to the bootloader so it can verify the app section is valid before transistion to app code is made.

These interface need to be tested in some manner rather than blind faith that the code behaves as you would expect. Although, I have confidence in the boot loader since it was debugged up to the point of transition to app code.

Here is the real problem. As far as I can tell, there is no way to keep my bootloader in memory when the application code is loaded for debugging. Studio and/or the MKII erases the entire memory before any code is uploaded. This is in spite of the fact that the boot loader has already be loaded with a programmer and THE LOCK BITS HAVE BEEN SET ! Pardon my increase in tone.

If the tools would simply not erase the entire memory when code was uploaded for debug, then my code would cycle through the bootloader and into the app section so that debugging of the app section could occur. It would be nice to have symbolic debug of both sections, but I would give that up if the tools didn't override my protection an erase the boot code that is already in place.

This shouldn't be difficult to implement. If the tools would only erase flash pages where program data was being uploaded and leave the reset alone, this particular problem would be solved. I understand that uploading new code for debug would take about twice as long since "each" page must be erased before programming. Studio should have a checkboxs to allow for either "Erase Chip Before Program Upload" or "Erase Only Pages Necessary" option. Selecting the later option would save the boot code if it we already loaded.

I've submitted a support ticket with Atmel on this subject. Also, I have another thread going in this forum on this subject as well.

https://www.avrfreaks.net/index.p...

Here is a link to another Atmel user with a similar problem/request.

https://www.avrfreaks.net/index.p...

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 104948 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Jul 2, 2007 - 10:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was thinking about this driving to work. Clearly the app code may be dependent on functionality in the bootloader but the BL cannot be dependent on anything in the app (the nature of BLs is that the app may not always be there!). So why don't you concentrate the effort on debugging the BL first. Once that's done and dusted and you know it's routines are totally reliable then, as far as the app is concerned, it's a "black box". So now you can switch to debugging the app. You may not be able to source level debug the stuff in the BL that it calls into but as long as you have test harness tested the APIs it provides you shouldn't need to as you've already proven it operates to spec.

Cliff

Top
gahelton
gahelton's picture
Level: Resident
Joined: Wed. Mar 19, 2003
Posts: 738 View posts
Posted by gahelton: Mon. Jul 2, 2007 - 04:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff,

I appreciate your thoughts on this matter.

My boot code has been debugged and I'm confident in its operation. The problem is that the tools (MKII)will not allow boot code and application code to reside in the micro simulaneously while performing symbolic debug of the application code. The MKII erases the entire chip anytime any program memory (flash)is uploaded. The bootloader cannot remain resident when application code is uploaded for symbolic debug using the existing tools.

The only way at present to upload and keep both the bootloader and application code in the micro is to merge the hex files and upload the single, merged file. But, symbolic debug is lost.

Atmel must change the tools so that a chip erase is not executed before new program code is uploaded (could be an option selection). If flash pages were erased, then reprogrammed on a page by page basis, then the bootloader could be programmed into the device and remain resident while the application code is uploaded and debugged as many times as necessary.

Top
tolsen2
tolsen2's picture
Level: Hangaround
Joined: Tue. Oct 7, 2003
Posts: 157 View posts
Location: Trondheim, Norway
Posted by tolsen2: Mon. Jul 2, 2007 - 08:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you looked at the JTAGICE mkII's options dialog where you can specify whether to reprogram the device when starting a debug session? If you select the "Open Platform Options" checkbox when selecting debugger platform, you can make sure this setting is active before you start the debug session.

Tore

Top
gahelton
gahelton's picture
Level: Resident
Joined: Wed. Mar 19, 2003
Posts: 738 View posts
Posted by gahelton: Mon. Jul 2, 2007 - 10:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tore,

As far as I can tell, the program download options

Code:
(*) 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. I have tried all of them with the setup being performed prior to program upload. The entire flash memory is completely erased before each code upload to the device in all cases.

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 104948 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Jul 3, 2007 - 10:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why would it be doing an upload to the device in case 3 ?? If there's an error here then that is it.

Top
gahelton
gahelton's picture
Level: Resident
Joined: Wed. Mar 19, 2003
Posts: 738 View posts
Posted by gahelton: Tue. Jul 3, 2007 - 02:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff,

The meaning of the programming option settings listed above are vague at best - especially option #3, "Don't reprogram the device" which seems to have conflicting intent at this point.

The options that I would like to see here (or somewhere) are:

( ) Erase entire flash before upload
(*) Erase affected flash pages during upload

The later option would protect a section of code that the user doesn't want to be reprogrammed (could be boot, application, tables, etc).

After looking at the command structure to the MKII (app note AVR069), I am convinced that the MKII is not capable of the erasing and reprogramming flash on a page by page basis (today). A new command "CMD_ERASE_PAGE_ISP" should be added to support the options above. Repeating the following command sequence would accomplish this goal for the last option.

CMD_ERASE_PAGE_ISP
CMD_PROGRAM_FLASH_ISP (page mode)

*** Still no response from Atmel on support ticket ***

Top