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?
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)
which address will this data get stored in the ATmega?
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.
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?
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.)
I am now more keen on if any of the below line's data is stored in AVR's flash?
:0400000300003800C1If 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?
I am now more keen on if any of the below line's data is stored in AVR's flash?
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.
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
