Where is the Default Linker Script

Go To Last Post
150 posts / 0 new

Pages

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

what I am trying to say is, when I call a function the return address is pushed to the stack. 

How can I jump back to the return address with code 

i know I need something like that , but how can i know the adress of tha Stack_ADRESS ?

__asm__ Volatile("jmp Stack_ADRESS");

 

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

AVATAR_Freaks wrote:
when i jump from the application the SP gets stuck at the bootloader an never come back to the next line

         void do_spm_N (uint16_t page) __attribute__ ((used)) __attribute__ ((naked)) __attribute__((section(".vectors")));
                                                              =======================

 

 

Stefan Ernst

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

sternst wrote:

AVATAR_Freaks wrote:
when i jump from the application the SP gets stuck at the bootloader an never come back to the next line

         void do_spm_N (uint16_t page) __attribute__ ((used)) __attribute__ ((naked)) __attribute__((section(".vectors")));
                                                              =======================

 

 

do you think I should remove __attribute__ ((naked)) ?

 

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

Do you know what it does?? If not (a) why are you using it? and (b) do you think it might be time to consult the user manual?

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

Yea I know, it identifies the function as ASM function. and The reason I included is that I have few lines in my function in __ASM__ 

so I thought i should use it !?!?

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

time to read the manual - no point simply guessing

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

Okay I was able to fix this problem ! But now I am facing another obstacle !

Is there away to figure out the size of the used Flash Memory by the application code I know when you compile it tells you the size of you app, but I want to be able to save it as a variable and use it to figure out how much free space I have so when I write to flash memory i don't over write my application ?

 

Any suggestions 

 

Last Edited: Wed. Dec 5, 2018 - 01:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What I mean is  , How can I calculate the Free Memory space in the Flash memory ? (Using coding language )

the reason is I want to be able to determine how much free space do I have and make sure to not write any more data than this size ?

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

One approach is to write a cookie as a marker.

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

Another approach is to use __data_load_end.

Stefan Ernst

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

yes that works i used the __data_load_end

 

now how can i find the start of my bootloader ?

 

is it possible to pass avariable from the MAKEFILE to the flashmemeory ?

something like __data_load_end but used defined ?

 

 

 

Last Edited: Thu. Dec 6, 2018 - 05:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The start of the bootliader is surely at the BOOTSZ address?

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

HI , I am back with more question. I got the size thing working out and I can write to the flash memeory from the Application, However ther is one set back.

If I write from the application any thing less than 2096 i have no problems 

but if i tried to write something more  like 3311 , everything locks up and nothing gets written , I am trying to troubleshoot now, but no luck 

 

any suggestions ?

 

 

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

This is why God invented ICEs

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

Yes the ICE is not much help in my case. I figure out what is my problem 

I am using arduino Micro and it oly have up to 2K of RAM so when I try to allocate a memory buffer for the 3K file the whole thing locks up because there is no enough memory space. Maybe I can writ in small packs but the question now, Do atmega32u4 required restarting after writing each pack ? if  it does that is an issue 

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

You only ever deal in SPM_PAGESIZE packets so why would you ever need to hold 3K?

 

Have you looked at the design of other bootloaders?

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

Happy holidays guys !

 I am back with one more question 

when i call my bootloader function from my application one single time it works and everything executes as expected

 

However, If I put it in a loop pr called two consecutive times from the application, it gets stuck some how

          SNSFlashWrite(page_w ,flash_buffer,length); --> Assembly --> 00000080 ICALL Indirect call to (Z) // Z= 0x3856 (0x3856*2 = 70ac....
                                                                                                                        which is the location of the array in the bootloader ) this is correct 
           SNSFlashWrite(0x3100 ,flash_buffer,length);  -->>> 00000087 ICALL Indirect call to (Z) //z = 0x0203 i am not sure what is 0x0203 refer too?
           SNSFlashWrite(0x2700 ,flash_buffer,length); -->>>> 0000305E  ICALL         Indirect call to (Z)  //z = 0x0203 i am not sure what is 0x0203 refer too?

 

 

