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.

CCS/AM5728: Unexpected program termination

Part Number: AM5728
Other Parts Discussed in Thread: SYSBIOS

Tool/software: Code Composer Studio

Hello,

I am working on a Sitara AM572x industrial EVM and I am developing a UART/DMA based communication channel between two different processor EVM. This has been successfully finalized so far. I was able to achieve my goals via enhancing the TI example project 'UART_BasicExample_idkAM572x_DMA_armTestproject'. Rahul helped me a lot in the past regarding this topic.

Afterwards I copied my code from the 'UART_BasicExample_idkAM572x_DMA_armTestproject' into another project, which is the project of the device that we are developing. This new project is derived from a GPIO example.

When trying to send data via the UART low level drivers, I call at the beginning the function 'UART_initConfig(true)' and this function calls as a result the function 'UartApp_edmaInit()'. I hit a breakpoint inside that function 'UartApp_edmaInit()' , see here:

The next instruction is a DMA library function 'edma3init' and calling this one leads to a termination of the program, see here:

The 'edma3init' function is a pre-compiled library so further debugging with the JTAG is not possible. I verified that the following lines are inside the *.cfg file:

   var Edma = xdc.loadPackage ("ti.sdo.edma3.drv.sample");
   var drv = xdc.loadPackage ("ti.sdo.edma3.drv");
   var rm = xdc.loadPackage ("ti.sdo.edma3.rm");

What can be the root cause that calling 'edma3init' is working on the 'UART_BasicExample_idkAM572x_DMA_armTestproject' but leads to a crash when being called out of our own project?

If there are too many potential causes for this behavior, how can I further debug the behavior and provide more specific information to you?

Kind regards,

