Help on ADSP-21489 firmware update via RS-232

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.

Regards,

Craig.

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.

Regards,

Craig.

so how to solve this problem???

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