Where is the Default Linker Script

Go To Last Post
150 posts / 0 new

Pages

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

As long as the contents as well as the name are .bin (ie binary) then that should be fine. For "xxd" go to the download site for "vim for windows" and get one of the .zip files. The xxd.exe is just separate within the .zip file. Use in the form:

xxd -i file.bin file.c

It will create a C source file that is the binary contents as a C array.

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

clawson wrote:
4) add that to your app project but use __attribute__((section(".boot"))) or similar to assign the array in boot.c to some named section

this part is troubling me 

 

should I do it this way 

 unsigned char SNSBootloader_bin[] = {
  0x84, 0xe0, 0x80, 0x93, 0xe9, 0x00, 0x80, 0x91, 0xe8, 0x00, 0x85, 0xfd,
  0x0d, 0xc0, 0x80, 0x91, 0xe8, 0x00, 0x8b, 0x77, 0x80, 0x93, 0xe8, 0x00}  __attribute__((section(".boot"))) ;
  

or is that wrong ?

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

I normally put the __attribute__ bit up at the front but I don't think it matters - the result should be the same. Basically "SNSBooltLoader" should be assigned to section .boot then later on a -section-start=.boot=0x7C00 (or whatever it is) will place that "data" (which is really program code) at the right place to execute as the bootloader.

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

It actually makes difference, it has to be in the front

volatile unsigned char  __attribute__ ((section (".boot"))) SNSBootloader_bin[] = {
  0x84, 0xe0, 0x80, 0x93, 0xe9, 0x00, 0x80, 0x91, 0xe8, 0x00, 0x85, 0xfd}

but now i am using the atmel studio 

i am trying to add the 

 

-Wl,-section-start=.boot=0x7648

but then it isnot working, it should go under memory settings right ?

 

 

 

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

Wrong.

 

If you use "memory settings" you only enter:

.boot=0x1234

AS7 will dress that up with all the -Wl,-section-start= stuff that is also required. Note also in this is example it would take 0x1234 and treat it as a word address. So it would then double it then finally pass -Wl,-section-start=.boot=0x2468 so (as those lengthy comments in the dialog say) you need to specify the word address here - that is the byte address you really want divided by 2. So if you really want byte address 0x7C00 then put 0x3E00 etc.

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

It didn't work unfortunately, it didnt write anything to that location 

 

how about using the "Additional Modules ) under  the advanced option  

 

I tried that but it didn't work , 

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

AVATAR_Freaks wrote:
It didn't work unfortunately, it didnt write anything to that location 
Almost certainly because of -fdata-sections and -gc-sections. The gc-sections will garbage collect (discard) any data (or code) sections that apparently have no access made. So just turn off -gc-sections for now.

 

Atmel's documentation for AS7 is a bit rubbish. I'm not sure "additional modules" is actually explained anywhere - so it's anyone's guess how that might be used.

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

I tried a google for "atmel studio additional modules" hoping it would hit the right page in the manual if there were some words. It didn't.

 

But the top hit was this: https://www.avrfreaks.net/forum/... which seems to question whether it works,

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

clawson wrote:
top hit was this: https://www.avrfreaks.net/forum/... which seems to question whether it works,

Yes i came a cross this post and it looks like it is not a very effective solution 

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

clawson wrote:
just turn off -gc-sections for now.

 

what section is that agian ? how i can turn it off 

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

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

oh  I see , I turned off. and it write the data to the location but ... it doesn't stop for debugging ?

which was the same problem I am having when i use"  manage by script"

 

now  can't debug 

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

Not sure I follow. What "does not stop" ?

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

sorry, so the main goal is to debug the code right. so I am using the ATMEL ICE & JTAG. When I hit Start Debugging and break , the code compiles and start running but it doesn't break at the 1st line like it suppose to. 

usually it compiles, build ,run then breaks at the 1st line so i can debug step by step.

 

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

Do you think " srec_cat " can be used ?

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

Tbe point is that ELF (not hex) is the format that holds both the binary and the symbol links. So just creating a HEX only gets you binary. You need an ELF with all the binary in it (and the app symbols). That is the goal here. What if you put a break on the first line of main()?

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

yes , correct this is the goal. It doesn't allow me to 

 

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

You set the breakpoint BEFORE you start debugging (or you have to break to set one)

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

Yes that is what i did. I actually set the break point before running the program. but it still doesn't want to set it 

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

How about this method , 

 

https://www.nongnu.org/avr-libc/...

 

