"Loader is not a LIBMEM RPC loader" error message

Follow

Comments

9 comments

  • Avatar
    Threehc

    I specified the loader for my application, but it always take the default one. Does anybody have any idea on this? Thanks!

    Target > Loader File Path    $(ProjectDir)/loader/Release/LM3S9xxx-Loader.elf

    Target > Loader File Type    LIBMEM RPC Loader

    It always take the loader file that located at $(targets)/LM3S/Release/loader.elf.  I tried to move the default loader file, it will complain cannot open C:\Documents and Settings........\packages\targets\LM3S\Release\Loader.elf*.

    *

     

    1
    Comment actions Permalink
  • Avatar
    Jon Elliott

    Charles,

    Which loader are you actually using? The "read operation timed out" error could well be down to debugging a loader that is a "Comms Channel Loader" rather than a "LIBMEM RPC Loader.

    Best regards,

    Jon

    0
    Comment actions Permalink
  • Avatar
    Charles Harwell

    Good question.  Up to now, I was just using the default loader (when I download it says "loader.elf").  On seeing the message about LIBMEM RPC LOADER, I followed the instructions and noted that my loader type was set to "Comms channel loader"; I changed this to LIBMEM RPC loader.  I searched out the location of the loader.elf (to try debugging as mentioned above); and the only one I found built and loaded but does not run (it produces the message "cannot stop processor").

    0
    Comment actions Permalink
  • Avatar
    Charles Harwell

    Reducing the JTAG clock frequency didn't help.  Made sure the Loader File Path and Loader File Type were set correctly.  Opened up the loader solution, built and downloaded the loader (it loaded ok); when run the debugger the message "Read operation timed out" is displayed. and the debugger does not start.

    0
    Comment actions Permalink
  • Avatar
    Gordon Scott

    Just an FYI. I see this fairly regularly when programming a particular board that is powered via another board on a plug-top PSU.

    I suspect something like ground-bounce upsetting the signals.

    0
    Comment actions Permalink
  • Avatar
    Michael Farnet

    I'm having this problem on a new target.  I can connect the J-Link, but I get the "Not an RPC loader" error.  I've tried every type loader and I deleted the old loader and rebuilt the loader to make sure the correct one is being used.

    I set the clock on the SWD to 10KHz.

    I know my device is active, as I can erase it all and connect the debugger.

    Attached is my problem project.

    0
    Comment actions Permalink
  • Avatar
    Michael Farnet

    I found some help that suggested connecting the debugger and breaking to find out where the code program counter is.  Sure enough, it was 0x1FFFxxxx, executing the ISP bootloader.  According to the user manual, the ISP bootloader executes for two reasons.  1) P2.10 is low when reset pin rises.  2) the user code checksum is false.

    P2.10 is high.  On my micro, the adjacent pin is VCC, so I soldered the two together.  It's high.

    Using the debugger I looked at the vector table.  It doesn't appear that vector 7 contains anything.  How does Crossworks place the checksum in vector 7?

    0
    Comment actions Permalink
  • Avatar
    Jon Elliott

    Michael,

    CrossWorks adds the checksum to the elf file as a post link build step. Presumably the MCU is entering ISP mode because the download failed and there isn't a valid program in flash. Try following the "If the above doesn't help" section at the top of this post to find out why the loader is failing - my guess is that it is a difference with board, i.e. clocks, etc.

    Regards,

    Jon

    0
    Comment actions Permalink
  • Avatar
    Geoff Field

    I've reached the stage where I have confirmed that the loader seems to be running: At the bkpt #0 statement, R0 is 0x200007a8, R1 is 0x2000bfff and R3 is 0x76e9c416.  I assume the R0 and R1 locations are OK: they certainly seem to be in the right ballpark.

    When I try to debug my application, the console shows as far as "Executing script FLASHReset()" and then we get the error.

    Our target processor is an STM32F405VG on a custom board.  We're using Crossworks 2.3.55.2014011021.20385 on a WIndows 7 (64-bit) machine.

    0
    Comment actions Permalink

Please sign in to leave a comment.