Hi everbody,

I am devoping on a Ashling EVBA7 lpc2106 evaluation board, with the
ashling ide/debugger. I am using FreeRTOS. I have some trouble with
the linker script and the debugger. I have a linker script from
ashling and one from FreeRTOS, but none of them works on the ashling
debugger, if I program in Flash, for flash debugging. When I put the
stuff in RAM, for ram debuggen, the interupts do not work? I think
there is some problem with the memory configuration. Does somebody
know a good resource for linker scripts? Hints & tips are welcome.

I've upload the files to the web:
FreeRTOS stuff:
http://members.home.nl/bart.theeuwes/files/lpc2106-ram.ld
http://members.home.nl/bart.theeuwes/files/lpc2106-rom.ld
http://members.home.nl/bart.theeuwes/files/boot.s

Ashling Stuff (from free examples):
http://members.home.nl/bart.theeuwes/files/arm.ln
http://members.home.nl/bart.theeuwes/files/startup.s

I am not familiar with the Ashling tools. Are you using the GCC compiler?

When executing from RAM the interrupt vectors have to be remapped from ROM into RAM. The FreeRTOS demo does this for you if you define RUN_FROM_RAM.

See the line:

#ifdef RUN_FROM_RAM
/* Remap the interrupt vectors to RAM if we
are running from RAM. */
SCB_MEMMAP = 2;
#endif

in main().

Yes, i am using the RUN_FROM_RAM option when running in RAM and RUN_FROM_ROM option when running to flash. I use the newest GCC compiler, have also tried the GCC compiler delived with ashling; version 3.3.1.

The problem is, I think, that the LD script that is delivered with FreeRTOS isn't configured right for our board (although it is a LPC2106), or, it's wrong configured so you can't use it for the Ashling Debugger. I was hoping you could look to the Ashling Configuration, give me some tips for modify the LD scripts delivered with FreeRTOS.

Some points I noted which may or may not help:

- The Ashling load script seems to define the RAM location in an odd way. Starting at 0x40000400 and length of 64K appears to take it off the end of the true RAM region. The FreeRTOS script starts at 0x40000000 for 64K which covers the entire on chip RAM.

It looks suspicious but maybe there is a good reason for it - something to do with the Ashling tools maybe? You could try changing it to be like the FreeRTOS version - or try changing the FreeRTOS version to be like the Ashling script.

+ The Ashling boot code does not setup a stack for system mode. I don't think this is a problem as when the tasks start executing (in system mode) they have their own stacks anyway - and the default setting is not used. But it is a difference between the two ...

+ The script posted by yourself is only shows a flash boot configuration - but I presume you know this.

Are you just trying a hello world type program that does not include any of the hardware config included in the FreeRTOS download? If not then maybe the hardware config is different and this is causing a problem. Does everything else work other than the interrupts?

+ The script posted by yourself is only shows a flash boot configuration - but I presume you know this.

Yes, I know, with the debugger I should be able to debug in ROM mode, but then I have only 1 breakpoint. Reason for that is, if compile in ram mode, an try to debug it, the interupt doesn't work it all, but if I build it for rom mode, and just flash it, (without any debugger), the serial driver runs great. So that is the reason I want to debug in flash mode. Maybe, you can give me a reason when the interupts happen, the jump to ISR doen't.
Here is the link of the "RAM" version of the ashling linker script.
http://members.home.nl/bart.theeuwes/files/arm_ram.ln

Is this linker script from Ashling directly? There are some things that look odd to me, like the position of the _end marker. Sometimes it is difficult to follow other peoples linker scripts but if Ashling have tested it then it must be ok.

There does not seem to be anything obvious although I would suggest that the memory regions could be defined as:

MEMORY
{
flash: ORIGIN = 0, LENGTH = 120K
ram: ORIGIN = 0x40000000, LENGTH = 64K
}

as per flash linker script. Then change all the ">rom" strings to ">ram" so nothing uses the defined ROM region.

This would allow the entire RAM to be used and allow the linker to know the true memory type (if this makes any difference).

The way the Ashling linker script is set there is 16K set aside for RAM, but there could be a big unused gap between the end of the code and the start of the RAM.

If the program runs ok and it is just the interrupts that are not working then I would guess that the remapping of the vectors is still the most likely candidate. Is it possible using the debugger to force a serial interrupt (set an ISR register flag) and follow the debugger to see where it goes when it tries to service the interrupt?

