Crossworks: "LIBMEM RPC loader has not initialized correctly"

[Henry]

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

[mhoneywill]

I would say that the wrong Flash loader has been selected for the project, I've come across a similar problem on the Luminary Micro uTasker project.

I'm using Rowley V1.7 at the moment, but I would try selecting a different loader for the project. Sometimes this is not defined in the utasker configurations because Mark uses IAR for most of his development.

I'm guessing because I do not have a copy of crossworks V2 here.

I'm assuming you have the correct Rowley support packages loaded for the processors you are using.

1. MAKE A COPY OF THE ROWLEY .HZP FILE so you can always recover what you have done
2. Open the Rowley Project and right click on the project in the project explorer and select properties
3. In properties select the "common" configuration so your changes apply to all configurations FLASH / RAM / DEBUG / RELEASE etc
4. In the properties look under "Target Option" at the "loader file path" and "loader file type" settings to see if they are correct, see what options you have.

Look at the above settings in a demo rowley project that does download and work and ensure you have the same settings selected for the "loader" in the utasker project.

Sorry I can't be more specific, good luck

Martin
 

[Henry]

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

[Henry]

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