This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AWR1642: How can I write data to SFLASH throw QSPI ?

Part Number: AWR1642

      I am now writing the program to FLASH through a serial port , but its inconvenience in this way. I wanna receive hex data through CAN port and write it to FLASH throw QSPI.

So,could you tell me where can I find the start adress of the SFLASH or exam about SFLASH operation.

  • Hello Anist,


    For example of Flash memory read write please check the QSPI driver and test under mmWave SDK installation, typically at:
    C:\ti\mmwave_sdk_01_00_00_05\packages\ti\drivers\qspiflash\test

    For memory address of flash which is accessible via QSPI, please check the Memory map of Techincal Reference manual of the device.
    For AWR1642 the address is under EXT_FLASH entry:


    EXT_FLASH start address: 0xC000_0000



    Thank you,
    Vaibhav
  • Hello Vaibhav

    Thanks for your answer. Others , when the AWR1642 is powered up , the bootloader copy program from SFLASH to RAM . I want to install two program on the SFLAH , after the bootloader,the device execute the first program (PBL code) at first , and then exexute the second program(application code) , is it feasible ?
    If it is feasible , I assume the bootloader cpoy all the code( include PBL code and application code) from flash to ram when it is power up , then the devices executes different code by jumping different RAM addresses , am I right ?
  • Hello Anist,

    The ROM bootloader in the AWR1642 device loads one MSS image from the SFLASH onto the RAM and thereafter the loaded image begins execution.

    Now mapping this to your usecase, the ROM bootloader will be able to load only the PBL from the SFLASH to RAM. It will now be the responsibility of the PBL to load the application code from the SFLASH to RAM.

    There are some caveats that need to be considered while doing this:

    1. The application code (in this usecase) is not interpreted by the ROM bootloader and will need to be placed at an offset in SFLASH beyond the size of the multicore image file. 

    2. As the loaded PBL is also executing from the RAM,  the application code needs to be loaded at an non-overlapping offset from the PBL. This is considering the application code is independent of the PBL.

    3. The interrupt vector handlers have to be replaced/reinstalled (at location 0x0) before passing on the control to the application code from PBL. Again considering the application code is independent of the PBL.

    In case the application code is an extension to the PBL, it would be like an image overlay/paging approach from the SFLASH to RAM.

    Best regards,

    Naveen