Hi, perhaps I am overseeing a simple solution for my problem:

On the pic32 there are two flash areas, one at 0x9d000000 for the main program and another at 0xbfc00000 that is called Boot Flash. On reset the program starts in the boot flash at the first address.

I have written the startup code for the chips now but I need to distribute some procedures between the two memory areas, for obvious reasons I must have some code at address 0xbfc00000 or the chip will not boot correctly ;-).

My thought was now to tweak the linker script in the same way the original linker scripts of pic32 work:

MEMORY
{
kseg0_program_mem (rx) : ORIGIN = 0x9D000000, LENGTH = 0x80000 kseg1_boot_mem : ORIGIN = 0xBFC00000, LENGTH = 0x490 }

SECTIONS
{
.reset _RESET_ADDR :
{
KEEP(*(.reset))
KEEP(*(.reset.startup))
} > kseg1_boot_mem
}

In assembler I can then simply write:
.section .reset,code and
.section .reset.startup,code

and then the code, this will automagically end up in the kseg1_boot_mem, but this does not work with the inline assembler. Any ideas on how to do this the correct way? Is there something more intelligent than to write a plain assembler file?

TnX,

Michael

PIC32MX FRM - Section 3. Memory Organization PIC32MX FRM - Section 3. Memory Organization

You should be able to use
.section ".reset"

Unfortunately that does not seem to work (or I use it wrong):

This procedure:

procedure _general_exception_handler; assembler; nostackframe; public
name '_GENERAL_EXCEPTION_HANDLER';
asm
   .section "reset"
   sdbbp 0;
   .Lloopb:
    b .Lloopb
end;

translates to:

.section .text.n_pic32mx1xxfxxxc_$$__general_exception_handler .balign 4
.globl PIC32MX1XXFXXXC_$$__GENERAL_EXCEPTION_HANDLER .type PIC32MX1XXFXXXC_$$__GENERAL_EXCEPTION_HANDLER,@function PIC32MX1XXFXXXC_$$__GENERAL_EXCEPTION_HANDLER:
.globl _GENERAL_EXCEPTION_HANDLER
.type _GENERAL_EXCEPTION_HANDLER,@function
_GENERAL_EXCEPTION_HANDLER:
.ent PIC32MX1XXFXXXC_$$__GENERAL_EXCEPTION_HANDLER

.section reset
sdbbp 0
.Lj11:
b .Lj11
jr $ra
nop
.set macro
.set reorder
.end PIC32MX1XXFXXXC_$$__GENERAL_EXCEPTION_HANDLER .Lt3:
.Le2:
.size PIC32MX1XXFXXXC_$$__GENERAL_EXCEPTION_HANDLER, .Le2 - PIC32MX1XXFXXXC_$$__GENERAL_EXCEPTION_HANDLER
.Ll8:

which creates an assembler error:

/Users/ring/devel/fpc/rtl/units/mipsel-embedded/pic32mx1xxfxxxc.s:94: Error: operation combines symbols in different segments

the error is from the .size line.

Try

procedure _general_exception_handler; assembler; nostackframe; public name '_GENERAL_EXCEPTION_HANDLER';
asm
.section "reset"

   sdbbp 0;
   .Lloopb:
    b .Lloopb
   .text

end;

This version worked,

thank you for your help!

Michael

I had some time this weekend (while beeing grilled by the sun on my balcony) to work on another thing that did not work correct and that I did not understand (Now I do, I least I hope ;-)

As said before in this thread, I wanted to distribute Code in two different memory areas because this needs to be done so that pic32 startup code works correctly.

But when I linked my binary the elf-file had always a startup address somewhere in the wrong memory area.

This is what I tried:

procedure reset; assembler; nostackframe; public name'_reset'; asm
.section ".reset,\"ax\",@progbits"
la $k0, _startup
jr $k0 //Jump to startup code nop
.text
end;

but this does not what I expected. I thought that the code would go to the segment I assigned to .reset in the linker script (that worked) and I also thought that the symbol _reset would point to this location

... which did not happen ...

the symbol _reset will get defined somewhere in the .text segment even though the code resides in another segment (please see the generated assembler listing created by inline asm later in this mail). All in all that makes perfect sense, the compiler is doing exactly what I wrote but not what I wanted ;-) ;-)

So I created a 'real' assembler file for the startup code, there i wrote:

.section .reset,"ax",@progbits
.set noreorder
.ent _reset
_reset:
la $k0, _startup
jr $k0 # Jump to startup code nop

.end _reset
.globl _reset

this worked perfect, now the linker uses the address of the _reset procedure in the correct memory area as the startup address.

So is there a way I can get this behaviour in inline assembler?

Something like:

procedure reset; assembler; nostackframe; public name '_reset'; section
'.reset,"ax",@progbits';

???

TnX,

Michael

---- generated assemblerfile:

.section .text.n_pic32mx1xxfxxxb_$$_reset
.balign 4
.globl PIC32MX1XXFXXXB_$$_RESET
.type PIC32MX1XXFXXXB_$$_RESET,@function
PIC32MX1XXFXXXB_$$_RESET:
.globl _reset
.type _reset,@function
_reset:
.ent PIC32MX1XXFXXXB_$$_RESET

.section .reset,"ax",@progbits
la $k0, _startup
jr $k0
nop

.section .text.n_pic32mx1xxfxxxb_$$_reset
# path: mipsel/
# file: pic32mx_start.inc
# indx: 2
.Ll3:
jr $ra
nop
.set macro
.set reorder
.end PIC32MX1XXFXXXB_$$_RESET
.Lt2:
.Le1:
.size PIC32MX1XXFXXXB_$$_RESET, .Le1 - PIC32MX1XXFXXXB_$$_RESET .Ll4:

16.06.2013 23:39, Michael Ring пишет:

In general, the custom section support in compiler needs a lot of improvement...

Try the following, maybe it could work:

procedure anyname; assembler; nostackframe;
asm
.section ".reset,\"ax\",@progbits"
.globl _reset
_reset: // <-- correct name here la $k0, _startup
jr $k0
nop
.text
end;

Regards,
Sergei

I agree that it needs some work. Having a way to specify the section with a procedure directive would largely be preferable I think. Such a directive could also be interesting for variables and typed constants

Also, I think
.section ".reset"
should work just fine in most cases

Maybe the section keyword that was introduced for embedded systems for variables (see compiler/pdecvar.pas unit, look for _SECTION and try_consume_sectiondirective) should be extended to function/procedure header parsing.

procedure reset; assembler; nostackframe; public name'_reset'; section '.reset,"ax",@progbits';
would then do all you want.

Pierre Muller

pdecsub.pas looks like the place to look for, there I also found the declarations for the other keywords that work with procedures/functions. I am still not understanding enough of the inner workings of the compiler so if anybody feels the urge to implement this please go ahead ;-) , for me this would be something for the longterm to try to do it myself, first I would like to get support for pic32mx done, this burns more under my fingernails and I am still not atb the end of the learning curve there.

Michael