Post Go back to editing

Help on ADSP-21489 firmware update via RS-232


We are looking for some assistance with adding the ability to update our

ADSP-21489 firmware via RS-232. The fundamentals of what we want to do is

discussed in Application Note EE-345, and we have played around with this a

little bit, but never got it to work completely. We can continue to puzzle

through this ourselves, but we'd rather find a consultant who can help add

this ability into our existing software and we'll be happy to pay someone to

help in this regard.

If you have experience in this area and have some extra time on your hands,

and want to earn some extra money in your pocket, please contact me.

(Ideally the forum has some private messaging system, otherwise you could

leave an email address. Let me know your thoughts...)

Thank you,


  • HI,

    Thanks for providing the project. I've taken a look, and can see a problem - one which I also hit when porting it in VisualDSP++:

    The Second Stage Loader is loaded into Internal Memory on the processor, and is executed from that location. It then reads the LDR image (in your case from a buffer that is part of the Second Stage Loader) and processes it, block by block, using DMA to copy the contents into internal memory.

    The ever present danger here - and something you are definitely hitting - is: What if the LDR file being booted occupies the same space as the Second Stage Loader? In this event, the Second Stage Loader will start overwriting itself when it configures DMA to copy from the source (LDR) to the destination (internal memory).

    For example, if I build your attached project with the option "Generate Symbol map" enabled in the Linker Options, I can see that your binary Loader File is stored at address 0xb2022. Examining the contents of your LDR file, which will be processed by the Second Stage Loader, Block 18 contains INIT_L32 data that is to be copied to address 0xb2022 - at this stage your Second Stage Loader starts overwriting the very boot stream it is trying to copy from - there are almost certainly other sections in your LDR file that are overwriting other sections of the Second Stage Loader - probably sections that are overwriting the code, which is a more serious event.

    As a first step I would try forcing your LDR file into SDRAM, and ensuring that the LDF for your Firmware project avoids using that section of SDRAM for any purpose, then try again.

    I personally found it very useful to place a breakpoint in "READ_BOOT_INFO:" just at the first "IF EQ..." instruction. Keep running to this point, examining the contents of the R0, R2, R3 registers to make sure their contents makes sense. Your second stage loader is likely much larger than the default 256-instruction (1536byte) boot kernel that is automatically overwritten by the self-modifying loop at the end of the second stage loader ("final_init:"), so you may have to take extra measures to avoid any memory used by the SSL in your Firmware LDR by modifying the LDF to make certain memory ranges off-limits for your application.



  • Any solution to this issue ?? i am facing the exact same problem. I have the 214xx_hdr.asm file added into the source folder. This assembly code has both  _lib_RSTI and _lib_final_init_loop but those are not seen by CCES. 

    Kindly help solving this matter

Reply Children
No Data