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.

AM2434: Sciclient_rmIrqSet() fails after reloading application in CCS

Part Number: AM2434

Hi  ,

you have described a workaround for the above problem in this thread AM2432: MCU-PLUS-SDK-AM243X Sciclient_rmIrqSet() fails after reloading application in CCS - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums. This workaround is not acceptable to us. We prefer a fix for this problem. We use neither the SBL_NULL nor the DEV_BOOTMODE.

Regards,

Matthias

  • Hello Matthias,

    If you are okay to use SBL_OSPI mode then can you check Getting Started --> Flash a Hello World example here at https://dev.ti.com/tirex/explore/node?node=A__AD2nw6Uu4txAz2eqZdShBg__com.ti.MCU_PLUS_SDK_AM243X__AROnekL__LATEST ? 

    But in this case you can't load from CCS. The flashing steps will do that for you.

    Does this help or is your requirement something else?

  • Hi,

    in my opinion this is a bug and we would like TI to take care of it. We just want to load fw several times in a row with the debugger without problems.

    Regards,

    Matthias

  • Hi Matthias,

    Can you confirm what you mean by "We use neither the SBL_NULL nor the DEV_BOOTMODE"?

    Can you share step by step in the boot process?

    Regards,

    Ankur

  • Hi Ankur,

    we use our own bootloader, primary boot is spi and secondary boot is sd. 

    We use the blackhawk xds560 as debugger. In my opinion, it should be possible to load fw with the debugger several times in a row without a powercycle. Unfortunately, this does not work with the function mentioned above. If it is called a second time without a powercycle, the call fails.

    Regards,

    Matthias

  • In AM243X soc architecture, sysfw is used to manage the power and resources which executes on the device manager core. It gets initialized during the primary booting. When we load and run our application, the resources requested by the cores get allocated to them with the help of Sciclient (running on the host core) interacting with the Sciclient server (device management core).

    The 2nd time when we re-run the same app without power cycling, all those resources requested earlier are seen as the already taken ones and hence sciclient is not able to get those again and so it throws errors. This is a limitation we have.

    We have tried experimenting with some configurations and below are a few ways to handle it:

    1. You can either do system reset so as to release all the resources being requested and allocated in the 1st run. In this case, you have to again load to all the cores involved in the project.

    2. If you're doing a core reset then you can selectively deintialize those resources which you want to use again so as to release them before using again. For eg, in case of gpio, we may check how Board_gpioDeinit() function is releasing the resoures and do the same before requesting for the resources again.