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.

AM5728: am5728 RTOS pinmux

Part Number: AM5728

I am using AM5728 GP evm board.
I am using RTOS and the version is processor_sdk_rtos_am57xx_5_02_00_10.

I change i2c5 to gpio during program execution.
The pinmux is being executed by referring to the evmam572x_pinmux.c file.
However, when performing pinmux, "IntDefaultHandler(void *dummy)" function is sometimes called.

I wonder why this is happening. And I want to know how to solve it.

I would appreciate if you can tell me how.

Thank you.

  • Hi,

    However, when performing pinmux, "IntDefaultHandler(void *dummy)" function is sometimes called.

    You mentioned "sometimes", is it not always?

    Also, as mentioned in function definition, "Since interrupts should be disabled before unregistering the corresponding handler, this should never be called".

    I change i2c5 to gpio during program execution.
    The pinmux is being executed by referring to the evmam572x_pinmux.c file.

    can you attach your project and steps to reproduce the error, so that we can reproduce it on our side.

  • Thank you for answer.

    Yes. The function "IntDefaultHandler(void *dummy)" is not always called, but sometimes.

    I'm using the "ti/drv/vps/examples/loopbackBareMetal" example.
    In the LpbkApp_runTest() function of the example, after executing the LpbkApp_dispCreate(appObj) function, pinmux is being executed.

    Below is the pinmux function.

    unsigned int pinmux_i2c5_to_gpio(void)
    {
    CSL_control_core_padRegs *hCtrlCorePad =
    (CSL_control_core_padRegs *) CSL_MPU_CTRL_MODULE_CORE_CORE_PAD_REGISTERS_REGS;
    Uint32 regValOrig;
    Uint32 regVal = hCtrlCorePad->CONTROL_PBIAS;
    regValOrig = regVal;

    CSL_FINST(regVal, CONTROL_CORE_PAD_CONTROL_PBIAS_SDCARD_BIAS_PWRDNZ, DISABLE);
    CSL_FINST(regVal, CONTROL_CORE_PAD_CONTROL_PBIAS_SDCARD_IO_PWRDNZ, DISABLE);

    hCtrlCorePad->CONTROL_PBIAS = regVal;


    /* Check to make sure IO Delay stack and functions are in local memory */
    if (((uint32_t) &ioStack >= 0x80000000) || ((uint32_t)BoardCtrlPadIoDelayConfig >= 0x80000000))
    return BOARD_PINMUX_BAD_MEM_REGION;
    #if defined(_TMS320C6X)
    Board_ioStack(ioStack+IO_DELAY_STACK_SIZE, BoardCtrlPadIoDelayConfig, ctrlPadCfg->mmcPadCfg, ctrlPadCfg->noPins);
    #else
    asm("STR r13, [%0]\n"::"r"(&ioStack[IO_DELAY_STACK_SIZE-1]));
    asm("MOV r13, %0\n"::"r"(&ioStack[IO_DELAY_STACK_SIZE-2]));
    /* Configure the pinmux and virtual/manual timing modes for all pads. */
    //================= I2C5->GPIO ==================//
    BoardCtrlPadIoDelayConfig(i2c5_to_gpio_pad, 2);
    //================= I2C5->GPIO ==================//
    asm("MOV r13, %0\n"::"r"(ioStack[IO_DELAY_STACK_SIZE-1]));
    #endif /* End of IO Delay config with relocation */
    delay(10);
    hCtrlCorePad->CONTROL_PBIAS = regValOrig;
    delay(10);

    return 0;
    }

    Thank you.

  • Hi,

    I didn't get the reference of "i2c5_to_gpio_pad", but as you mentioned that this code is working, therefore i assume that should be fine. Basically, you are replicating the pinmux API from board files. That will take some of your stack and hence i am thinking it is a more of a memory issue. Can you try following suggestion:

    • Increasing the stack size is good advice, that should tell you if the problem is due to stack overflow. You can increase by 50% and see whether the issue persists. Then, you can try optimizing it.
    • can you do a debug reset to insure the program counter is at the reset vector or, at least, the beginning of main when you start execution of your code.

  • Thank you for answer.

    I found that the "IntDefaultHandler(void *dummy)" function is called from the Intc_AbortHandler(void) function.

    void Intc_AbortHandler(void)
    {
         if (0U != fnRAMVectors[INTERNAL_INTERRUPT_ABORT_ID])
         {
              fnRAMVectors[INTERNAL_INTERRUPT_ABORT_ID]
              (argArray[INTERNAL_INTERRUPT_ABORT_ID]);
         }
         else
         {
              /* Go into an infinite loop.*/
              volatile uint32_t loop = 1U;
              while (1U == loop)
              {
                  ;
              }
         }
    }

    When I debugged it, it seems that it is an problem about address.


    I've tried increasing the stack size among the methods you mentioned, but the problem still occurs.

    I would appreciate it if you could tell me how to do the second method about debug reset.

    Thank you.

  • Hi,

    When I debugged it, it seems that it is an problem about address.

    Yes, as discussed hereIntc_AbortHandler() called during invalid address accesses.

    I've tried increasing the stack size among the methods you mentioned

    try increasing heap also.

    but the problem still occurs.

    As you told, it is running sometimes. Can you give some numbers, as how frequent it is failing. And, also can you attach the src file(s), so that i can reproduce the issue on my side. Which ball numbers you want to change from i2c5 to gpio.

    I would appreciate it if you could tell me how to do the second method about debug reset.

     It is an CCS option, inside CCS GUI, after connecting the cores and before loading the program just click on the icon as shown.

  • Thank you for answer.

    All of the methods you suggested don't seem to work.

    On average, it seems that the "IntDefaultHandler(void *dummy)" function is called about once every 7-8 times.
    However, it seems difficult to generalize the number of times.

    The ball numbers I want to change are G12, F12.


    I am in a baremetal environment.
    Also, it is difficult to say that the MMU and cache settings are perfect.
    Could this environment have an effect?


    src file is attached.
    I didn't know which files to attach, so I attached only mux-related files.
    Only function and pad added to existing TI provided files.

    /cfs-file/__key/communityserver-discussions-components-files/791/8877.boardPadDelayInit.c

    /cfs-file/__key/communityserver-discussions-components-files/791/8686.evmam572x_5F00_pinmux.c

  • Hi,

    On average, it seems that the "IntDefaultHandler(void *dummy)" function is called about once every 7-8 times.

    are you power cycling the board everytime, or running continuously? I want to understand the scenario as somewhere your code is either trying to accessing invalid address or module.

    The ball numbers I want to change are G12, F12.

    Can you confirm the pinmux change by reading padconfig registers. Also, after doing the pinmux, is the code is trying to access some i2c5 devices?

    I didn't know which files to attach, so I attached only mux-related files.

    you can zip and attach the project.

    Also, you can debug the following points:

    • If there is no dependency of i2c5 in the code, then doing it manually you can directly change the pinmux file and do the configuration as part of BOARD_INIT_PINMUX_CONFIG. This will remove redundancy.
    • you can increase the delay after pinmux so that configuration get in sync with processor. 
  • Thank you for answer.

    Adding or increasing the delay while performing the mux or after performing the mux will work.
    But can you say this is the right solution?

    I wonder if there is another underlying problem.

    Currently, the problem is occurring only in the i2c5 mux part. However, if there are other fundamental problems, similar situations are likely to occur in other areas as well.

    Thanks for your response.

  • Hi,

    Adding or increasing the delay while performing the mux or after performing the mux will work.

    Great! it may be due to some input signal comes immediately and core is not ready to process it, after enabling the mux.

    But can you say this is the right solution?

    yeah, if it is a nominal delay then it is fine. But if you are giving long delays then we have to look for other reasons.

    Hope, the issue is resolved. Please click on resolve the issue if you dont have any further query.