i am trying to use it and i successfully created the .o file but i am not sure how to link it to my application 

 

 

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

Okay so  I used this method

 

https://community.nxp.com/thread...

 

and it looks like itis working partially. 

I can see that the app hex file has both the booloader and theapp, and it is located at the correct Memory location.

However I can't step in the code or do step by step debugging ..

What is wrong ?>

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

Zip and post your project.

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

here you go attached is the zipped file

the SNSBootloader.bin --> contains the Bootloader 

 

the application is simple, all what it does is to flash the LEDS

 

the used Mod_Avr5.xn Script is the one in the debug folder 

Attachment(s): 

Last Edited: Fri. Nov 16, 2018 - 03:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, back at you. I modified the project. As I don't have a 32U4 and because the simulator does not support that chip I changed it to mega324P

 

I removed the reference to your modified linker script and instead did the add of the bootloader code as I originally intended.

 

It builds and I see:

 

So that has the app and the boot code in the right places. When I do start/break in the simulator that works too.

 

EDIT: this works better if I remember the attachment...

Attachment(s): 

Last Edited: Fri. Nov 16, 2018 - 03:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVATAR_Freaks wrote:
However I can't step in the code or do step by step debugging ..

When you examine the "mixed view" or the LSS, has the compiler optimized/moved the code around?  Put a breakpoint in the routine itself.  "Start debuggiing and break" and put a breakpoint there.  Step from there; "step over" to start.  then Step into"?  each stop should be able to do a breakpoint.

Add a spurious reference to a volatile variable, before and after the code of interest.

 

And perhaps the most straightforward:  What does the message say?  Is your app code running?  "the selected device can't set a breakpoint when it is running" or similar...

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

clawson wrote:

OK, back at you. I modified the project. As I don't have a 32U4 and because the simulator does not support that chip I changed it to mega324P

 

 

thanks a lot.. When I download your version it did work as you descried it. But when I switch to atmega32u4 and use the ATMEL ICE debugger .. it doesn't break for debugging as before.

 

I am not sure is it the MEGA32u4 or the ICE debugger ?

 

 

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

And if you forget all this "embedded binary" stuff and just build then try to debug just an LED flasher that does work?

 

