Post Go back to editing

ADSP-21569 Error: couldn't find DPIA buffer address

Category: Software
Product Number: ADSP-21569
Software Version: CCES 2.11.1


I'm working on an own design of ADSP-21569 (nearly identical with the ADSP-21569-SOM). The SPI flash is the same as on the ADZS-21569-EZKIT (IS25LP512M-JLLE).

When I try to program the flash using device programmer in CCES (setup as described here: I get the following error message:

Downloading to device...
'Invoking: CrossCore SHARC Device Programmer'
cldp -proc ADSP-21569 -cmd prog -driver "C:\Analog Devices\ADSP-2156x_EZ-KIT-Rel1.0.1\ADSP-2156x_EZ-KIT\Examples\Device_Programmer\Legacy_SPI\is25lp512m_dpia_2156x\21569\is25lp512m_dpia_21569.dxe" -erase affected -emu ice-1000 -format bin -offset 0x0  -file DSP_Firmware.ldr 
Error: couldn't find DPIA buffer address
Error: 13 - Error in Setup
Error: driver load failed.
Target          Emulation Debug Target
Platform        ADSP-21569 via ICE-1000
Processor       ADSP-21569
Core            0
Driver          C:\Analog Devices\ADSP-2156x_EZ-KIT-Rel1.0.1\ADSP-2156x_EZ-KIT\Examples\Device_Programmer\Legacy_SPI\is25lp512m_dpia_2156x\21569\is25lp512m_dpia_21569.dxe
make: *** [makefile:135: program_device] Error -1
Error during device programming

Related thread to:

Do I need to modify the driver, although I am using the same SPI flash as on the EZ-Kit?

Kind regards,

Edited title
[edited by: MKrautter at 6:40 AM (GMT -4) on 6 Apr 2023]
  • Hi,

    We have seen similar issue (error messages) with DPIA when trying to program board with different FLASH device.

    Although you are using the similar flash device as the EZ-KIT, it may be hooked up or connected differently. Note that the EZ-KIT has external memory available to it, does the custom board have external memory?
    If not and your design of the flash on custom board differs from the EZ-KIT then these differences must be accounted for in the flash programmer application which is loaded to the target.

    We recommend the flash programmer application example provided as part of the tools and make changes to suit your particular hardware configuration.

    Also, we provide documentation for the Device Programmer API, which describes the commands the Flash Programmer Drivers require to perform the Flash accesses.

    This documentation is available at help > CrossCore® Embedded Studio <version> > Integrated Development Environment > Working with Bootable and Non-bootable Files > Device Programmer > Custom Device Drivers

    If you are still facing issue, Could you please try to flash with bmode as Zero if you have in your custom board and let us know how you gets on.

    Please let us know whether you have flash this board before successfully ?Can you please check with "erase all" instead of "erase affected" and check if that works.

    Do you have any other EZ-kit/SOM board, if possible please try in another board and let us know how you gets on.

    Also, could you please try any other emulator to flash your board.

    Please confirm whether you are able to debug board (establish connection to crosscore debugger)successfully in CCES? Also please try to open the flash driver in CCES and try to debug, confirm whether it is getting to the main processing loop.

    /* command processing loop */
    while ( !bExit )
    * the programmer will set a breakpoint at "AFP_BreakReady" so it knows
    * when we are ready for a new command because the processor will halt
    * the jump is used so that the label will be part of the debug
    * information in the driver image otherwise it may be left out
    * since the label is not referenced anywhere
    if ( FALSE )
    asm("jump AFP_BreakReady;");

    /* Make a call to the ProcessCommand */
    AFP_Error = ProcessCommand();

    Awaiting for your reply.


  • Hi,

    I did as you suggested and added debug outputs in the flash driver code. The problem is solved as I found out that our manufacturer of the PCBs assembled the wrong flash chip. As a result the device ID was not correct (same manufacturer but one memory size smaller than desired).

    I corrected the device ID for the actually mounted flash chip and it is working now.

    Thanks for your support.


  • Hi  ,

    I have one further question: how can I evaluate the needed memroy size of SPI flash for my program?
    For example my loader file has a size of 82 kByte. How much overhead is generated? Based on the 82 kB, how much memory size do I need?
    Is there a tool or compiler output to see the general memory usage of a project (RAM, flash etc.)?


  • Hi,

    As you are aware, you need to choose the memory size of SPI flash based upon your application size(ldr file).The size of loader file is actually the size of memory to be programmed in the flash.

    The Loader file does indeed contain additional information. This is covered in the 'File Formats' appendix within the Loader and Utilities Manual. The Loader file will be significantly larger that the actual space required due to the headers for each record.

    There is no automated way to get the sizing information, you would need to extract the size from each record's header within the Loader file.

    You can download the CCES Loader and Utilities Manual from the below link:

    There is no way to determine the exact size that the Loader Image will occupy in flash. You can get a very rough estimate by adding up the "Used Words" columns.

    The quickest way to find out your code size is to generate a Linker Map File which you can do via 'Project->Properties->C/C++ Build->Settings->CrossCore SHARC Linker' and selecting the 'Generate symbol map' checkbox. This will instruct the linker to generate a map file. This will be available in the 'Debug' folder of the project directory. The map file describes how objects and the symbols they define are mapped into the memory defined by the .LDF file. Once generated simply add up the totals from the 'used' column in the map file.

    Map file can be viewed in CCES's internal browser, via Right-clicking on the Proj_name_map.xml in CCES project explorer > open with > Other > internal web browser.

    The differences come from the fact that there are additional overheads (the block headers, etc) in the loader stream that are not taken into account in the section sizes given in the XML file. This can make the space on flash larger than the totals given by adding up the columns. Furthermore, large blocks of zeros may be compressed into a smaller space, which can make the % of flash used smaller than expected. However, this is still a good way to estimate size.