why the ICAL going to some random address ?

 

 

 

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

Show the real LSS but just a small question. Are the called bootloader functions reentrant? That is do they only use stack frame autos? (Bss and .data for the bootloader will not exist when called from the app)

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

here is the the entire LSS

test.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         00000000  00800100  00800100  0000198c  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  1 .boot         000017e8  00006810  00006810  000001a4  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .text         00000130  00000000  00000000  00000074  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .comment      00000030  00000000  00000000  0000198c  2**0
                  CONTENTS, READONLY
  4 .note.gnu.avr.deviceinfo 00000040  00000000  00000000  000019bc  2**2
                  CONTENTS, READONLY
  5 .debug_aranges 00000048  00000000  00000000  000019fc  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_info   000008cb  00000000  00000000  00001a44  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_abbrev 00000756  00000000  00000000  0000230f  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_line   00000332  00000000  00000000  00002a65  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_frame  00000068  00000000  00000000  00002d98  2**2
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_str    000003b0  00000000  00000000  00002e00  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_loc    000001a0  00000000  00000000  000031b0  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_ranges 00000028  00000000  00000000  00003350  2**0
                  CONTENTS, READONLY, DEBUGGING

Disassembly of section .text:

00000000 <__vectors>:
   0:	0c 94 34 00 	jmp	0x68	; 0x68 <__ctors_end>
   4:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
   8:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
   c:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  10:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  14:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  18:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  1c:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  20:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  24:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  28:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  2c:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  30:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  34:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  38:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  3c:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  40:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  44:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  48:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  4c:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  50:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  54:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  58:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  5c:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  60:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>
  64:	0c 94 3e 00 	jmp	0x7c	; 0x7c <__bad_interrupt>

00000068 <__ctors_end>:
  68:	11 24       	eor	r1, r1
  6a:	1f be       	out	0x3f, r1	; 63
  6c:	cf ef       	ldi	r28, 0xFF	; 255
  6e:	d8 e0       	ldi	r29, 0x08	; 8
  70:	de bf       	out	0x3e, r29	; 62
  72:	cd bf       	out	0x3d, r28	; 61
  74:	0e 94 58 00 	call	0xb0	; 0xb0 <main>
  78:	0c 94 96 00 	jmp	0x12c	; 0x12c <_exit>

0000007c <__bad_interrupt>:
  7c:	0c 94 00 00 	jmp	0	; 0x0 <__vectors>

00000080 <ioinit>:

void ioinit (void)
{
	//1 = output, 0 = input
	DDRB = 0b11111111; //All outputs
  80:	8f ef       	ldi	r24, 0xFF	; 255
  82:	84 b9       	out	0x04, r24	; 4
	DDRC = 0b11111111; //All outputs
  84:	87 b9       	out	0x07, r24	; 7
	DDRD = 0b11111110; //PORTD (RX on PD0)
  86:	8e ef       	ldi	r24, 0xFE	; 254
  88:	8a b9       	out	0x0a, r24	; 10
  8a:	08 95       	ret

0000008c <delay_ms>:
}

