Bootloader section erased when application section loaded

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

Hi,

Avrstudio4 version: 4.08 Build 310
Imagecraft compiler : 6.31A

Device : Atmega16

I am trying to make a bootloader on the Atmega16.

I wrote some bootloader testcode and downloaded it to the device. The code is there at address 0x1C00 (1K boot section), and it is working.
USART interrupts are treated in the bootloader code.

The bootloader code should be kept in the bootloader section.

However, when i load, via avrstudio4, application software in the application
section. The Bootloader section is erased.
I need the application software because the bootloader will be triggered from the application section.

How can i prevent that the bootloader section is erased when the application section is downloaded to the device?

In the advanced debug options, is select that "always reprogram device when loading object file"

Thanks for help
Fabrizio,

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

Quote:
However, when i load, via avrstudio4, application software in the application
section.

The answer depends on how you load the application software; is it by ISP? JTAG? You will need to be more specific. It could be as simple as not erasing on the second load.
Dave Raymond

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

Dave,

I load the application software via JTAG.

Fabrizio,

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

Quote:
It could be as simple as not erasing on the second load

That's how I did it when developing my bootloader ...
1 : Program bootloader.: uisp --erase --verify --upload if=bootloader.hex
2: Program "dummy application".: uisp --verify --upload if=dummy.hex

EDIT ! : Sorry, I didn't notice that this was in the AvrStudio forum ...

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

I can think of two relatively simple solutions:

1) Merge the bootloader hex file and the application hex file into a single combined file, and program it via AVR Studio.
Merging should be relatively easy, perhaps using only a text editor to delete the footer information from the end of the application hex file, and then paste the body and footer of the bootloader hex file in at the end.

A more sophisticated technique would be to merge them together using a utility such as SRecord.

2) Inhibit the Flash Erase before programming the application hex file.
ALWAYS erase the flash when you program the bootloader. Then, turn off the "Erase Flash before programming" option, and flash the application code.

Whenever you need to program a new version of the application, you'd need to first erase the entire flash, and re-program the bootloader again first.
_______________

Another option:
Write your bootloader such that it can _either_ get triggered by an action in the application section, _or else_ it can trigger itself when the system first boots up.

One common way to do this would be to program a time limit in the bootloader... if no commands are received to begin re-programming the application section within a given time limit, then the bootloader will abort and switch over to running the regular application code.

Then, program the BOOTRST fuse, so that the first thing which runs each time the AVR starts up, is always the bootloader.

Now, you can just program the bootloader, and then use the bootloader itself to program the remainder of the application Flash section.

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

Quote:

That's how I did it when developing my bootloader ...
1 : Program bootloader.: uisp --erase --verify --upload if=bootloader.hex
2: Program "dummy application".: uisp --verify --upload if=dummy.hex

Where are you enterring this command sequence in Averstudio4 ?

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

Quote:
Where are you enterring this command sequence in Averstudio4 ?

Sorry ! I didn't notice that this thread was in ther AvrStudio forum ...

But the idea is the same regardless the programming application ...
1: Erase entire chip & program bootloader into bootloader area
2: Program application software without erasing

/J

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

lfmorrison wrote:
I can think of two relatively simple solutions:

1) Merge the bootloader hex file and the application hex file into a single combined file, and program it via AVR Studio.

I am working on a RS485 network of microcontrollers, for hobby.
Every time i change the application software i need to merge it with the
bootloader. I could make a tool to do this!
Good workarround.

Quote:

2) Inhibit the Flash Erase before programming the application hex file.

How do you do this in Avrstudio4.
The only advanced options when using jtag-ice are options regarding the
reprogramming of the device, there is no option where you can inhibit the
erasure of the device.
This would be a good solution.

Quote:

Another option:
Write your bootloader such that it can _either_ get triggered by an action in the application section, _or else_ it can trigger itself when the system first boots up.

This is a good solution for later on. The devices are integrated in a RS485
chain, i need an application program in the device that receives the command from the controlling PC to start the bootload.

Especially during development of the system it would be interresting to
be able to load the bootloader and the application software sepearetly.
Therefore i think your second proposal is for the time being the most
interresting.

Main question, how can you prevent a flash erase when loading software.
When application software is loaded, the bootloader software is erased.
When bootloader software is loaded, the application software is erased.

Device erase or flash gets cleared.?
We are NOT talking about a device erase here. But about a clearing of the
flash. For test i programmed the Boot_Reset_Enable fuse. This fuse will
be reset after a device_erase. When i load the bootloader software the
flash is cleared, but the Boot_Reset_Enable fuse is still set. Meaning that
the device is not erased.