I can't see how just placing a block of binary in the load image would upset the cart. Sadly I don't have a 32U4 to try this (assuming it's specific to that)

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

yes it will work , no problem 

i don' think that binary bolock is the issue tho... I tied the other method with the atmega324p simulator and it works.

 

Unfortunately there is no simulator for the atmega32u4.

 

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

I think i will debug  my application and my bootloader  on the simulator using atmega324p

and it should give me a good idea if it is working or no..

 

how should i call a function in the bootloader from the application again 

 

typedef void (*do_spm_t)(uint16_t address);



const do_spm_t do_spm_N = (do_spm_t)(0x7256);

is that right ?

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

so I called the do_spm_N from the application and used the step by step for debugging. However the memory location didn't change?

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

AVATAR_Freaks wrote:
However the memory location didn't change?
Haven't a clue what that means. What memory location didn't change? And what were you expecting it to change to anyway? Are you talking about the Program Counter? If you switch to the mixed C+Asm view (ie "Goto disassembly" on the right click menu) then as you approach:

do_spm_N(0x1234);

Then in the code I'd expect to see something like:

LDI R25, 0x12
LDI R24, 0x34
LDI R31, 0x72
LDI R30, 0x56
ICALL

An "ICALL" is just like CALL but it loads Z (R31:R30) into PC as the destination address (and I think it' may be half of 0x7256 so perhaps 0x392B in fact?)

 

If that's what you are talking about then what value is in Z as it gets to the ICALL and where does it go to next as it performs the ICALL?

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

I meant the memory content doesn't change and the the programmer counter doesn't go to the location of the do_spm_N(). 

so 

when i call do_spm_N(0x1300); that what hapens

0000006F  LDI R22,0x00		Load immediate 
00000070  LDI R23,0x13		Load immediate 

00000071  LDI R24,0x00		Load immediate 
00000072  LDI R25,0x00		Load immediate 
00000073  CALL 0x00000081		Call subroutine 
.......
.
.
.
.

00000081  RJMP PC-0x000C		Relative jump 

but i was expecting that the program counter go to the location of the do_spm_N which is at 0x7000 to call the function and write the information to the memory location 0x1300 ?!? 

 

 

 

 

 

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

Show the source that produced that - it should be an ICALL not a CALL - it can't CALL as the destination address is a run time variable.

 

(I don't know what's at address 0x0081 but it sounds like it might be in the middle of the vector table or perhaps in the early CRT stuff).

 

If you do something like

typedef void (*do_spm_t)(uint16_t address);

do_spm_t do_spm_N = (do_spm_t)(0x7256);

...

do_spm_N(0x1234);

then, like I say, I'd expect an ICALL. It's true that because you added const the compiler then knows it cannot change and 0x7256 is fixed so maybe that's why it could use CALL nit ICALL but how it converted 0x7256 into 0x0081 is a complete mystery.

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

I think the problem is, I was defining the function location "const do_spm_t do_spm_N = (do_spm_t)(0x7000); "on a source file not the main(). But I think it must be done in the main(), something like that-which works :-

int main(void)
{
    /* Replace with your application code */
	
	const do_spm_t do_spm_N = (do_spm_t)(0x7000);
		uint32_t page_w ;

	    ioinit(); //Setup IO pins and defaults
		page_w =0x1300;

		do_spm_N(page_w);

	
    while (1) 
    {
		//L_LED_ON();
		TX_LED_ON();
		RX_LED_ON();
		delay_ms(1000);
		
		
		
		//L_LED_OFF();
	    TX_LED_OFF();
		RX_LED_OFF();
		delay_ms(1000);
		
		
		
    }
	 return(0);
}

Doing this way  the C+Assembly will show the correct address (r31 ,r30) =0x7000; and it uses ICALl:-

		do_spm_N(page_w);
0000006F  LDI R24,0x00		Load immediate 
00000070  LDI R25,0x13		Load immediate 
--- C:\Users\bghobreal\Documents\Atmel Studio\7.0\test_5\test\Debug/.././main.c 
00000071  LDI R30,0x00		Load immediate 
00000072  LDI R31,0x70		Load immediate 
00000073  ICALL 		Indirect call to (Z)

when reaches to the ICALL --> it jumps to 003000 which is nothing there , why ?  I excpect it goes to 0x7000 or is it thinking in words? 

it goes to 
00003000  NOP 		Undefined 
00003001  NOP 		Undefined 
--- No source file -------------------------------------------------------------
00003002  NOP 		Undefined 
00003003  NOP 		Undefined 
00003004  NOP 		Undefined 
00003005  NOP 		Undefined 
00003006  NOP 		Undefined 
00003007  NOP 		Undefined 
00003008  NOP 		Undefined 
00003009  NOP 		Undefined 
0000300A  NOP 		Undefined 
0000300B  NOP 		Undefined 
0000300C  NOP 		Undefined 
0000300D  NOP 		Undefined 
0000300E  NOP 		Undefined 
0000300F  NOP 		Undefined 
00003010  NOP 		Undefined 
00003011  NOP 		Undefined 
00003012  NOP 		Undefined 
00003013  NOP 		Undefined 
00003014  NOP 		Undefined 
00003015  NOP 		Undefined 
00003016  NOP 		Undefined 
00003017  NOP 		Undefined 
00003018  NOP 		Undefined 
00003019  NOP 		Undefined 
0000301A  NOP 		Undefined 
0000301B  NOP 		Undefined 
0000301C  NOP 		Undefined 
0000301D  NOP 		Undefined 
0000301E  NOP 		Undefined 
0000301F  NOP 		Undefined 
--- No source file -------------------------------------------------------------
00003020  NOP 		Undefined 
00003021  NOP 		Undefined 
00003022  NOP 		Undefined 
00003023  NOP 		Undefined 
00003024  NOP 		Undefined 
00003025  NOP 		Undefined 
00003026  NOP 		Undefined 
00003027  NOP 		Undefined 
00003028  NOP 		Undefined 
00003029  NOP 		Undefined 
0000302A  NOP 		Undefined 
0000302B  NOP 		Undefined 
0000302C  NOP 		Undefined 
0000302D  NOP 		Undefined 
0000302E  NOP 		Undefined 
0000302F  NOP 		Undefined 
00003030  NOP 		Undefined 
00003031  NOP 		Undefined 
00003032  NOP 		Undefined 
00003033  NOP 		Undefined 
00003034  NOP 		Undefined 
00003035  NOP 		Undefined 
00003036  NOP 		Undefined 
00003037  NOP 		Undefined 
00003038  NOP 		Undefined 
00003039  NOP 		Undefined 
0000303A  NOP 		Undefined 
0000303B  NOP 		Undefined 
0000303C  NOP 		Undefined 
0000303D  NOP 		Undefined 
--- No source file -------------------------------------------------------------
0000303E  NOP 		Undefined 
0000303F  NOP 		Undefined 
00003040  NOP 		Undefined 
00003041  NOP 		Undefined 
00003042  NOP 		Undefined 
00003043  NOP 		Undefined 
00003044  NOP 		Undefined 
00003045  NOP 		Undefined 
00003046  NOP 		Undefined 
00003047  NOP 		Undefined 
00003048  NOP 		Undefined 
00003049  NOP 		Undefined 
0000304A  NOP 		Undefined 
0000304B  NOP 		Undefined 
0000304C  NOP 		Undefined 
0000304D  NOP 		Undefined 
0000304E  NOP 		Undefined 
0000304F  NOP 		Undefined 
00003050  NOP 		Undefined 
00003051  NOP 		Undefined 
00003052  NOP 		Undefined 
00003053  NOP 		Undefined 
00003054  NOP 		Undefined 
00003055  NOP 		Undefined 
00003056  NOP 		Undefined 
00003057  NOP 		Undefined 
00003058  NOP 		Undefined 
00003059  NOP 		Undefined 
0000305A  NOP 		Undefined 
--- No source file -------------------------------------------------------------
0000305B  NOP 		Undefined 
0000305C  NOP 		Undefined 
0000305D  NOP 		Undefined 
0000305E  NOP 		Undefined 
0000305F  NOP 		Undefined 
00003060  NOP 		Undefined 
00003061  NOP 		Undefined 
00003062  NOP 		Undefined 
00003063  NOP 		Undefined 
00003064  NOP 		Undefined 
00003065  NOP 		Undefined 
00003066  NOP 		Undefined 
00003067  NOP 		Undefined 
00003068  NOP 		Undefined 
00003069  NOP 		Undefined 
0000306A  NOP 		Undefined 
0000306B  NOP 		Undefined 
0000306C  NOP 		Undefined 
0000306D  NOP 		Undefined 
0000306E  NOP 		Undefined 
0000306F  NOP 		Undefined 
00003070  NOP 		Undefined 
00003071  NOP 		Undefined 
00003072  NOP 		Undefined 
00003073  NOP 		Undefined 
00003074  NOP 		Undefined 
00003075  NOP 		Undefined 
00003076  NOP 		Undefined 
00003077  NOP 		Undefined 
--- No source file -------------------------------------------------------------
00003078  NOP 		Undefined 
00003079  NOP 		Undefined 
0000307A  NOP 		Undefined 
0000307B  NOP 		Undefined 
0000307C  NOP 		Undefined 
0000307D  NOP 		Undefined 
0000307E  NOP 		Undefined 
0000307F  NOP 		Undefined 
00003080  NOP 		Undefined 
00003081  NOP 		Undefined 
00003082  NOP 		Undefined 
00003083  NOP 		Undefined 
00003084  NOP 		Undefined 
00003085  NOP 		Undefined 
00003086  NOP 		Undefined 
00003087  NOP 		Undefined 
00003088  NOP 		Undefined 
00003089  NOP 		Undefined 

 

 

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

That terrible disassembler annotates addresses with word values. But 7000 / 2 is 3800 not 3000 - so that's a bit of a mystery.

 

let me try a quick simulator experiment.

 

(BTW I thought the function parameter was a uint16_t yet you prepare a uint32_t to be passed (except that it is then truncated to 16 bit). Try to be consistent. Either the function takes uint32_t or you should pass uint16_t.

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

OK, I get it "0x7000" is the wrong value. It takes it literally for the ICALL which takes a WORD address so this then wraps around. The chip is 4000 bytes long so it passes 4000 and then wraps around to 3000 which is 4000+3000 = 7000. So the code should be:

#include <avr/io.h>

typedef void (*fptr_t)(uint16_t);

fptr_t fn;
 
int main(void) {
	fn = (fptr_t)0x3800; // word address for 7000
	while(1) {
		fn(0x1234);
	}
}

this gets you to:

 

 

which is where you want to be (I don't have boot code loaded)

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

Yes  exactly !! That is what I just figured out! that it needs 0x3800 not 0x7000. SO now it works and write to flash memory, but the thing after writing it it deletes it again , surprisngly !?

I gotta figure out why is that..

But yes you are so right  it should be ( 0x7000>>1) 

 

 

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

the thing is once it calls the do_spm_N and update the memroy location it gets stuck there and it never return to the application location to excute the rest of the code . Any idea what could be wrong ?

 

Last Edited: Mon. Nov 19, 2018 - 03:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVATAR_Freaks wrote:
. Any idea what could be wrong ?
Remember this:

#include <inttypes.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
void boot_program_page (uint32_t page, uint8_t *buf)
{
    uint16_t i;
    uint8_t sreg;
    // Disable interrupts.
    sreg = SREG;
    cli();
    eeprom_busy_wait ();
    boot_page_erase (page);
    boot_spm_busy_wait ();      // Wait until the memory is erased.
    for (i=0; i<SPM_PAGESIZE; i+=2)
    {
        // Set up little-endian word.
        uint16_t w = *buf++;
        w += (*buf++) << 8;
    
        boot_page_fill (page + i, w);
    }
    boot_page_write (page);     // Store buffer in flash page.
    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 ();
    // Re-enable interrupts (if they were ever enabled).
    SREG = sreg;
}

 

Whenever I have had instances of "can't get back" it's because of an omission of that absolutely vital call to boot_rww_enable() at the end there.

 

What happens is it calls into this - it does SPM, the RWW (lower flash) goes "unreadable" (in fact it all just reads as 0xFF) so when the code hits the RET from the ICALL it goes back to flash that apparently all contains 0xFFFF opcodes. Well 0xFFFF acts very like a NOP (actually SBRS R31,7 in fact) so it goes hopping its way through flash until it bumps into something that looks like real AVR code which will be the start of the bootloader at 0x7000

 

So are you doing a boot_rww_enable() at the end of your called SPM sequence?

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

Yes I do  a boot_rww_enabel() at the end but still it doesnt go back 

 

void do_spm_N(uint16_t page) {
    uint8_t sreg;
	uint16_t i;
    // Disable interrupts.
	//volatile uint32_t page = 0x014;
    sreg = SREG;
    cli();
    eeprom_busy_wait ();
	
    boot_page_erase (page);
	
	boot_spm_busy_wait ();      // Wait until the memory is erased.
	for ( i=0;i < 256; i++) {
	  boot_page_fill (page+i , 'a');
	}
    boot_page_write (page);     // Store buffer in flash page.
    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 ();
    // Re-enable interrupts (if they were ever enabled).
    SREG = sreg;
	
}

 

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

Then single step it in the Asm view after the rww enable and through the RET and see exactly where it does get to. (the joy of owning an ICE!)

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

Now I know where is my problem. I called do_spm_N from the application and also called from the main in the booltoader.

so when it executes  the do_spm_N() from the application it return to the do_spm_N() in the bootloader, even though it should retuin to the one in the APP.  SO easy solution right..

Remove the one in the bootloader , because i just can call it from the app..Would you think !!!!!

 

 

I wish was it that easy !!!! The strange thing ... If i called do_spm_N() from the main() in the boot loader, then the do_spm_N() function shows at location 0x7000 where i assigned it too..

But if didn't call it from main then i doesn't  show at that location .... 

what am i missing ?

		 void do_spm_N (uint16_t page)  __attribute__ ((section (".bootloader")));

make file

 

 -Wl,--section-start=.bootloader=0x7000

 

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

I am back with more questions,

 

Why if I don't call my function in main() it dosn't show up in the location I assigned it too, eventhough I have every thing linked correctly ??

 

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

It's because of -ffunction-sections followed by -gc-sections

 

The first puts every function into an individually named memory section and the second tell the linker to keep track of references. Any section that has no reference is "garbage collected" (hence "-gc") which means it is discarded from the load image. It doesn't hurt to leave -function-sections (and -fdata-sections) enabled but if you don't want the stuff discarded then switch off the -gc-sections linker option.

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

oh okay, what if i moved it to  section(.vectors ) the -gcc shouldn't touch it right>?

 

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

.vectors is not a good section to mess with - there's a clue in the name - it's only supposed to contain the interrupt vectors from the CRT

 

As I say just switch off garbage collection at the link stage.

 

Or assign it to your own named section and make sure that has the attribute "used".

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

I tried using the used attribute but still didn't work 

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

how can i switch the -gcc-sections ?

i deleted from the make file but then it gave an error 

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

you know my problem now I dont know why when i jump from the application the SP gets stuck at the bootloader an never come back to the next line 

 

take a look at this 

Attachment(s): 

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

Is thee a way to save the location of the SP and the jump back to it ?

 

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

That question makes no sense. You never jump to the SP value itself you might use an address pushed onto the stack as a return address but that is all.

Pages