Loader communication buffer too small

Comments

16 comments

  • Avatar
    Paul Curtis

    This usually indicates that the part ID of the LPC has changed and it can't be auto-identified from the set of part IDs programed into the loader.  Make sure you have the latest LPC200 CPU package installed.

     

    You can test this theory out by loading up the loader project and stepping through it and see if the LPC2k is identified correctly.  You'll need to set Generate debug Information to Yes.

    0
    Comment actions Permalink
  • Avatar
    Jon Elliott

    The error message typically indicates that you are using an old version of the FLASH loader. Earlier versions of the FLASH loader displayed this error message when it was run on an LPC2000 part that returned a part ID that it didn't know about (which you might get if you are using a newer revision of a part).

    Make sure you have the latest LPC2000 CPU support package installed. If you are using your own loader or a loader not supplied with the LPC2000 CPU support package you may also need to rebuild it in order to link in the latest version of the libarm library contained in the LPC2000 CPU support package.

    0
    Comment actions Permalink
  • Avatar
    Mike Page

    Thanks for your replies.

    I am using the latest CPU support package - v1.28. The mask revision is B which has been out for at least a year.

    I rebuilt the loader project with debug enabled and stepped through. Execution is reaching at least to libmem_rpc_loader_start() where it appears to stall at the second SVC instruction (but maybe that wouldn't work in a debugger anyway, it's beyond my area).

    I repeated the process on the old board with the same results.

    0
    Comment actions Permalink
  • Avatar
    Jon Elliott

    Can you run the following code on the part and tell me what value of partID is?

    #include "liblpc2000.h"
    ...
    unsigned long partID;
    liblpc2000_iap_command(IAP_CMD_READ_PART_ID, 0, 0, 0 ,0, &partID);

    0
    Comment actions Permalink
  • Avatar
    Mike Page

    Since I can't JTAG and can't seem to get source stepping in the loader, I included your code early in in my application and ISP'ed it, got:

    partID = 0x1600F902

    This is also what FlashMagic says.

    0
    Comment actions Permalink
  • Avatar
    Jon Elliott

    That part ID has been supported since V1.10 of the LPC2000 CPU support package.

    Can you double check that your project is using the loader you think it is (the loader file is specified by the Target Options > Loader File Path target property)?

    Can you also try one of our example projects to see if it behaves the same?

    BTW, you didn't need to use ISP, you could have selected a RAM configuration in order to download to RAM rather than FLASH.

     

     

     

    0
    Comment actions Permalink
  • Avatar
    Mike Page

    My project file has:

    <configuration Name="Flash" Placement="Flash" arm_target_flash_loader_file_path="$(StudioDir)/targets/Philips_LPC210X/Release/Loader_lpc2300.elf" arm_target_flash_loader_type="LIBMEM RPC Loader" linker_section_placement_file="$(StudioDir)/targets/flash_placement.xml" target_reset_script="FLASHReset()"/>

    Is this correct?

    I couldn't find any example projects - the only samples are plain C files. I am using v1.7 Build 20. I haven't altered my project file and it works fine with the old boards with LPC2368. If you can email me an example project, I'll try it. 

    0
    Comment actions Permalink
  • Avatar
    Paul Curtis

    Example projects are always provided with CrossWorks packages.

    Tools > Show Installed Packages

    Click the link associated with your board or CPU, then you'll find more links to example projects and example CTL projects.

    0
    Comment actions Permalink
  • Avatar
    Jon Elliott

    The loader described in the project file snippet looks OK as it is the default location, but it doesn't necessarily mean the setting hasn't been overwritten elsewhere in the project. Right click on the project in the project explorer, click Properties, make sure the selected configuration in the top left corner is the same as the one you are using and then look for the Target Options > Loader File Path project property. What is the location and modification date of this file?

    Regarding the examples, use the examples from a board support package as close to your target as possible (for example, the Keil MCB2300).

    0
    Comment actions Permalink
  • Avatar
    Mike Page

    The only project file in the list is the loader, which I would have to modify to resemble an application and that defeats the purpose of using a proven example.

    I did find the two *.hzp CTL test files via Windows search but neither resemble project files and neither load into CrossWorks.

    0
    Comment actions Permalink
  • Avatar
    Mike Page

    Paul - see my reply 14:46.

    Jon - confirmed via IDE and visual inspection of HZP the path is as above. I tried the Keil MCB2300, all 6 projects program OK on my LPC2368 board and fail with the same behaviour on my LPC2364 board: the loader programs and verifies via JTAG, then I get the message "Loader communication buffer too small".

     

    0
    Comment actions Permalink
  • Avatar
    Jon Elliott

    Can you let me know what the modification date of the loader file is?

    The next thing to try is to open up the loader project and see what the liblpc2000_get_ram_size function call on line 85 returns.

    0
    Comment actions Permalink
  • Avatar
    Mike Page

    Jon -

    The loader project was modified earlier today to enable debug, as requested. The other files are dated 20 Mar 2009, whereas my download is dated 18 May 2009.

    liblpc2000_get_ram_size() returns 8192. (I make it line 49 whereas 85 is the number of lines in the file.)

    I realized while testing the Keil projects that I was not familiar with selecting a project in a multiple project solution. I was only building the correct project, but still running the first one. So in my my 9:39 post I was actually stepping "Philips LPC2000 2K RAM ... ". But this last test shows the loader would not emit "unknown target device".

    0
    Comment actions Permalink
  • Avatar
    Jon Elliott

    OK, I think I can see what is going on now, the loader communication buffer *is* too small on the new part. Can you try reducing the stack size of the loader to 512 bytes by setting the Stack Size (User/System Mode) project property, rebuilding the loader and trying again?

    0
    Comment actions Permalink
  • Avatar
    Mike Page

    That's it! Many thanks!

    Mike.

    0
    Comment actions Permalink
  • Avatar
    Jon Elliott

    This problem should now be fixed in NXP LPC2000 CPU support package version 1.29.

     

    0
    Comment actions Permalink

Please sign in to leave a comment.