I'm downloading a program and I'm getting a "Loader is not a LIBMEM RPC loader" error message. What does this mean?
This error message indicates that loader program has not identified itself correctly as the correct type of loader program.
Possible causes
- JTAG clock frequency too high causing the loader download and/or startup to fail. Try reducing the JTAG clock frequency .
- The loader program being used isn't a a LIBMEM RPC loader program. Check the loader program specified by the Target > Loader File Path project property is a LIBMEM RPC loader. If it is the correct loader, but it isn't a LIBMEM RPC loader change the Target > Loader File Type to the correct type.
- The project that you are downloading is targeting a different device to the one being used.
- The project that you are downloading is targeting a different board to the one being used (for example a board with a different external clock configuration).
If the above doesn't help
Try debugging the loader to see why it is not correctly calling the libmem_rpc_loader_start function. To do this:
- Open the loader solution.
- Put a breakpoint on the line containing the libmem_rpc_loader_start function. Note that you may need to enable debug information and disable optimization in the loader project (using the Build > Include Debug Information and Compiler > Optimization Level project properties) to do this.
- Download and run the program until it hits the breakpoint on the line containing libmem_rpc_loader_start.
- While keeping this breakpoint set (this is important, it allows the debugger to stop on the loader start trap), let the program run again.
The program should stop again in the libmem_rpc_loader_start function with r0 and r1 pointing to the communication buffer and r3 holding the value 0x76E9C416, it is this value in r3 that the host uses to determine that the loader is a LIBMEM RPC loader.
If you get to this point it is likely that the cause of the problem is that you are either specifying the incorrect loader in your application's Target > Loader File Path project property or you are using a different reset script with your application solution. If you don't get to this point then this is the cause of the error message and you need to find out why the program is not getting there.
Comments
9 comments
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.
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
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").
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*.
*
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.
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.
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?
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
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.
Please sign in to leave a comment.