Post Go back to editing

Write into flash with regard to OTA Update

Category: Software
Product Number: ADSP-SC573

Hello,

I’m currently working on a project involving the ADSP-SC573 processor, and I’m exploring the possibility of implementing Over-the-Air (OTA) updates for firmware deployment.

I have a few specific questions and would appreciate guidance or suggestions based on others' experiences:

Bootloader Flexibility:

  • Does the default bootloader support any mechanism for receiving and updating firmware over a wireless or network interface (e.g., SPI, Ethernet, UART)?
  • If not, would it be feasible to customize the bootloader for this purpose?

LDR File Handling:

  • Since the firmware is typically in the form of an .ldr file, are there recommended strategies for transmitting and parsing this file for OTA updates?
  • Can the .ldr file be processed and written to flash in chunks, or does it require additional parsing mechanisms during the update process?
  • So if I'm loading the ldr file by some means into the ram, should I write the file after loading the whole file, or is it possible to write as chunks of ldr file into the flash as we receive it ?

Memory Management:

  • Are there specific considerations or limitations with using the flash memory on the ADSP-SC573 for storing and switching between old and new firmware during an update?

Success Stories or Examples:

  • Has anyone implemented OTA updates on the ADSP-SC573 or similar ADI processors? If so, are there any best practices, pitfalls, or code examples you could share?
  • Any help would be greatly appreciated. 

Development Tools:

  • Are there any ADI-provided tools, libraries, or example projects that can simplify the implementation of OTA updates?

