Help on ADSP-21489 firmware update via RS-232

Hi Marc,

We simply implemented this logic:

1. Enter update mode

The host sends #u* to the DSP. The host waits for confirm string #u0*. The DSP enters update mode, ignoring other commands unrelated to the process.

2. Erase flash command

The host sends @E* to the DSP. The DSP erases the first a few sectors (for code). Data sectors are not affected. After finished, the DSP returns @u0* if succeed, @u1* if some error occurs, #u2* if operation timeout (10s). So the host can be able to proceed.

3. Send data

The host sends the data line by line from the hex ldr file in the following format:

@:[hex line]*

the DSP proceed the addressing and check sum of the line and if correct, write the data into the addresses. It returns @u0* for succeed, @u1* for fail. The host can re-send the failed line again.

this will be sent line by line until the EOF of the file. And then the DSP exits the update mode.

The user can update again without power cycling, in case he sends a wrong file.

4. Time out

If the DSP did not receive any command or data for longer than a certain time (10s), it will send an warning #u2* and exit the update mode. The host could show error messages and the user can try again.

The best method is loading the whole ldr into memory, check the integrity and then flash it. Or write a loader. Our method is just a simple lazy one for emergency field debugging..

Hope this helps.

Rongxi

Hi Marc,

Regarding “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.”

>> Could you please explain what kind of issue are you facing in using the example codes provided along with Application Note EE-345 for ADSP-21489 processor?

Kindly provide more information regarding this so that we can assist you better with the issue.

Thanks,

Harshit

Hi Harshit,

Actually, we are trying to do this firmware upgrade through UART for serial Flash on the ADSP-21489.

We have made a custom board with the ADSP-21489 and the code is loaded on the Flash M25P16. We have loaded it through the Flash programming to on VisualDSP++.

Now, the goal is to upgrade this flash memory through UART, because there will be a software which communicates with the board and allows to update the firmware if available.

The Application Note EE-345 provides example for ADSP-21469. I saw all the threads concerning migration  to ADSP-21489 but I didn't get a clear example or explanation.

I don't know what to modify to get it work on ADSP-21489. This thread provides an example (http://ez.analog.com/message/59942#59942) but for Parallel upgrade.

This application note has been released on October 2009. Is there any update of this application note that could provide an example for ADSP-21489?

I would really appreciate your help on this,

Best regards,
Marc

Hi Marc,

Sorry for the delay in response.

In order to port the code written for ADSP-21469 processor present in the Application Note, you may have to make the following changes for it to work for ADSP-21489 processor:

1. Make sure that you generate a LDF file corresponding to ADSP-21489 processor.
2. Change your project option to ADSP-21489 processor.
3. You may have to change the PLL initialization code for ADSP-21489 processor.
4. Also replace the DDR2 initialization code for ADSP-21469 processor with SDRAM initialization code for ADSP-21489 processor.

The initialization code for ADSP-21489 processor can be taken from any of the example codes present in the directory below:

…\Program Files (x86)\Analog Devices\VisualDSP 5.0\214xx\Examples\ADSP-21489 EZ-Board

When you try to make all the above changes and build the code, then please let me know what error messages do you encounter, so that we can look into it and assist you to resolve it.

You would  also like to go through following forum threads:

1. http://ez.analog.com/message/9538#9538
2. http://ez.analog.com/message/32256#32256

Please let me know in case of any further queries.

Thanks,

Harshit

I ported the "SSL with GUI" project from EE-345 to work with the ADSP-21489, and tested it on a 21489 EZ-KIT Lite with the Power On Self Test example. Marc has also tested it successfully on his target, and looks to be working correctly.

I also hit the same issue as this customer using the GUI on Windows 7 x64, so copied MisterDSPs code from this thread and adapted it to work with a Binary LDR file (see MisterDSPs original post for code to work with ASCII ldr files). As with MisterDSPs post this uses the GPL rs232 library available from here.

Attached are two projects - the 21489 second stage loader for VisualDSP++, and the uart Upload project which was build with Eclipse CDT.

Regards,

Craig.

Hi,

Can you please port this to CCES? I tried importing a VDSP project into CCES 1.1.0, and got a lot of unsolved reference.