Maybe i should take a closer look to the hex file produced by the imagecraft compiler. Maybe unused flash memory is filled up with 0xFF

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

fabrizio wrote:
Quote:

2) Inhibit the Flash Erase before programming the application hex file.

How do you do this in Avrstudio4.


Now for a little lesson on Flash memory:
You can only do two things to Flash: Erase it, or Program it.

When you Program it, the only thing you can do is take individual bits and change them from 1's to 0's.

If there are already any 0's in the Flash prior to programming, then they will remain 0's after programming, no matter what you have to say about it.

When you Erase it, you're taking ALL of the 0's and changing them back to 1's.

As you probably already know, a Bootloader is capable of erasing the Flash one "page" at a time. That isn't the case with a JTAG or ISP programmer: They must do it all at once.

The only way for a JTAG or ISP programmer to erase the Flash is to emit a Chip Erase command.

Fuse Bits will always withstand a Chip Erase command. Depending on the state of the EEPSAVE fuse, the EEPROM may withstand a Chip Erase command, or else it may be erased along with the rest of the device.

The Lock Bits and Flash are always Erased by a Chip Erase command.

When you go into the main AVR Studio programming interface (NOT the Debug interface) there should be a check box you can click to selectively turn off the Chip Erase.

Attachment(s): 

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

lfmorrison wrote:

Now for a little lesson on Flash memory:

Thank you, for the lesson.

I was wrong in my previous post. The Boot_Reset_Vector_Enable fuse is NOT cleared on chip_erase.

The "Erase device before programming" checkbox is NOT checked in the
gui. The JTAG-ICE is found on COM2 so the programming-mode can not be selected.

However i see a flash erase after programming the device?

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

OK, call this a mad idea, but how about loading the application code using the bootloader itself? I can think of two positives and one negative:

+1) this heavily exercises the bootloader you've written which is worthwhile testing before release
+2) you won't need to worry about the bootloader getting wiped as it can't (hopefully!) wipe itself

but

-1) the transfer/programming cycle may be longer than a JTAG transfer

Cliff

PS This advice comes from projects I've worked on on a slightly larger scale (37KB bootloader, 12MB application code). When we bring up a new board the first thing we get running (using JTAG ICEs) is the bootloader but as soon as that is finalised we distribute devices to about 50-100 testers and it would be impractical (cost ineffective!) for them all to have JTAGs. We then distribute alpha/betas of the main app binary and they use an RS232 download to squirt it into the board using the bootloader. This gives the bootloader code a severe thrashing to be sure it has no major errors because it doesn't matter how buggy the main app is, as long as the bootloader will function you can always repair/replace the main app but, on the whole, you can never repair/replace the bootloader (without performing a VERY dangerous operation!)

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

Cliff,

Has also proposed by Ifmorrison, these seems to be best way. Let the bootloader load the
application software.

It is during development of the application that i can load the application-software using the JTAG interface.

But application software updates, after the device is incorporated into the RS485 chain,
have to be done via the bootloader.

Nevertheless the question remains, why do i get a chip-erase on application- or bootloader
download via the JTAGICE. Although the checkbox "Erase device before programming" is UNCHECKED.

Regards,
Fabrizio,

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

Are the bootloader and amin app co-dependent then? I'd have thought that during the development of the main app you woudn't need the bootloader in place at all (UNLESS the main app calls a function in the bootloader??). Just set the device fuses so it boots to 0000 rarther than the bootloader entry point and do all app development independent of the bootloader (which you've previoulsy separately developed/tested using JTAG)

When you are finally ready for app roll out set the bootloader fuses again, program in the bootloader and use it to program in the app.

Cliff

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

clawson wrote:

When you are finally ready for app roll out set the bootloader fuses again, program in the bootloader and use it to program in the app.

Cliff,

This is the way of working, i agree.

Maybe my problem is NOT a problem.

Let me try to explain in a different way.

Suppose the application is tested and loaded in the device.
Know i need to load the bootloader in the boot-section of the device.
(With Avrstudio4 via GTAG-ICE)

After successful bootloader load, i see with Avrstudio4 that the application-section is cleared. At this moment the JTAG connector is still in place, and the device is in debug-mode. The bootloader software has not executed after download.

Why is the application-section of the device cleared, when i load the
bootloader into the bootloader-section. Although the checkbox "erase device before programming" in NOT checked in AVRSTUDIO4.

I understand that i can use the bootloader to load the application program again. But once more, why is the application-section cleared?
It should still be there because the checkbox "erase device before programming" in NOT checked.

Regards,
Fabrizio.