I’m aiming for a robust OTA solution that minimizes downtime and ensures secure firmware delivery. Any advice or references to existing resources would be greatly appreciated!

  • Hi,

    Please find our replies below:

    Bootloader Flexibility:

    ADSP-SC573 supports booting from external SPI and UART devices. Using SPI Host mode boot, the processor consumes boot data from an external SPI host device.

    Using UART Host mode boot, the processor receives boot data from a UART host device connected to the UART interface.

    LDR File Handling, Success Stories or Examples, Development Tools:

    Please refer the below link for UART host code:

    https://ez.analog.com/dsp/sharc-processors/adsp-sc5xxadsp-215xx/f/q-a/583004/convert-to-binary-file/528752

    Please refer the attached SPI host code. Both UART and SPI Host codes are available for ADSP-SC584 processor, and you can easily modify it for SC573 processor.

    When generating the .ldr file for the slave booting you would need to select the Loader file format as "Include" and choose boot mode "UART Host" or “SPI Host” as per your requirement. Then you can add .ldr file as in the examples.

    Please refer “SPI Slave Boot Mode” and “UART Slave Boot Mode” for hardware connection and more details .

    https://www.analog.com/media/en/dsp-documentation/processor-manuals/adsp-sc57x-2157x_hwr.pdf

    You can use CCES IDE for multi-core development & debug. We have CLDP utility (Command line Device programmer) within CCES for programming flash memory on a target board. Please download CCES tools from the below link:

    https://www.analog.com/en/resources/evaluation-hardware-and-software/software/adswt-cces.html#software-overview

    Memory Management:

    We understand that you will store both firmware versions in Flash and select which one should be used to boot. If so, you can approach Second-Stage Loader (SSL) Using ROM API.

    Please refer the below FAQ for sample projects:

    https://ez.analog.com/dsp/sharc-processors/adsp-sc5xxadsp-215xx/w/documents/18362/adsp-sc584-ssl-booting-via-rom-api-from-the-arm-cortex-a5-core0-sharc0-and-sharc1

    Regards,
    Nandini C

    ADSP_SC584_SPI_Host_Core0.zip

  • Hi Nandini,

    Thank you for the detailed response and the shared resources. The explanation regarding the bootloader flexibility and the process of creating and using LDR files for SPI and UART Host modes is very helpful. Additionally, the links to the documentation and sample projects provide a great starting point for further exploration.

    I have a follow-up question regarding writing the LDR file to a specific location in the flash memory:

    1. When using the SPI Host or UART Host mode, is there a way to specify the exact flash address where the LDR file should be written, especially when storing multiple firmware versions?
    2. If the LDR file inherently contains address information for where its segments need to be written, how can we configure or confirm these addresses during LDR file generation or in the flash programming process?
    3. Are there any examples or tools that illustrate how to write the LDR file to a particular flash offset using the SPI or UART Host approach?

    This information would help us better understand how to manage multiple firmware versions in flash and dynamically choose which firmware to boot.

  • Hi,

    It seems you want to perform the SPI Host or UART Host boot mode, which chooses the application resides in the flash memory to boot.
    Please confirm if our understanding is correct and kindly share your requirements in detail so that we can assist you better.

    Regards,
    Nandini C

  • Hi Nandini,

    Thank you for your response. Your understanding is partially correct. Currently, we are booting the ADSP-SC573 via SPI Flash. However, our goal now is to implement a firmware update mechanism with the following approach:

    1. Firmware Update Process:

      • We will load the new DSP firmware into RAM through a suitable interface (e.g., UART or other means).
      • Once the new firmware is validated in RAM, we want to write it to a specific location in the SPI Flash to replace the existing firmware.
    2. Questions:

      • How can we specify the target address in the SPI flash where the new LDR file should be written?
      • Does the LDR file contain information about its intended location in flash, or do we need to manually manage flash offsets?
      • Is the original LDR file enough to be loaded into RAM and then written directly to SPI flash, similar to handling a normal binary file? Or does it require any special processing before writing to flash?
      • Are there any recommended APIs or utilities in CCES that can assist with writing the firmware to a specified flash address during the update process?

    This approach is aimed at enabling robust over-the-air (OTA) updates or updates via a connected interface without relying solely on booting mechanisms.

    Looking forward to your guidance on implementing this approach effectively.

  • Hi,

    The SC573 always boots from the 0th address of flash. There are two methods available to boot the application from a different location. The methods are outlined below:
    1.Programming OTP space to change the start address.
    2.Second-Stage Loader (SSL) approach Using ROM API.

    We recommend fulfilling your requirements by flashing the firmware at the start address of the flash, and then implementing one of the methods mentioned above.

    Please refer the below steps to achieve this:

    1.Generate a loader file for your actual application with the boot mode set to SPI flash. For example, name the file as “led_blink.ldr”
    2.Create an SC573 application that writes the led_blink.ldr into the start address of the flash. For example, name the project as “SC573_flash_app”.
    3.Next, generate the loader file for the "SC573_flash_app" with the boot mode set to UART Host or SPI Host. For example, name the file “SC573_flash_app.ldr”.
    4.Now, send the SC573_flash_app.ldr from the host device to the SC573. This loader file will run on the SC573 and write the actual firmware (led_blink.ldr) to the start address of the flash.

    We recommend installing the “ADSP-SC5XX Board Support Package” from the link provided below:
    download.analog.com/.../ADI_ADSP-SC5xx_EZ-KIT_Lite-Rel2.0.2.exe

    After installation, please refer to the "Device_Programmer" example for guidance on how to write the .ldr file into the flash.
    <installation path>\ADSP-SC5xx_EZ-KIT_Lite-Rel2.0.2\ADSP-SC5xx_EZ-KIT\Examples\Device_Programmer

    After successfully completing this, we recommend referring to EE-428 and its associated example, "3. SSL_Code_Example," which explains the SSL method to boot from different location.
    https://www.analog.com/media/en/technical-documentation/application-notes/ee428v01.pdf

    https://www.analog.com/media/en/technical-documentation/application-notes/ee428v01.zip

    Please find our replies for your questions:
    How can we specify the target address in the SPI flash where the new LDR file should be written?
    >> Refer to the "Device_Programmer" example, where you can specify the target address of the flash for the write operations.

    Does the LDR file contain information about its intended location in flash, or do we need to manually manage flash offsets?
    >> Yes, you need to manage the flash offsets and determine where the .ldr file can be stored.

    Is the original LDR file enough to be loaded into RAM and then written directly to SPI flash, similar to handling a normal binary file? Or does it require any special processing before writing to flash?
    >> Please follow the steps mentioned above.

    Are there any recommended APIs or utilities in CCES that can assist with writing the firmware to a specified flash address during the update process?
    >> We have the Device Programmer (cldp) CCES command-line utility for programming device memory on a target board. Below is the command, used to write the “SPIMASTER_Single_Multicore_Led_Blink_Core0.ldr” to the offset 0x80000.

    "C:\Analog Devices\CrossCore Embedded Studio x.x.x\cldp.exe" -proc ADSP-SC573 -core 1 -emu 1000 -driver "C:\Analog Devices\ADSP-SC5xx_EZ-KIT_Lite-Rel2.0.2\ADSP-SC5xx_EZ-KIT\Examples\Device_Programmer\sc573\sharc\sc573_w25q128fv_dpia_Core1\sc573_w25q128fv_dpia_Core1.dxe" -cmd prog -erase affected -format bin -offset 0x80000 -file ./SPIMASTER_Single_Multicore_Led_Blink_Core0.ldr -cmd compare -format bin -offset 0x80000 -file ./SPIMASTER_Single_Multicore_Led_Blink_Core0.ldr

    Regards,
    Nandini C

  • Hi Nandini,

    I came across this question in the forum.  ADSP-SC584 Flash memory firmware upgrade . My requirement is the same but with a different processor, which is ADSP- SC573.

    So, I went through the resources you provided and couldn't find a way to write the firmware to a particular location, when I looked into the Device Programmer example. If I'm not wrong that is the firmware of the driver file which we use to program flash using cldp. 

    As a matter of progress I was able to flash a SSL at offset 0, jump from there to another address where I placed another firmware. Both these firmware were flashed through CLDP. 

    If possible could you please provide a sample code to write an LDR file generated as include format, to a particular address in flash and jump to that address using the adi_rom_Boot() API ?

    Hoping you could help me with this.

    Regards,

    Hisham

  • Hi,

    Please refer the below FAQ which upgrades the firmware in the flash via UART and boots the new firmware.
    Documents 

    Download the “7127.UART_Firmware_Upgrade.zip” file and open the “ADSP_SC589_UARTFirmwareUpgrade_Core0” project in CCES.

    Please refer to the "SPI_FlashRW" function in the ADSP_SC589_Flash_Core1.C file, which writes the data (.ldr) to a specific location in flash memory. By modifying the "WR_Block_ID" macro, you can write the firmware to the desired location.

    Hope this helps.

    Regards,
    Nandini C

  • Hi,

    I referred the provided source code and implemented a code to just test if the writing to flash is working or not.

    I created the ldr file for the SSL firmware and wrote it at WR_Block_ID = 0. But the code is stuck at the function wait_for_flash_status, where it checks status register 1.

    I believe the status byte will be 1 when the flash is busy and 0 when it is not. It's sets the write enable bit. Flag value is 0x02 = 0b10. So when this function is called with state 1, if the flash is busy the status will be 0b11 and if not 0b10. Thus won't program stay in the loop without exiting ?  

    I'm attaching my source code, would you be able to look into it if I'm doing anything wrong. Your suggestions would be very helpful.

    OTA_Test_2_Core0.zip

  • I think the write enable command itself is not working. Write enable bit is not being set . 

    I tried running:

    *pREG_SPI2_SLVSEL &= ~ENUM_SPI_SLVSEL_SSEL1_HI ; // selct_flash;
    unsigned char status = flash_byte_access(FLASH_RD_STAT1);
    printf("Initial Flash Status: 0x%02X\n", status);
    flash_byte_access(FLASH_WR_EN); // send write enable command
    status = flash_byte_access(FLASH_RD_STAT1);
    *pREG_SPI2_SLVSEL |= ENUM_SPI_SLVSEL_SSEL1_HI ; // deselct_flash;
    printf("Updated Flash Status: 0x%02X\n", status);

    Result is:

    Initial Flash Status: 0x00
    Updated Flash Status: 0x00

    Could you please help me with this ?

  • Hi,

    We have analysed your project and noticed that the pin muxing for SPI pins has not been enabled. Please follow the steps below to configure the GPIO pins for SPI.

    1.Open the project in CCES
    2.Go to system.svc > Pin Multiplexing tab > Enable the SPI pins as in the attached image.


    3.Click Save and Run the project.

    After enabling the pin mux, we are able to write loader file in to the flash.

    Regards,
    Nandini C