[Error li1021]  The following symbols referenced in processor 'P0' could not be resolved:
        'SIG_BKP' referenced from '21489_hdr.doj'
        'SIG_CB15' referenced from '21489_hdr.doj'
        'SIG_CB7' referenced from '21489_hdr.doj'
        'SIG_EMUL' referenced from '21489_hdr.doj'
        'SIG_FIX' referenced from '21489_hdr.doj'
        'SIG_FLTI' referenced from '21489_hdr.doj'
        'SIG_FLTO' referenced from '21489_hdr.doj'
        'SIG_FLTU' referenced from '21489_hdr.doj'
        'SIG_IICDI' referenced from '21489_hdr.doj'
        'SIG_IRQ0' referenced from '21489_hdr.doj'
        'SIG_IRQ1' referenced from '21489_hdr.doj'
        'SIG_IRQ2' referenced from '21489_hdr.doj'
        'SIG_P0' referenced from '21489_hdr.doj'
        'SIG_P1' referenced from '21489_hdr.doj'
        'SIG_P10' referenced from '21489_hdr.doj'
        'SIG_P11' referenced from '21489_hdr.doj'
        'SIG_P12' referenced from '21489_hdr.doj'
        'SIG_P13' referenced from '21489_hdr.doj'
        'SIG_P14' referenced from '21489_hdr.doj'
        'SIG_P15' referenced from '21489_hdr.doj'
        'SIG_P16' referenced from '21489_hdr.doj'
        'SIG_P17' referenced from '21489_hdr.doj'
        'SIG_P18' referenced from '21489_hdr.doj'
        'SIG_P2' referenced from '21489_hdr.doj'
        'SIG_P3' referenced from '21489_hdr.doj'
        'SIG_P4' referenced from '21489_hdr.doj'
        'SIG_P5' referenced from '21489_hdr.doj'
        'SIG_P6' referenced from '21489_hdr.doj'
        'SIG_P7' referenced from '21489_hdr.doj'
        'SIG_P8' referenced from '21489_hdr.doj'
        'SIG_SOVF' referenced from '21489_hdr.doj'
        'SIG_SPERRI' referenced from '21489_hdr.doj'
        'SIG_TMZ' referenced from '21489_hdr.doj'
        'SIG_TMZ0' referenced from '21489_hdr.doj'
        'SIG_USR0' referenced from '21489_hdr.doj'
        'SIG_USR1' referenced from '21489_hdr.doj'
        'SIG_USR2' referenced from '21489_hdr.doj'
        'SIG_USR3' referenced from '21489_hdr.doj'
        '__lib_int_table [___lib_int_table]' referenced from '21489_hdr.doj'
        'main [_main]' referenced from '21489_hdr.doj'

Linker finished with 1 error
cc3089: fatal error: Link failed
make: *** [..\..\DebugNWC\21489_SSL_Serial_FLASH.dxe] Error 1

Hi,

Rather than trying to port that VisualDSP++ project, you should follow the advice in the EE-Note, EE-345, but start with the 214xx Kernel files located within CCES at "...\SHARC\ldr\".

As you may have seen, the EE-Note does not contain code for the 21489, but the process I followed to produce the project above was to start with the 21489 PROM Kernel, and follow the steps in the EE-Note to customize it into a second stage loader. The same principal should be applicable starting with the CCES 214xx PROM or SPI Kernels.

Regards,

Craig.

Hi Craig,

I followed the steps for getting a second stage loader in CCES. However, it is not working. Could you please have a look at the attached project and see what I did wrong.

The project

1. reads a blink.ldr file (built into the project as a C array),
2. writes the ldr to flash
3. and then jumps to the second stage loader (_load_application in boot_kernel.s).

The problem is it doesn't start the blink program. Sometimes it jumps back to the start of itself, sometimes gets lost somewhere.

If the flash offset of the blink.ldr is set to 0, the blink.ldr will start after reset. So it seems the flash programming works fine.

One question is that I need to replace final_init_loop with _lib_RSTI, but lib_RSTI is nowhere to be found in CCES. What is it?

Thanks and have a good day.

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, phychem

Now, i am doing a firmware update task with ADSP-SC587.

I think we have the similar process for the update through RS-232: update mode, erase command, flash command, reset command, etc. And for now, i  stuck by the step " erase the flash memory", i wondered if u used the ADI API function "SPI‘ like adi_spi_ReadWrite() to do the erase process .

I know, we use the different DSP, but i think the erease funciton of the ADI are similar

Could you please kindly share your idea? thanks