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.

RTOS/66AK2G12: Unable to boot from QSPI Flash

Part Number: 66AK2G12

Tool/software: TI-RTOS

Hi,

I have an application (running on both arm and dsp core) which works perfectly when I run it using JTAG debugger. But when I flash the same to QSPI Flash, it does not work at all.

I have followed the following link to flash my binary on the board: http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_K2G

According to the link I should generate the app and flash it through QSPI. Interestingly when my app is of smaller size, it works as intended. But if I add some modules to my application, thereby increasing the size of app, it stops working.

Note that QSPI flashing works properly irrespective of the size. Its just that after booting in QSPI mode, the application does not work properly when app size is little bigger.

My application is built using Processor SDK.

Thank You

  • Hi,

    I have a couple of questions to help us better understand your use case:
    1. Please shortly describe what does your app do? Which modules does it involve?
    2. Do you use the Processor SDK RTOS MLO to initialize your board and load your custom application, or does your app include the 66AK2G12 initialization in it?
    3. Which Processor SDK RTOS version are you using?

    Best Regards,
    Yordan
  • Hi Yordan,

    1. I am working on PASDK(processor_sdk_audio_1_02_04_01). It has executables for arm and dsp core.

    2. Yes, I am using Processor SDK RTOS MLO to initialize the board which in turn loads the application.

    3. I am using pdk_k2g_1_0_6.

    Please let me know if I should provide further details.

    Thanks,

    Krishna

  • Hi,

    I've notified the RTOS team. They will post their feedback directly here.

    Best Regards,
    Yordan

  • According to the link I should generate the app and flash it through QSPI. Interestingly when my app is of smaller size, it works as intended. But if I add some modules to my application, thereby increasing the size of app, it stops working.


    The SBL does the following,

    1. SBL finishes setup and looks for "app" to execute next. This user-modifiable application may reside in SD card or QSPI memory depending on the bootmode chosen.
    2. Once located, app will be loaded into memory and execution will be branched to the application's entry address

    Please ensure to choose the correct memory region to load and run the application.

    Are you loading the application in DDR or Internal memory? Do you have enough memory to load and run the application?
  • Krishna,

    How big are your application images. We have tested boot images >8 MB with PRSDK 4.01 and later releases and have not seen any issues. We had a bug PRSDK-2792 with older releases where we saw some issues. Can you confirm you are using PRSDK 4.01 and later for your testing.

    If you are using image >16 MB then I would recommend checking if the QSPI writer is using 4 byte addressing. Other question would be, are you booting in QSPI 48 mode or QSPI 96 mode?

    Regards,
    Rahul
  • Hi everyone,

    I was able to find the issue. The issue is with IPC implementation in PASDK. I have verified that the issue in not because of size.

    Let me run you through some of the scenarios:

    1. The working case is when we run the application through JTAG and when DSP is run first followed by ARM.
    2. Next case is when we are running the application again through JTAG but this time we run ARM first and then DSP. In this case ARM crashes.
    • When ARM is run first, ARM is in a while loop of Ipc_attach. As soon as DSP runs and it calls Ipc_attach, ARM is crashing. It seems like some memory configuration issue involved in IPC module.
    • In the MLO code, we observed that MLO runs DSP first and then ARM. But still we introduced some delay after booting DSP and before jumping to ARM. This seems to resolve our issue.

    SBL_DSPBringUp(0, entry.entryPoint_DSP0);

    while(delay); /* introduced by us*/

    func_ptr = (EntryFunPtr_t) entry.entryPoint_MPU_CPU0;
    func_ptr();


    It is clear that there is some issue when ARM calls IPC_attach before DSP does. Can you please tell us what could be the reason?

    Thanks,

    Krishna

  • Krishna,

    I believe that this is a known issue with ARM and DSP side synchronization which we were debugging sometime back but was resolved in the GA release as far as I can tell. Please contact the audio support mailing list for their inputs as PA SDK related issues are not supported through public forums.

    Regards,
    Rahul