| Author |
Message |
|
|
 Posted: Jul 19, 2012 - 01:20 PM |
|
Joined: Feb 16, 2012
Posts: 4
Location: Tarxien, Malta
|
|
Hi friends,
First of all this is my first post on this forum so excuse me if i break some forum policy 
I am trying to make a simple checksum of the flash memory(basically the application program itself, if i'm not mistaken it's the .text section) by simply adding the memory locations together and compare the sum to what it's supposed to be. This function has to be performed first thing before the main program is executed to verify that no memory location is damaged in some way.
I am able to read the flash memory locations one by one by using the "pgm_read_byte" function, but what I am missing is how to determine the start and finish of the .text section in the flash memory.
I would appreciate if someone can enlighten me on this issue.
Thanks in advance!
Luke  |
|
|
| |
|
|
|
|
|
|
Posted: Jul 19, 2012 - 01:52 PM |
|
Joined: Jul 18, 2005
Posts: 62371
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
but what I am missing is how to determine the start and finish of the .text section in the flash memory.
Apart from bootloaders .text always starts at 0x0000 because that's where the reset (R)JMP is located. From a .map file you can see that .text ends at:
Code:
0x00000282 _etext = .
But is that really where you want to stop checking? What about the .data initialisers? If so the end mark is:
Code:
0x000000a6 __data_load_end = (__data_load_start + SIZEOF (.data))
|
_________________
|
| |
|
|
|
|
|
|
Posted: Jul 19, 2012 - 01:55 PM |
|
Joined: Sep 05, 2001
Posts: 2499
|
|
I would suggest one of the CRC16 from the crc16.h.
Peter |
|
|
| |
|
|
|
|
|
|
Posted: Jul 19, 2012 - 02:04 PM |
|
Joined: Jul 18, 2005
Posts: 62371
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
I built this:
Code:
#include <stdio.h>
#include <avr/io.h>
extern int _etext;
extern int __data_load_end;
int n[10] = { 1,2,3,4,5,6,7,8,9};
char buff[10];
int main(void) {
sprintf(buff,"%u", (unsigned int)&_etext);
sprintf(buff,"%u", (unsigned int)&__data_load_end);
}
After the first sprintf buff[] contained "1730" and after the second it contained "1754". That is 0x6C2 and 0x6DA. The .map file for it had:
Code:
0x000006c2 _etext = .
...
0x000006c2 __data_load_start = LOADADDR (.data)
0x000006da __data_load_end = (__data_load_start + SIZEOF (.data))
BTW I am making a huge assumption that you are using GCC (a fair one to make when you mentioned pgm_read_byte() though ) |
_________________
|
| |
|
|
|
|
|
|
Posted: Jul 19, 2012 - 02:20 PM |
|
Joined: Feb 16, 2012
Posts: 4
Location: Tarxien, Malta
|
|
|
Quote:
BTW I am making a huge assumption that you are using GCC (a fair one to make when you mentioned pgm_read_byte() though )
Yes your assumption is right
Quote:
But is that really where you want to stop checking?
Actually I will probably check .data as well but for now I was only testing the concept. Hmm you are right the end locations are listed in the .map file, probably I've overseen them. That makes things much more simple to follow thanks clawson good day! |
|
|
| |
|
|
|
|
|
|
Posted: Jul 19, 2012 - 02:24 PM |
|
Joined: Jul 18, 2005
Posts: 62371
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
Hmm you are right the end locations are listed in the .map file
More to the point they are available as linkable symbols in the C code (hence my example above). Note that the number you are interested in is '&symbol' (the address of the symbol) not just 'symbol' which would return the contents of that address. Hence my use of "(unsigned int)&_etext" and "(unsigned int)&__data_load_end". Other linker symbols that you see in the .map file (as a result of commands in the linker script) are available in the same way.
(I'll move this thread to GCC). |
_________________
|
| |
|
|
|
|
|
|
Posted: Jul 19, 2012 - 02:46 PM |
|
Joined: Feb 16, 2012
Posts: 4
Location: Tarxien, Malta
|
|
|
Quote:
More to the point they are available as linkable symbols in the C code (hence my example above)
Good good thanks for pointing it out, this will be a lot helpful otherwise I would have had to determine the end location manually! |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
