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 ?
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
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
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?
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)
Posted by AVATAR_Freaks: Thu. Dec 27, 2018 - 04:52 PM
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
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.
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 ?
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.
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 ?
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
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
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"
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?
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.
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.
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.
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");- Log in or register to post comments
Topvoid do_spm_N (uint16_t page) __attribute__ ((used)) __attribute__ ((naked)) __attribute__((section(".vectors"))); =======================Stefan Ernst
- Log in or register to post comments
Top- Log in or register to post comments
TopDo 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?
- Log in or register to post comments
TopYea 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 !?!?
- Log in or register to post comments
Toptime to read the manual - no point simply guessing
- Log in or register to post comments
TopOkay 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
- Log in or register to post comments
TopWhat 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 ?
- Log in or register to post comments
TopOne approach is to write a cookie as a marker.
- Log in or register to post comments
TopAnother approach is to use __data_load_end.
Stefan Ernst
- Log in or register to post comments
Topyes 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 ?
- Log in or register to post comments
TopThe start of the bootliader is surely at the BOOTSZ address?
- Log in or register to post comments
TopHI , 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 ?
- Log in or register to post comments
TopThis is why God invented ICEs
- Log in or register to post comments
TopYes 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
- Log in or register to post comments
TopYou 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?
- Log in or register to post comments
TopHappy 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 ?
- Log in or register to post comments
TopShow 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)
- Log in or register to post comments
Tophere 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 retand I think yes the functions is reentrant , since i am not using any global variables
- Log in or register to post comments
TopNo wonder strange things happen in the application when your SNSFlashWrite function clobbers several registers.
Stefan Ernst
- Log in or register to post comments
TopSee 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
- Log in or register to post comments
TopStefan Ernst
- Log in or register to post comments
TopInteresting, 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 ?
- Log in or register to post comments
TopWrite 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
- Log in or register to post comments
TopYES, 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 !??
==
- Log in or register to post comments
TopHow 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
- Log in or register to post comments
TopHello 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 ?
I tried EEMEM
but no luck
- Log in or register to post comments
TopIf 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...
- Log in or register to post comments
TopI 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
but this thing is when i look at the serial number of the device it rgives an error
- Log in or register to post comments
TopIt will be the wrong value UNTIL you program the EEP file.
- Log in or register to post comments
TopI write the eep file, but the serial number under device properties is giving an error
- Log in or register to post comments
TopOkay It was my mistake, I was reading from the wrong location !
Thanks
- Log in or register to post comments
TopHow could you get the location wrong? It's &STRING_SERIALNUMBER. You need never know the actual address as the linker handles that for you.
- Log in or register to post comments
TopYou 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 ?
- Log in or register to post comments
Tophow can i make
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 ?
- Log in or register to post comments
Top__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
- Log in or register to post comments
TopI actually seen your answwer for another post and I just used
.eeprom = 0x00144 under tool chain
- Log in or register to post comments
TopI guess that would work but watch for the avr-objcopy that creates the EEP - I think it has a fixed 810000 in it.
- Log in or register to post comments
TopYes 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 ?
- Log in or register to post comments
TopJust validity check the addresses you are about to write to and just make sure it never exceeds 6800
- Log in or register to post comments
Tophow can i do that ?
in the avr level or the bootloader level
- Log in or register to post comments
TopJust 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"
- Log in or register to post comments
TopI 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 ?
- Log in or register to post comments
TopWhat 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?
- Log in or register to post comments
TopPS 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:
So, yes, it will give an error by default if sections overlap with different data values.
- Log in or register to post comments
TopI 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
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
- Log in or register to post comments
TopWhat 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.
- Log in or register to post comments
TopYes 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
i gues at the command 'A'
I dont think it is related
- Log in or register to post comments
TopWell 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.
- Log in or register to post comments
TopPages