void (*app_start) & Address allocation in gcc

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

This is not specific to any application,

Just noticed this hex line and following c code

:0400000300003800C1

void (*app_start)(void) = 0x0000;

Any relation in it?

The hex file says address 0000, type Start Segment Address Record and the data.

which address will this data get stored in the ATmega?

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

The fact that the 03 record is offsetting to CS:IP 0000:3800 suggests that this a bootloader and there's probably a --section-start or -Ttext setting the program start to 0x3800 which would be a common offset for a bootloader in a 16K AVR.

There's no direct connection between this and your:

void (*app_start)(void) = 0x0000;

that's simply setting a function pointer to 0x0000 so that:

app_start();

can be used to transfer control from the bootloader to the application.

Actually that line as written will cause a warning about converting the 0x0000 to a pointer. The simple solution is:

void (*app_start)(void) = (void *)0x0000;

the complex solution is:

void (*app_start)(void) = (void (*)(void))0x0000;

but the solution I'd go for is:

typedef void (*fn_ptr_type)(void);

fn_ptr_type app_start = (fn_ptr_type)0x0000;

In this way you only need to get the complex function pointer specification right in ONE place then you can use the much simpler 'fn_ptr_type' wherever it is then to be used. If you later change the function type to:

typedef char * (*fn_ptr_type)(int n, char c);

You only need to make the change in one place (and change the invocation to pass the parms and use the return value)

Last Edited: Wed. Dec 23, 2009 - 01:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
which address will this data get stored in the ATmega?
Nowhere. That record tells 'whoever is interested' that the mega will start executing from 0x3800 (looks like bootloader). Probably not real useful unless the 'reader' of the hex file can also change fuses.

Yeah! Can we now start a discussion on how to 'jump' to 0? We haven't had one of those in weeks (leave the 'goto' for me, please).

On second thought, lets wait a few more weeks.

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

Quote:
The fact that the 03 record is offsetting to CS:IP 0000:3800 suggests that this a bootloader and there's probably a --section-start or -Ttext setting the program start to 0x3800 which would be a common offset for a bootloader in a 16K AVR.

Clawson, thanks for in-depth reply.

The first line of this hex file is:
:103800000C94341C0C944F1C0C944F1C0C944F1CA7
As you pointed out the code stored at 0x3800.

I am now more keen on if any of the below line's data is stored in AVR's flash?
:0400000300003800C1

If no data from above line is stored in AVR's flash then will it be ok if this line is removed from the hex file?

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

Perhaps you should find a good reference on Intel .HEX format, and find out the meaning of that record type.

Then you need to find out what the program(s) in question do with that record type and encoded information.

THEN you will know whether you can "remove" it or not.

(It sure would be intersting to know the purpose of the urge to remove.)

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:

I am now more keen on if any of the below line's data is stored in AVR's flash?
:0400000300003800C1

If no data from above line is stored in AVR's flash then will it be ok if this line is removed from the hex file?


You need to read some documentation about Intel Hex - no, an 03 record, does not cause data to be generated. It's actually a "helper" for 80x86 code so that the programming/running system knows the entry address. In the context of AVR it is meaningless and may be removed. (though this, in itself, is pointless as AVR tools would not make any use of it anyway and would simply ignore it)

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

Quote:
I am now more keen on if any of the below line's data is stored in AVR's flash?
I guess 'Nowhere' didn't work. How about 'the same place in flash that an eof record is stored'.

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

Quote:
In the context of AVR it is meaningless and may be removed. (though this, in itself, is pointless as AVR tools would not make any use of it anyway and would simply ignore it)

I am more keen about intel hex implementation for AVR.

Quote:
It's actually a "helper" for 80x86 code so that the programming/running system knows the entry address.

The programmer software knows if from type 00 record as where to put the code in flash.
e.g. :103800000C94341C0C944F1C0C944F1C0C944F1CA7

If this is the case then what more the programming software will understand from :0400000300003800C1