//General short delays
void delay_ms(uint16_t x)
{
  8c:	9c 01       	movw	r18, r24
	uint8_t y, z;
	for ( ; x > 0 ; x--){
  8e:	89 2b       	or	r24, r25
  90:	61 f4       	brne	.+24     	; 0xaa <delay_ms+0x1e>
  92:	08 95       	ret
	...
		for ( y = 0 ; y < 90 ; y++){
			for ( z = 0 ; z < 6 ; z++){
				asm volatile ("nop");
  a0:	91 50       	subi	r25, 0x01	; 1
//General short delays
void delay_ms(uint16_t x)
{
	uint8_t y, z;
	for ( ; x > 0 ; x--){
		for ( y = 0 ; y < 90 ; y++){
  a2:	c1 f7       	brne	.-16     	; 0x94 <delay_ms+0x8>

//General short delays
void delay_ms(uint16_t x)
{
	uint8_t y, z;
	for ( ; x > 0 ; x--){
  a4:	21 50       	subi	r18, 0x01	; 1
  a6:	31 09       	sbc	r19, r1
  a8:	11 f0       	breq	.+4      	; 0xae <delay_ms+0x22>
	DDRD = 0b11111110; //PORTD (RX on PD0)
}

//General short delays
void delay_ms(uint16_t x)
{
  aa:	9a e5       	ldi	r25, 0x5A	; 90
  ac:	f3 cf       	rjmp	.-26     	; 0x94 <delay_ms+0x8>
  ae:	08 95       	ret

000000b0 <main>:

int main(void)
{
  b0:	cf 93       	push	r28
  b2:	df 93       	push	r29
  b4:	00 d0       	rcall	.+0      	; 0xb6 <main+0x6>
  b6:	cd b7       	in	r28, 0x3d	; 61
  b8:	de b7       	in	r29, 0x3e	; 62
	//const do_spm_t do_spm_N = (do_spm_t)((0x70ac)>>1);
	volatile const SNSFlashWrite_T SNSFlashWrite = (SNSFlashWrite_T)((0x70ac)>>1); // Declearing the SNSFLashWrite In the Bootloader
  ba:	86 e5       	ldi	r24, 0x56	; 86
  bc:	98 e3       	ldi	r25, 0x38	; 56
  be:	9a 83       	std	Y+2, r25	; 0x02
  c0:	89 83       	std	Y+1, r24	; 0x01

    /* Replace with your application code */
		uint32_t page_w ;
	    ioinit(); //Setup IO pins and defaults
  c2:	0e 94 40 00 	call	0x80	; 0x80 <ioinit>
		page_w =0x2300;
		uint16_t length =1024;

		  

		uint8_t flash_buffer[length];
  c6:	8d b7       	in	r24, 0x3d	; 61
  c8:	9e b7       	in	r25, 0x3e	; 62
  ca:	94 50       	subi	r25, 0x04	; 4
  cc:	0f b6       	in	r0, 0x3f	; 63
  ce:	f8 94       	cli
  d0:	9e bf       	out	0x3e, r25	; 62
  d2:	0f be       	out	0x3f, r0	; 63
  d4:	8d bf       	out	0x3d, r24	; 61
  d6:	0d b7       	in	r16, 0x3d	; 61
  d8:	1e b7       	in	r17, 0x3e	; 62
  da:	0f 5f       	subi	r16, 0xFF	; 255
  dc:	1f 4f       	sbci	r17, 0xFF	; 255
  de:	f8 01       	movw	r30, r16
  e0:	2d b7       	in	r18, 0x3d	; 61
  e2:	3e b7       	in	r19, 0x3e	; 62
  e4:	2f 5f       	subi	r18, 0xFF	; 255
  e6:	3b 4f       	sbci	r19, 0xFB	; 251

		for( int i = 0; i < length; i++){
			flash_buffer[i] = 'B';
  e8:	82 e4       	ldi	r24, 0x42	; 66
  ea:	81 93       	st	Z+, r24

		

		uint8_t flash_buffer[length];

		for( int i = 0; i < length; i++){
  ec:	e2 17       	cp	r30, r18
  ee:	f3 07       	cpc	r31, r19
  f0:	e1 f7       	brne	.-8      	; 0xea <main+0x3a>

		for (uint16_t i=0 ; i<2 ; i++){
			page_w = page_w + i*0x400; 

	 	  SNSFlashWrite(page_w ,flash_buffer,length);
  f2:	e9 81       	ldd	r30, Y+1	; 0x01
  f4:	fa 81       	ldd	r31, Y+2	; 0x02
  f6:	40 e0       	ldi	r20, 0x00	; 0
  f8:	54 e0       	ldi	r21, 0x04	; 4
  fa:	b8 01       	movw	r22, r16
  fc:	80 e0       	ldi	r24, 0x00	; 0
  fe:	93 e2       	ldi	r25, 0x23	; 35
 100:	09 95       	icall
 102:	e9 81       	ldd	r30, Y+1	; 0x01
 104:	fa 81       	ldd	r31, Y+2	; 0x02
 106:	40 e0       	ldi	r20, 0x00	; 0
 108:	54 e0       	ldi	r21, 0x04	; 4
 10a:	b8 01       	movw	r22, r16
 10c:	80 e0       	ldi	r24, 0x00	; 0
 10e:	97 e2       	ldi	r25, 0x27	; 39
 110:	09 95       	icall

    while (1)
    {
		//L_LED_ON();
		TX_LED_ON();
 112:	5d 9a       	sbi	0x0b, 5	; 11
		RX_LED_ON();
 114:	28 9a       	sbi	0x05, 0	; 5
		delay_ms(1000);
 116:	88 ee       	ldi	r24, 0xE8	; 232
 118:	93 e0       	ldi	r25, 0x03	; 3
 11a:	0e 94 46 00 	call	0x8c	; 0x8c <delay_ms>

		//L_LED_OFF();
	    TX_LED_OFF();
 11e:	5d 98       	cbi	0x0b, 5	; 11
		RX_LED_OFF();
 120:	28 98       	cbi	0x05, 0	; 5
		delay_ms(1000);
 122:	88 ee       	ldi	r24, 0xE8	; 232
 124:	93 e0       	ldi	r25, 0x03	; 3
 126:	0e 94 46 00 	call	0x8c	; 0x8c <delay_ms>
 12a:	f3 cf       	rjmp	.-26     	; 0x112 <main+0x62>

0000012c <_exit>:
 12c:	f8 94       	cli

0000012e <__stop_program>:
 12e:	ff cf       	rjmp	.-2      	; 0x12e <__stop_program>

this is the LSS for the bootloader function 

 

000070ac <SNSFlashWrite>:
    uint8_t sreg;
	uint16_t i;
	uint16_t number_of_Pages=0;
	uint16_t Page_number=0 ;
	uint16_t page=0;
	number_of_Pages = Len>>7;//(Len/128)
    70ac:	ea 01       	movw	r28, r20
    70ae:	cc 0f       	add	r28, r28
    70b0:	cd 2f       	mov	r28, r29
    70b2:	cc 1f       	adc	r28, r28
    70b4:	dd 0b       	sbc	r29, r29
    70b6:	d1 95       	neg	r29

	if (Len> (number_of_Pages<<7)){
    70b8:	9e 01       	movw	r18, r28
    70ba:	36 95       	lsr	r19
    70bc:	32 2f       	mov	r19, r18
    70be:	22 27       	eor	r18, r18
    70c0:	37 95       	ror	r19
    70c2:	27 95       	ror	r18
    70c4:	24 17       	cp	r18, r20
    70c6:	35 07       	cpc	r19, r21
    70c8:	08 f4       	brcc	.+2      	; 0x70cc <SNSFlashWrite+0x20>
			number_of_Pages ++;
    70ca:	21 96       	adiw	r28, 0x01	; 1

	}
    // Disable interrupts.
    sreg = SREG;
    70cc:	ff b6       	in	r15, 0x3f	; 63
    cli();
    70ce:	f8 94       	cli
    eeprom_busy_wait ();
    70d0:	f9 99       	sbic	0x1f, 1	; 31
    70d2:	fe cf       	rjmp	.-4      	; 0x70d0 <SNSFlashWrite+0x24>
    70d4:	9b 01       	movw	r18, r22
    70d6:	60 e0       	ldi	r22, 0x00	; 0
    70d8:	70 e0       	ldi	r23, 0x00	; 0
    70da:	82 1b       	sub	r24, r18
    70dc:	93 0b       	sbc	r25, r19

	// Loop untill Finishing writting all the data
	for (Page_number=0; Page_number < number_of_Pages; Page_number++){
		page = First_page_adress + Page_number*SPM_PAGESIZE ;
		boot_page_erase (page);
    70de:	43 e0       	ldi	r20, 0x03	; 3
    70e0:	e4 2e       	mov	r14, r20
		for ( i=0;i < SPM_PAGESIZE; i+=2) {  // SPM_PAGESIZE = 128 words = 256 buts
			// Set up little-endian word.
			uint16_t w = *buf++;
			w += (*buf++) << 8;

		  boot_page_fill (page+i , w);
    70e2:	dd 24       	eor	r13, r13
    70e4:	d3 94       	inc	r13
		}
		boot_page_write (page);     // Store buffer in flash page.
    70e6:	55 e0       	ldi	r21, 0x05	; 5
    70e8:	c5 2e       	mov	r12, r21
    70ea:	2b c0       	rjmp	.+86     	; 0x7142 <SNSFlashWrite+0x96>
    70ec:	89 01       	movw	r16, r18
    70ee:	08 0f       	add	r16, r24
    70f0:	19 1f       	adc	r17, r25
    eeprom_busy_wait ();

	// Loop untill Finishing writting all the data
	for (Page_number=0; Page_number < number_of_Pages; Page_number++){
		page = First_page_adress + Page_number*SPM_PAGESIZE ;
		boot_page_erase (page);
    70f2:	f8 01       	movw	r30, r16
    70f4:	e0 92 57 00 	sts	0x0057, r14	; 0x800057 <__TEXT_REGION_LENGTH__+0x7e0057>
    70f8:	e8 95       	spm
		boot_spm_busy_wait ();      // Wait until the memory is erased.
    70fa:	07 b6       	in	r0, 0x37	; 55
    70fc:	00 fc       	sbrc	r0, 0
    70fe:	fd cf       	rjmp	.-6      	; 0x70fa <SNSFlashWrite+0x4e>
    7100:	d9 01       	movw	r26, r18
    7102:	20 58       	subi	r18, 0x80	; 128
    7104:	3f 4f       	sbci	r19, 0xFF	; 255

		for ( i=0;i < SPM_PAGESIZE; i+=2) {  // SPM_PAGESIZE = 128 words = 256 buts
			// Set up little-endian word.
			uint16_t w = *buf++;
    7106:	bc 90       	ld	r11, X
			w += (*buf++) << 8;

		  boot_page_fill (page+i , w);
    7108:	fd 01       	movw	r30, r26
    710a:	e8 0f       	add	r30, r24
    710c:	f9 1f       	adc	r31, r25
    710e:	11 96       	adiw	r26, 0x01	; 1
    7110:	4c 91       	ld	r20, X
    7112:	11 97       	sbiw	r26, 0x01	; 1
    7114:	50 e0       	ldi	r21, 0x00	; 0
    7116:	54 2f       	mov	r21, r20
    7118:	44 27       	eor	r20, r20
    711a:	4b 0d       	add	r20, r11
    711c:	51 1d       	adc	r21, r1
    711e:	0a 01       	movw	r0, r20
    7120:	d0 92 57 00 	sts	0x0057, r13	; 0x800057 <__TEXT_REGION_LENGTH__+0x7e0057>
    7124:	e8 95       	spm
    7126:	11 24       	eor	r1, r1
    7128:	12 96       	adiw	r26, 0x02	; 2
	for (Page_number=0; Page_number < number_of_Pages; Page_number++){
		page = First_page_adress + Page_number*SPM_PAGESIZE ;
		boot_page_erase (page);
		boot_spm_busy_wait ();      // Wait until the memory is erased.

		for ( i=0;i < SPM_PAGESIZE; i+=2) {  // SPM_PAGESIZE = 128 words = 256 buts
    712a:	2a 17       	cp	r18, r26
    712c:	3b 07       	cpc	r19, r27
    712e:	59 f7       	brne	.-42     	; 0x7106 <SNSFlashWrite+0x5a>
			uint16_t w = *buf++;
			w += (*buf++) << 8;

		  boot_page_fill (page+i , w);
		}
		boot_page_write (page);     // Store buffer in flash page.
    7130:	f8 01       	movw	r30, r16
    7132:	c0 92 57 00 	sts	0x0057, r12	; 0x800057 <__TEXT_REGION_LENGTH__+0x7e0057>
    7136:	e8 95       	spm
		boot_spm_busy_wait();       // Wait until the memory is written.
    7138:	07 b6       	in	r0, 0x37	; 55
    713a:	00 fc       	sbrc	r0, 0
    713c:	fd cf       	rjmp	.-6      	; 0x7138 <SNSFlashWrite+0x8c>
    sreg = SREG;
    cli();
    eeprom_busy_wait ();

	// Loop untill Finishing writting all the data
	for (Page_number=0; Page_number < number_of_Pages; Page_number++){
    713e:	6f 5f       	subi	r22, 0xFF	; 255
    7140:	7f 4f       	sbci	r23, 0xFF	; 255
    7142:	c6 17       	cp	r28, r22
    7144:	d7 07       	cpc	r29, r23
    7146:	91 f6       	brne	.-92     	; 0x70ec <SNSFlashWrite+0x40>
		boot_spm_busy_wait();       // Wait until the memory is written.

	}
    // Reenable RWW-section again. We need this if we want to jump back
    // to the application after bootloading.
    boot_rww_enable();
    7148:	81 e1       	ldi	r24, 0x11	; 17
    714a:	80 93 57 00 	sts	0x0057, r24	; 0x800057 <__TEXT_REGION_LENGTH__+0x7e0057>
    714e:	e8 95       	spm
    // Re-enable interrupts (if they were ever enabled).
    SREG = sreg;
    7150:	ff be       	out	0x3f, r15	; 63
				: "r0"
		);
	}
	else
	{
		__asm__ __volatile__ (
    7152:	9d e0       	ldi	r25, 0x0D	; 13
    7154:	88 e1       	ldi	r24, 0x18	; 24
    7156:	0f b6       	in	r0, 0x3f	; 63
    7158:	f8 94       	cli
    715a:	a8 95       	wdr
    715c:	80 93 60 00 	sts	0x0060, r24	; 0x800060 <__TEXT_REGION_LENGTH__+0x7e0060>
    7160:	0f be       	out	0x3f, r0	; 63
    7162:	90 93 60 00 	sts	0x0060, r25	; 0x800060 <__TEXT_REGION_LENGTH__+0x7e0060>
	wdt_enable(WDTO_500MS);
	__asm__ volatile("RET");
    7166:	08 95       	ret

 

 

and I think yes the functions is   reentrant since i am not using any global variables 

 

 

 

 

Last Edited: Thu. Dec 27, 2018 - 01:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVATAR_Freaks wrote:
this is the LSS for the bootloader function
Gosh, WHY ON EARTH do you still use  __attribute__ ((naked))???

 

No wonder strange things happen in the application when your SNSFlashWrite function clobbers several registers.

Stefan Ernst

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

sternst wrote:

 Gosh, WHY ON EARTH do you still use  __attribute__ ((naked))???

 

See If I removed the naked attribute, and call the function single time or several times, the code stuck at the function and never executes the next command line and to fix that i have to put a manual jump to the next line location (__asm__ volatile(".org 0x60B2");

 

with the naked attribute I don't need that. 

I think the reason it works because with the naked, that i have "__asm__ volatile("RET") and when it is not naked then it seems like the compiler skip it...

 

My understanind that naked tell the compiler this considered to be assembly 

 

 

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

AVATAR_Freaks wrote:
See If I removed the naked attribute, and call the function single time or several times, the code stuck at the function and never executes the next command line
It's actually the other way round. Your "function does not return" problem is CAUSED by the naked attribute.

Stefan Ernst

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

Interesting, I was describing what I was saying, okay i followed what you said i removed the naked and I am using the manual jumo /(.org) , but when that didn't fix the main issue that when i put my bootloader function inside the loop it only excutes once ?

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

AVATAR_Freaks wrote:
okay i followed what you said i removed the naked and I am using the manual jumo /(.org)
Where did I say that you should use this .org nonsense?

 

Write the function in a normal way. No naked, no .org, no manual ret/jump, nothing. The only "abnormal" thing you may need to do is to prevent the function from being removed due to optimisation.

Stefan Ernst

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

YES, You are right ! that was my issue , the "Attribute (Naked) " screwed me over plus the __asm__ volatile("RET"); 

 

It is better now, but the problem now is when  naked is removed for some reason   my boot loader bigger in size without adding any extra code !??

 

==

Last Edited: Thu. Dec 27, 2018 - 07:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sternst wrote:
 prevent the function from being removed due to optimisation. Stefan Ernst

 

How can i do that part, at the moment I'm having it at the __attribute__((section(".vectors"))); but I don't want to keep it that way 

 

is there is a way to turn optimisation for a single function , ot it has to be for the whole project 

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

Hello again, 

SO I am almost done with this project ! but I still have a question?

 How can i define a variable to br saved in the eeprom from the boatloader?

i have the following variable, which i would like to save it to the EEPROM ?

const u8 STRING_SERIALNUMBER[10] PROGMEM = USB_SerialNumber;

I tried EEMEM

but no luck

Last Edited: Thu. Jan 3, 2019 - 05:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it already in PROGMEM, why do you also need to save it to EEPROM???

 

Jim

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

I want to be able to update the serial number in the fly. without need to recompile

SO it is not in the promem it is only in the memm

i am using this now 

const u8 STRING_SERIALNUMBER[10] EEMEM = USB_SerialNumber;

but this thing is when i look at the serial number of the device it rgives an error

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

It will be the wrong value UNTIL you program the EEP file.

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

I write the eep file, but the serial number under device properties is giving an error

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

Okay It was my mistake, I was reading from the wrong location !

 

Thanks

 

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

How could you get the location wrong? It's &STRING_SERIALNUMBER. You need never know the actual address as the linker handles that for you.

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

You totally right, I was just doing EEMEM and using pgm_read_byte, so I was writing to the EEPROM and reading from the flash! Dump LOL

 

 

I have another obstacle tho, My serial number, device ID and VID ID, is working however when I upload a sketch it gets overriden by USBCORE.cpp that come with the arduino package , any idea how to disable it ?

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

how can i make 

const u8 STRING_SERIALNUMBER[10] EEMEM = USB_SerialNumber;

saved  at a specific address lets say 0x140 ;

 

without changing the linker 

 

the reason I am asking for that, is I have the 0x00 location reserved for something else.

 

i can be asking that question in another way, how can I reserve the 0x00 location in the EEPROM ?

 

Last Edited: Wed. Jan 9, 2019 - 03:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVATAR_Freaks wrote:
how can i make 
By NOT putting it in "EEMEM" but into some other named data section. In effect all EEMEM really achieves s the same as:

 

__attribute__((section(".eeprom")))

 

(perhaps also applying other attributes such as "used").

 

Later on the stuff in the linker script effectively has the same effect as if:

 

-Wl,secton-start=.eeprom=0x810000 

 

had been used. So if you wanted something at 0x140 in EEPROM then just assign the data to a section such as ".myee" and then later section-start this to 0x810140. To create the EEP file at present there is then an objcopy command that changes the 0x810000 base address to be 0x000000 so you'd want to modify that to also include .myee

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

I actually seen your answwer for another post and I just  used

 

.eeprom = 0x00144 under tool chain 

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

I guess that would work but watch for the avr-objcopy that creates the EEP - I think it has a fixed 810000 in it.

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

Yes it works!! 

 

 

Remember previously I was able to expand the bootloader by another 2k so now my bootloader starts from 0x6800 instead of 0x7000 (atmega32u4)

 

the part starting from 0x7000 is write protected when uploading application alone. now How I can make the rest (from 0x6800 to ox7000)   write protected ?

the reason is, when I upload the application by it self I don't have to worry about that extra 2k to be overwritten or deleted 

 

is there away ?

 

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

Just validity check the addresses you are about to write to and just make sure it never exceeds 6800

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

how can i do that ?

in the avr level or the bootloader level 

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

Just in the bootloader code. Ultimately you must have a kind of:

void do_write_page(uint16_t addr, uint8_t * page_data) {
    // write SPM_PAGESIZE bytes from page_data to "addr"
}

so you just say:

void do_write_page(uint16_t addr, uint8_t * page_data) {
    if (addr > 0x6800) {
        return;
    }
    // write SPM_PAGESIZE bytes from page_data to "addr"
}

You may want to then make this a bool rather than a void return and return some kind of success/failure code. Then later layers will handle the occasion it returns false. (flashing LEDs etc).

 

EDIT: OK that should either be ">= 0x6800" or "> 0x67FF"

Last Edited: Thu. Jan 10, 2019 - 01:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't mean whan i am writting from application to flash memory. I mean when I am burning the App.hex

Is there away to tell avrdude to burn to a specific location ?

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

What gets burned is based purely on the addresses in the hex. But why would you be programming the APP using ISP? Surely the very point of using a bootloader is that IT will then do all the app flashing?

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

PS the very first (and only) time you flash the AVR you might want to put both bootloader and first version of the app in together but you'd do that by combining app.hex and boot.hex as one then program the combined image. If you use a sensible tool like Srecord to combine it will hopefully warn of any overlap.

 

EDIT: yup the SRecord manual contains this:

It is common to want to “join” two hex files together, without any changes of address. on the assumption neither file intersects with the other. This is a simple “layers”, it is quite common for linkers to output the main code, and then a whole bunch of relocation and jump destination, by writing a two layered files.

     srec_cat one.he two.hex −o three.hex

Almost always you see an error

     srec_cat: two.srec: 49282: contradictory 0x00000000 value (previous = 0x00, this one = 0x80)

So, yes, it will give an error by default if sections overlap with different data values.

Last Edited: Thu. Jan 10, 2019 - 02:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see your point, but i think i didn't say all the information.

SO the 1st time we are flashing the device we are writting a combined version of bootloader.hex and app.hex through the ISP.

 

then the IT don't use ISP they use the USB connection and the bootloader that already exist to update the app.hex 

with the help of avrdude to write we use the following command while pushing the rest button to start burning  

 

 avrdude -C avrdude.conf  -v -p atmega32u4 -c avr109  -P COM40 -b 57600 -U flash:w:"app.hex":i 

so what you explained previously is exactly what I'm doing, but the obstacle is that It erases the extra 2K i was talking about previously . 

 

I'm Using a modified version of the Caterina Bootloader

 

Last Edited: Thu. Jan 10, 2019 - 03:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It erases the extra 2K

What is the "It" that "erases"? As that it talking to "-c avr109" which is presumably your bootloader? Then surely any erasing being done is as a result of a command passed in the avr109 protocol? In fact it must be this:

 

 

So your own bootloader is being "too aggressive" when it receives a "e" command in the protocol. It should just do writes of 0xFF pages from 0x0000 to 0x67FF and not attempt to perform a full "chip erase" beyond that in any way.

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

Yes You totally right, It was erasing to 7000 i changed it to be  0x67FF. in the "e" command .

 

now the problem if i try to uplaod the application.hex by it self i get the following error 

 

Writing | avrdude: butterfly_recv(): programmer is not responding
avrdude: error: programmer did not respond to command: set addr

 

i gues at the command 'A'

 

I dont think it is related 

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

Well on the avrdude side you can add four -v so it gets very verbose about the 109 commands it is sending then on the AVR side you can breakpoint and track the execution of each command byte that arrives so none of this should be a mystery.

Pages