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.

AM2634-Q1: Accessing the QSPI Flash

Part Number: AM2634-Q1
Other Parts Discussed in Thread: UNIFLASH

Hi,

I am working on AM2634-Q1.

I had a Scenerio where I had to update the firmware in it and I cannot access the boot mode pins.

Question1: Can I update my application into the Flash while my system is still running without accessing boot mode (SOP) pins?

Question2:What would be the procedure, If I have to do a firmware update?

  • Hi,

    The expert is currently OOO due to holiday in TI India, please expect a response by Oct 23rd.

    Regards,

    Sahana

  • Question1: Can I update my application into the Flash while my system is still running without accessing boot mode (SOP) pins?

    Yes. The QSPI flash is usually just idle while your application runs wholly in RAM. As long as your application has the FLASH and QSPI peripherals configure, you can then receive a byte stream (e.g. by CAN), store in a buffer and program the QSPI flash.

    Question2:What would be the procedure, If I have to do a firmware update?

    I'm not saying this is the only way but this is how I did it on AM263Px.

    Study the SBL CAN UNIFLASH example. AM263x MCU+ SDK: SBL CAN UNIFLASH

    By debugging this you will see that an application file is received over CAN into a RAM buffer then through calls to Bootloader driver, the application is flashed to QSPI.

    Ultimately it calls Bootloader_uniflashFlashFileSector(flashIndex, buf, fileSize, flashOffset) where:

    • flashIndex is usually 0.
    • buf is pointer to the start of your application data (e.g. appimage or .mcelf) in RAM.
    • fileSize (size of your application)
    • flashOffset which is usually 0x81000


    In your application, configure FLASH and QSPI the same as the SBL CAN UNIFLASH example then make similar call(s) to Bootloader_uniflashFlashFileSector() in your running application to flash the new application. All being well, after a POR the new application will run.

    In my case, I download the whole application to RAM by XCP-on-CAN FD and then make a single call to Bootloader_uniflashFlashFileSector() in a background idle task. Eventually, I may run low on RAM so at that point I will then download the application block by block and make multiple calls to Bootloader_uniflashFlashFileSector() like a traditional reflash sequence.

  • Question1: Can I update my application into the Flash while my system is still running without accessing boot mode (SOP) pins?

    As Kier has replied, you can read/write to QSPI flash, since in AM263x SOC code is always executed from RAM, so flash is almost idle, unless you are using it in your application.

    Question2:What would be the procedure, If I have to do a firmware update?

    If you are looking for a sample flow refer this: e2e.ti.com/.../5667305

  • without accessing boot mode (SOP) pins?

    Boot mode pins are read by ROM on every power-on reset, so being able to read or write into flash does not depend on it.

    You have to make sure once you have written the new firmware and if you are upgrading SBL also, then make sure both of these have right certificates and SBL has correct location of the new application image that is flashed.

  • Thank you :)