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.

TMDS64GPEVM: SciClient event config failed with two GPIO interrupts

Part Number: TMDS64GPEVM
Other Parts Discussed in Thread: SYSCONFIG

Hi,

we are using the TMDS64GPEVM with the XAM6442A SFGGAALV SoC in combination with the MCU+ SDK 8.6.0.34. (SysConfig Tool 1.15.00)

All questions are related to applications running on the R5 only. (Bootswitches are set to NO_BOOT)

I have three questions:

1.

We realized that when we enable two GPIOs  with interrupts, the Board_gpioInit is not able to succeed and exits with "SciClient event config failed". When we reduce the number of interrupts by one Board_gpioInit runs without errors. Is that a known issue and has something to do with our hardware and/or MCU+ SDK version?

2. 

Board_gpioInit is not part of a public header of the autogenerated files. What is the reason behind it? I think to use for example interrupts we need to execute Board_gpioInit on startup.

3.

To start debugging on the R5 we use CCS 12.5.00. Here we launch the configuration and initialize R5 and M3 with the load_dmsc.js script.

We realized in case the application on the R5 crashes, we can't just reset the R5 core and start the application again. Here the Board_gpioInit fails again with "SciClient event config failed". We have to powercycle the board (I think to reset the M3 core) and to the described procedure again. Is that really needed or is there an alternative?

Thank you in advance.

Please come back to me  in case anything is unclear.

 

  • Hello Vincent,

    Thanks for your question.

    Please expect delayed responses as the expert is out of office.

    Thanks for your patience.

    Regards,

    Vaibhav

  • We realized that when we enable two GPIOs  with interrupts, the Board_gpioInit is not able to succeed and exits with "SciClient event config failed". When we reduce the number of interrupts by one Board_gpioInit runs without errors. Is that a known issue and has something to do with our hardware and/or MCU+ SDK version?

    Hello Vincent,

    May I know which pins you are using in your project ?

    For example, you are enabled GPIO0_0 and GPIO0_1 Pins for GPIO interrupts from system config.

    SYSFW is assigned one Router output to destination core , when you tried to configure the same router output for the other gpio interrupt, you may get this issue.

    Since , the GPIO MUX Interrupt Router works like route one input to one output. But in the current situation, the same two bank  interrupt was routed to same router and same cores, and this is not supported in AM64X or AM62X devices.

    This issue can be solved by pin interrupt rather than bank interrupt or routing different router outputs to different GPIO pins.

    for example, the GPIO0_0 pin router output would be 7 and configure the router output would be other than 7 for GPIO0_1.

    Please find the FAQ below for more details on pin interrupt methods.

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1260818/faq-am64x-am62x-how-do-i-route-the-same-gpio-bank-interrupts-to-different-destination-cores

    Board_gpioInit is not part of a public header of the autogenerated files. What is the reason behind it? I think to use for example interrupts we need to execute Board_gpioInit on startup.

    The problem is that to route the GPIO interrupt to different cores, there is GPIO MUX Router . Users can' t write this register directly. This register should be configured by SYSFW through a SCI client. In the SCI client config, there are src , dst index and other parameters. These are user can't configure without knowledge of resource allocations the SOC level. So, if, users configures these parameters wrongly, then every time user gets the SCI client error and unexpected behavior in the system to avoid this issues we are doing all stuff and generated code in the autogenerated files . I have explained all SCI client parameters config in the above FAQ as well.

    To start debugging on the R5 we use CCS 12.5.00. Here we launch the configuration and initialize R5 and M3 with the load_dmsc.js script.

    When initializing the SOC with scripts for every POR , you have to initialize the SOC every time. To avoid this initializations you can go with other than NO BOOT Mode.

    Regards,

    S.Anil.

  • Hi, thank you for the fast reply. We tried to use GPIO1_35 and GPIO1_43 at the same time, with different Interrupt Router Outputs (8 and 9).

  • What would be an alternative boot mode for my case?

  • Hello Vincent,

    Hi, thank you for the fast reply. We tried to use GPIO1_35 and GPIO1_43 at the same time, with different Interrupt Router Outputs (8 and 9).

    Did you face any problems with the different router outputs ?

    In the above situation, both GPIO1_35 and GPIO1_43 pins will come under the Bank 2 Interrupt and SYSFW does not allow you to route the same bank interruptions to Destination core.

    So, you have to go with Pin interrupt rather than Bank interrupt.

    Please look at the above FAQ, in which I have clearly explained and attached the Pin interrupt example.

    What would be an alternative boot mode for my case?

    Board mode requirement is user choice.

    You can go with OSPI or emmc or SD boot mode.

    If you are using EVM or SK kits, use anyone in the boot mode and try to initialize SOC with the same boot mode.

    For more details , you can check in link  below for below topic.

    Flash SOC Initialization Binary 

    https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/latest/exports/docs/api_guide_am64x/EVM_SETUP_PAGE.html

    Regards,

    S.Anil.