Andreas

  • The RTOS team have been notified. They will respond here.
  • Hi,

    When crashed, you may use CCS tools----->ROV classic to see if any exception, stack, heap issues: processors.wiki.ti.com/.../Processor_SDK_RTOS:_TI_RTOS_Tips_And_Tricks

    If you need to step through the EDMA code for edma3init() function:
    Check the map file:
    E.g: C:\ti\edma3_lld_2_12_05_30C\packages\ti\sdo\edma3\drv\sample\lib\tda2xx-evm\a15\debug\edma3_lld_drv_sample.aa15fg(sample_arm_init.oa15fg)
    ./main_uart_test.o (edma3init)

    So you know which edma library is used, then you can add the source code file (E.g: C:\ti\edma3_lld_2_12_05_30C\packages\ti\sdo\edma3\drv\sample\src\sample_arm_init.c) of this function into your project to build (use -O0) without any optimization, then you should be able to step through the code (which was provided in a library format).

    Regards, Eric
  • Hello,

    Regarding the original issue,

    We basically combined a GPIO example project with a UART example project as a start condition for our firmware development. We now have the following problem with the two yellow marked function calls:
        UartApp_edmaInit();
        OSAL_HeapsInit();
        OSAL_StdIOInit();
        UART_socGetInitCfg(BOARD_UART_INSTANCE_BETA, &uart_hw_attrs);
        uart_hw_attrs.enableInterrupt = FALSE;
        UART_socSetInitCfg(BOARD_UART_INSTANCE_BETA, &uart_hw_attrs);
        /* Call board init functions */
        Board_initGPIO();
        AppGPIOInit();
        ConsoleUtilsInit();
        /* GPIO initialization */

        GPIO_init();
     
    Both functions UartApp_edmaInit() and the GPIO_init() call after a chain of function calls finally a function called Hwi_Instance_init() inside the file:
     C:\ti\bios_6_52_00_12\packages\ti\sysbios\family\arm\gic\Hwi.c.
    We don’t face any issues in case that this function is called for the first time, but if that function is being called for the second time, then we finally end up with the below Error_raise() function call.
    This function call causes the program termination inside function Error_policyDefault of the file C:\ti\xdctools_3_50_03_33_core\packages\xdc\runtime\Error.c.
    So if UartApp_edmaInit() is called first, then GPIO_init() causes the program termination and vice versa. But both functions are required since we want to use the UART in combination with DMA based transfer to/from the Tx/Rx FIFOs and also the GPIOs must be properly initialized.
    Can you please help us how to avoid this conflict?
    Thanks,
    Sergei
  • Hi,

    Let me create a test case calling UartApp_edmaInit() followed by GPIO_init() to see if I can reproduce the issue.

    Regards, Eric
  • Hi,

    I was not able to reproduce your issue.Here is what I did on the latest Processor SDK 5.1 release:

    1. I used the UART_BasicExample_idkAM572x_DMA_armTestproject as the baseline (this one enables UART DMA)

    2. I added some GPIO library (via .cfg) and header files and GPIO_idkAM572x_board.c into the project to make sure there is

    GPIO_v1_config passing into GPIO library.

    My code like this:

    static bool UART_test_read_write(bool dmaMode)
    {
    UART_Handle uart = NULL;
    UART_Params uartParams;
    int length = 0;
    uint32_t addrDataPrint, addrScanPrompt, addrEchoPrompt;
    UART_Transaction transaction;
    bool ret = false;

    /* UART SoC init configuration */
    UART_initConfig(dmaMode);

    GPIO_init();

    /* Initialize the default configuration params. */
    UART_Params_init(&uartParams);

    ....

    Inside UART_initConfig(dmaMode), I have below:

    static void UART_initConfig(bool dmaMode)
    {
    UART_HwAttrs uart_cfg;

    /* Get the default UART init configurations */
    UART_socGetInitCfg(uartTestInstance, &uart_cfg);

    #ifdef UART_DMA_ENABLE
    if (dmaMode == true)
    {
    #if defined (SOC_AM65XX) || defined(SOC_J7)
    uart_cfg.edmaHandle = UartApp_udmaInit(&uart_cfg);
    #else
    uart_cfg.edmaHandle = UartApp_edmaInit();
    #endif
    uart_cfg.dmaMode = TRUE;
    }
    else
    #endif
    {
    uart_cfg.edmaHandle = NULL;
    uart_cfg.dmaMode = FALSE;
    }
    uart_cfg.loopback = FALSE;

    if(verifyLoopback)
    uart_cfg.loopback = TRUE;
    /* Set the DMA enabled UART init configurations */
    UART_socSetInitCfg(uartTestInstance, &uart_cfg);
    }

    I knew that dmaMode is true. By stepping through the code, I also confirmed that UartApp_edmaInit() is called,  GPIO_init() is also called later. I didn't have any issue to run it. My code sequence is:

    UART_socGetInitCfg()

    UartApp_edmaInit()

    UART_socSetInitCfg()

    GPIO_init()

    In your code sequence:

        UartApp_edmaInit();
        OSAL_HeapsInit();
        OSAL_StdIOInit();
        UART_socGetInitCfg(BOARD_UART_INSTANCE_BETA, &uart_hw_attrs);
        uart_hw_attrs.enableInterrupt = FALSE;
        UART_socSetInitCfg(BOARD_UART_INSTANCE_BETA, &uart_hw_attrs);
        /* Call board init functions */
        Board_initGPIO();
        AppGPIOInit();
        ConsoleUtilsInit();
        /* GPIO initialization */

        GPIO_init();

    Are you able to isolate any of below can change the behavior:

    1) uart_hw_attrs.enableInterrupt = FALSE 

    2) remove two OSAL calls

    3) remove board_initGPIO() and AppGPIOinit() 

    4) calling UartApp_edmaInit() in between UART_socGetInitCfg() and UART_socSetInitCfg()

    For item 3), in your application .cfg file, if you use:

    var Gpio = xdc.loadPackage('ti.drv.gpio');
    Gpio.Settings.socType = socType;

    This will linking with library ti.drv.gpio:./lib/am572x/a15/release/ti.drv.gpio.aa15fg. This library use the default GPIO configuration, you don't need to have add GPIO_soc.c in your application and you should be able to remove the board_initGPIO() and AppGPIOinit() to blink the LED.

    If you use: var Gpio = xdc.loadPackage('ti.drv.gpio');

    This will linking with library ti.drv.gpio:./lib/a15/release/ti.drv.gpio.aa15fg. This you need add GPIO_SOC.c in your application. See the explanation in:  

    Topic: What is the difference between SOC-specific driver library and the SOC-independent (Generic core-specific) driver library?

    Regards, Eric

  • Hi,

    Can you let me know if the issue still pending?

    Regards, Eric
  • Hi All,
    It looks duplication of e2e.ti.com/.../739574

    We got software abort because we re-used 2 examples, both use the same IRQ 67 for two (2) different purposes - interrupt from Input and UDMA.

    If you do not mind, I suggest to close this thrread and continue in e2e.ti.com/.../739574

    Best regards
    Rasty
  • Thanks Rasty! I closed this one and let's use the e2e.ti.com/.../739574 for discussion.

    Regards, Eric