I need to preset 4 longWords at a specific memory location in flash of the microcontroller that define the startup behaviour of the chip.

I came up with two solutions, but both more feel like a hack than a proper way to do things, any ideas how to do this better?

a) by hijacking the declaration of a typed array constant in the linker script:

program x;
const
   devcfg : array[0..3] of longWord = (
$12345678,$87654321,$ffffffff,$00000000 );

linker script:

.devcfg :
KEEP(*(.data.n_tc*_devcfg))
} > devcfg

or

b) by creating specialized units (very unflexible)

unit pic32mx8mhzpll;
interface
implementation
procedure dummy;assembler;nostackframe;
asm
.section ".devcfg,\"ax\",@progbits"
.long 0x12345678
.long 0x87654321
.long 0x12345678
.long 0x87654321
.text

   end;

end.

I would simply create a record type and a pointer type to same and then typecast an integer constant (=address) onto the pointer. Now you can access the values by normal dereferencing.

-Michael

Thanks,
but does not solve the problem, it's not about reading the data, it's about defining the data so that it is included in the elf file in the correct section so that the microcontroller is programmed with the values when the elf file is uploaded to the microcontroller.

Michael

23.04.2014 12:34, Michael Ring пишет:

You may specify a name of section to place your data (if this feature is enabled for the target you use -- but it should be enabled for all embedded targets):

const
   FreePascal_TLS_callback : pointer = @Exec_Tls_callback;
     public name '__FPC_tls_callbacks' section '.CRT$XLFPC';

Regards,
Sergei

Hmm.

The said method allows for writing to such data as well. Of course only after some initialization is done.

If I need such stuff during the initialization, I would use ASM.

Anyway, by creating true constants (as you seem to aim for), the data would reside in FLASH, and never be touched by any software.

Certain processors with on-chip flash memory indeed use hardware to read such configuration data before the processor starts, but the only I know of, that might be usable with fpc (and which I in fact am eager to use with fpc) is PIC32 (a MIPS architecture).

-Michael

this code is for PIC32 ;-) , Florian has merged my initial work a few weeks ago and Segger has created a new version of their J-Link probe which supports pic32, so I am currently fine-tuning the code so that Florian can merge the missing parts.

I have already started a page in the FPC-Wiki:

http://wiki.freepascal.org/TARGET_Embedded_Mipsel

Michael

GREAT !!!

Thanks a lot !
-Michael

Michael Ring wrote

this code is for PIC32 ;-)

I did some research on behalf of PIC32.

Here some of my latest results that might be of some interest.

- PIC32 MX uses (cost efficient) "MIPS 4K" Architecture, (40 MHz chips with a single, 80 MHz chips with two register sets)

- PIX32 MZ (200 MHz) uses "MIPS 14K" Architecture which on top of faster processing offers some really nice additional features such as eight register sets, enhanced ability for signal processing (e.g. by four 64 Bit accumulators and SIMD instructions) enhanced hardware support for Interrupts.

- you need to do atomic instructions by "read locked / store conditional" instructions (very similar to modern ARM architectures

Please come back with any questions that I might be able to help with. (We in fact do active development with the PIC32 in C right now.)

-Michael

Some questions that might put us in a working position:

Can you state the cause why xc32 is not usable ?

For our project (from your first message seemingly different form what you are doing) we want to call fpc functions from running C-made code.

Hence
- initialization is no issue at all for us
- we would supposedly need to do the RTL in a way that it cooperates with the standard (Microchips) C - Library functions.E.g. supposedly the rtl memory management would need to call the appropriate C Library functions.
- we did not yet decide if we would want to link the fpc functions statically or load and link them dynamically in some way. (Here compiling to PIC (position independent code :-) ) might be an issue.

Any comments on that ?

Thank,
-Michael

The wiki page speaks of gdb. Does same use PICKit a similar tool to connect to the chip ?

Of course it would be great to be able to use the debugger from withing MPLABX. I suppose MPLABX just calls a gdb executable in a standard way, so this might be possible.

-Michael

Michael Schnell wrote

Some questions that might put us in a working position: Can you state the cause why xc32 is not usable ?

binutils from xc32 is not usable, I could not link correctly when I used th xc32- tools.

Nope, my main focus is to get it running on bare metal, so dynamic linking is of no relevance, I hope that I can statically link Microchip libs to pascal code.

Michael Schnell wrote

The wiki page speaks of gdb. Does same use PICKit a similar tool to connect to the chip ?

If mplabx is you primary development env then you do not need another debugger.

The JLink-Probe is for those like me that do not want to work in a C-Style IDE. So it might be of no relevance at all to you.

Thank you for this tip Sergei, this seems to work just fine!

Michael

OK.

Once we get at this, we will be able to find (and publish) ways to link fpc functions statically and/or dynamically to a C based main program.

-Michael

Michael Ring wrote

> - we did not yet decide if we would want to link the fpc functions > statically or load and link them dynamically in some way. >

For statical linking it would be essential to be able to use the xc32 linker with fpc generated object files.

For dynamical (lading and) linking I suppose that it would be helpful to have fpc generate position independent code.

-Michael