mmm, uh, i just give you the script to compare. But ok. I have also now a teacher on te case.
But i have a question; The lpc2106 port is build for the Ominex board, but we use an ashling board. Could you configure (the FreeRTOS) lpc2106-ram.ld and lpc2106-rom.ld with the arm.ln (ROM) and arm_ram.ln (RAM) as reference. As our gratefull thanks, we are willing to share our software we are writing, like serial port driver with support for 2 ports, an I2C driver and an SPI driver.

In this case, as all the ROM and RAM are on chip, the linker script should not change between different boards - which is why it is odd that the FreeRTOS one does not work with the Ashling board.

The debugger is different of coarse, so if the script needs to be different at all then it could be that the debugger requires some memory reserved for its own use or something like that.

What I can try doing is getting the Olimex board to work with the Ashling linker script. This may highlight to me some differences between the two.

I will get back to you on this.

Can you send me the boot.o file referenced from the linker script? email on the WEB site contacts page. Thanks.

Ok, some explanation about the files:
Boot.s belongs to LPC2106-RAM.LD & LPC2106-ROM.LD

Startup.s in the first post belongs to the arm.ln also in the first post, build for ROM mode. This one belongs to the arm_ram.ln
http://members.home.nl/bart.theeuwes/files/startup_ram.S

You want the boot.o ? With which configuration should I Build it?

Sorry, mine mistake:

http://members.home.nl/bart.theeuwes/files/boot.o

The boot.o will not link. Is it a file that you build or something that Ashling provide ready built.

If you build it, can you rebuild it using the Ashling linker script and send it again. It seems it was built with the FreeRTOS linker script.

http://members.home.nl/bart.theeuwes/files/startup.o

voila!

I got it to build ok using your startup.s startup.o and linker script. I will not be able to try it on the hardware immediately, but will let you know what I find as soon as I do.

The odd thing is that the linker script references one of the build files - a circular dependency with my setup which I why I required the startup.o file. Your environment must build this first, then link in later.

Hi again…

I have tried your startup and linker files on the Olimex board – building the FreeRTOS demo application to run in ARM mode and execute from RAM. I found that the serial port interrupts worked well, and using GDB I could set break points in the serial ISR with no problem.

I have to make a few changes to get the demo to build with my setup, I have detailed these below in case they provide any clues to your problem.

I think the build seems to be fine. As all the ROM and RAM are on chip the linker script should not change (hardly) between boards so this is probably fine also. This leaves something with either your hardware configuration or something particular with your tools/debugger. As I am not familiar with the Ashling tools I don’t think I can help there.


To compile using my setup I:

1) I modified the RAM_ARM.bat and makefile to use your linker and startup files. RAM_ARM.bat becomes:

“set USE_THUMB_MODE=NO
set DEBUG=-g
set OPTIM=-o0
set RUN_MODE=RUN_FROM_RAM
set LDSCRIPT=arm_ram.ln
make”

Your linker script references the startup obj code, so it does not need linking in in the makefile. Therefore the line CRT0=boot.s was commented out of the makefile.


2) The makefile I have meant that I could not build startup.s as it was used on the same command line as the linker script – which referenced the startup.o file. You therefore supplied a prebuilt version. This resulted in a couple of undefined references from startup.o for the ISR’s startup.o expected to find. To get around this I defined the dummy ISR routines in main as follows:

void do_undefined_instruction( void )
{
while( 1 );
}

void do_prefetch_abort( void )
{
while( 1 );
}

void do_data_abort( void )
{
while( 1 );
}

void do_fiq( void )
{
while( 1 );
}

void initialise_monitor_handles( void )
{
}


Note the last one – “initialise_monitor_handles”. I stubbed this out also. I suspect this is something to do with your debugger.

For the same reason I had to rename the FreeRTOS SWI handler to do_software_interrupt() to give it the name expected by your startup.o.


3) When building now I ran out of RAM as I was building the entire demo application. To get around this I changed the linker file ARM_RAM.ln as follows:

MEMORY
{
rom (rx) : ORIGIN = 0x00000000, LENGTH = 48K
ram (rx) : ORIGIN = 0x40000000, LENGTH = 64K
}

and changed the “> rom”s to “> ram”’s.
The 48K of ROM is irrelevant as nothing uses it.



Built with the RAM_ARM batch file.