Messages

1

NXP^TM LPC2XXX and LPC17XX / How to put a struct at a defined address in FLASH

« on: May 12, 2011, 11:42:18 AM »

Hi All,

I am using the Crossworks project with an LPC2468, which is ok so far.
Now I want to put a structure of 0x20 bytes exactly at 0x7DFE0 in FLASH.
The project makes use of a linker script instead of Rowley`s section placement file.

My question is "How can I place the file at this address using a linker script?"


This is what I did up to now:
Modification of the script file uTaskerLPC23XX.ld
1.  FLASH has been reduced and a memory segment has been added
    MEMORY
    {
    FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x0007C000       
                                                                 /* ... */
    STRUANLAGE (rx) :ORIGIN = 0x0007DFE0, LENGTH = 0x20     
                                                                 /* ... */
    }
2.  The section .struanl has been added
    SECTIONS
    {
                                      /* ..... */   
       __struanl_start__ = 0x7DFE0;
       .struanl __struanl_start__ (NOLOAD) :
       {
         *(.struanl .struanl.* .glue_7t .glue_7 .gnu.linkonce.t.*)

       }
       . = ASSERT(__struanl_start__  >= 0x7DFE0 && (__struanl_start__ + SIZEOF(.struanl)) <= 0x7E000 , "error: .struanl is too large to fit in STRURANLAGE memory segment");
                                    /* ....   */

    }


Linking is done without errors.

The structure I would like to locate at 0x7DFE is in StrukturAnlage.c:
    const STRUANLAGE Anlage = {
   ...
   
    }

In the Project Manager at Section Options I changed the Constant Section Name from .rodata to .struanl.
This should be ok. as I have done that before in a project that used a section placement file.
But I suppose that this modification is useless because a linker script is used.

When I load the progamme into the debugger (Crossworks), Anlage is at address 0, not at 0x7DFE0.

I then added an attribute to the structure
  const STRUANLAGE Anlage __attribute__ ((section(".struanl"))) = {
   ...
  }
but the result is the same, i.e. Anlage is located at address 0.

Can anybody tell me what is wrong?

Henry

2

NXP^TM LPC2XXX and LPC17XX / Re: Accessing external memory

« on: August 04, 2010, 01:57:43 PM »

Hi Mark,

this routine is identical to the one in TFT.c of the Rowley project.
I added
  PCONP |=  PCEMC;
and now the problem is solved.

Thank you very much for your immediate help!

Regards,
Henry

3

NXP^TM LPC2XXX and LPC17XX / Accessing external memory

« on: August 03, 2010, 01:18:33 PM »

Hi,

I am using the Rowley-(LPC2378)-project with the LPC2468-16 OEM board from Embedded Artists.
The problem is that I cannot write to external SDRAM located in the range of 0xA0000000...0xAFFFFFFF.

I have modified the linker script like this, which is similar to a modification for the internal USB RAM, which is ok:

Code: [Select]

MEMORY
{
/*
Some other memory segments here  ....
*/
  EXTERNAL_SDRAM (wx) : ORIGIN = 0xA0000000, LENGTH = 0x02000000  /* für EA-Board hinzugefügt, bss2-Segment am  Dateiende */
}

SECTIONS
{
/*
Some other sections here ....
*/
  __EXTERNAL_SDRAM_segment_start__ = 0xA0000000;              
  __EXTERNAL_SDRAM_segment_end__  =  0xA2000000;
/*----------------------------------------------------------------*/
  __bss2_load_start__ = ALIGN(__EXTERNAL_SDRAM_segment_start__ , 4);
  .bss2 ALIGN(__EXTERNAL_SDRAM_segment_start__ , 4) (NOLOAD) :
  {
    __bss2_start__ = .;
    *(.bss2 .bss2.* .gnu.linkonce.b.*) *(COMMON)
  }
  __bss2_end__ = __bss2_start__ + SIZEOF(.bss2);

  . = ASSERT(__bss2_end__ <= __EXTERNAL_SDRAM_segment_end__ && __bss2_end__ >= (__EXTERNAL_SDRAM_segment_start__) , "error: .bss2 is too large to fit in EXTERNAL_SDRAM memory segment");

}

Are additional considerations required for external memory?

While the structures / buffers are assigned to the correct memory range, it is not possible to write to that memory.
I suppose that the reason for this has something to do with the specific project, because there is another project (ARM, not THUMB mode) which does fine.

Does anybody know how to solve this problem?

Regards,

Henry

4

NXP^TM LPC2XXX and LPC17XX / Re: Crossworks: "LIBMEM RPC loader has not initialized correctly"

« on: March 25, 2010, 02:22:20 PM »

Ok., I have to make a correction.
It is possible to find the source of exception without modifying startup_gnu.s.
See http://www.utasker.com/forum/index.php?topic=535.msg2279#msg2279

Henry

5

NXP^TM LPC2XXX and LPC17XX / Re: Crossworks: "LIBMEM RPC loader has not initialized correctly"

« on: March 25, 2010, 01:39:49 PM »

Thank you very much for your comprehensive reply, Martin.

The reason for that issue was a modification I had made in startup_gnu.s to find out the source of an exception.

The original code was this:
_undef_handler:   
_swi_handler:
_pabort_handler: 
_dabort_handler:   
_fiq_handler:
    .word default_code

With this code it is not possible to find out which exception caused the disruption.
I thought I could modify it like this, thus creating different code for breakpoints:
_undef_handler:      .word undef_code
_swi_handler:          .word swi_code
_pabort_handler:     .word pabort_code
_dabort_handler:     .word dabort_code
_fiq_handler:
    .word default_code

...
undef_code: b .
swi_code:   b .
pabort_code: b .
dabort_code: b .


I still don't know what was wrong with this code, but obviously that caused my problem.
Perhaps somebody can explain it?


Kind regards,
Henry

6

NXP^TM LPC2XXX and LPC17XX / Crossworks: "LIBMEM RPC loader has not initialized correctly"

« on: March 23, 2010, 04:38:53 PM »

Hello,

when I try to load the uTasker project using Crossworks, normally the messages
  "LIBMEM RPC loader has not initialized correctly" or sometimes
  "Loader is not a LIBMEM RPC loader"
show up.

I am using
  CrossStudio 2.0.3,
  Configuration THUMB FLASH DEBUG + some modifications
  OLIMEX ARM-USB-OCD

Sometimes the application can be loaded after the RESET button on the board has been pressed. But normally the only solution is to load a hex-file (created from the same project) with FlashMagic and run it.
After that my application can be loaded once by the Crossworks debugger and so on.

I have another application (configuration ARM RAM DEBUG, not uTasker) that loads over and over again (once I have managed to load it). So I suppose the problem has something to do with my application.

Does anybody know where to start solving this problem?

Regards,
Henry