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.

PRU In-Stable Behavior

Other Parts Discussed in Thread: AM3358

Hi,

We are trying to send and receive data via DCAN of AM3358 using PRU engine. We see issues which is very strange and stopping us not to continue further. The below are some highlights,

1. In our program PRU updates shared memory of it to show the current status to user, the shared memory here is 0x12000 & 0x12004 (as in lnk-am3xx.cmd) of DATA 12K RAM2. And an application program in Linux read shared memory of PRU and display in UART console.
2. When we integrate/enable our DDR memory access code into our project we are able to see fairly expected result. I mention fairly because in-stable behaviour

    rxdata:7=5f525543 sharedDram=1 +1=100        <<<<< This is not accepted and displayed for long duration more than minute, it shows control stuck at end of function "initDcan()".
    rxdata:0=69007265 sharedDram=8 +1=0            <<<<< This is the expected content
3. When we remove DDR memory access code the behaviour is very strange.
    rxdata:0=69007265 sharedDram=427ca17e +1=80db864 <<<<<< This appears to be very strange, it appears to be PRU does not run our program.
4. Attached folder structure:
    
        NonWorking
            dataHexDump                -    Hex Dump of data.bin created by hexpru
            main.c                     -     Major code snippet, which shows different updates about Shared Memory
            SyncCAN.map                -    Map file generated during non working case
            textHexDump                -    Hex Dump of text.bin created by hexpru
            UART_Non_Working.log    -    UART log at non working case which includes boot log.
        Working
            CRO_Shot.jpg            -    CRO capture during fairly working cmd
            dataHexDump                -     Hex Dump of data.bin created by hexpru
            main.c                     -     Major code snippet, which shows different updates about Shared Memory
            SyncCAN.map                -    Map file generated during working case
            textHexDump                -    Hex Dump of text.bin created by hexpru
            UART_Working.log        -    UART log at working case which includes boot log.
        bin.cmd                        -    command file used by hexpru
        lnk-am3xx.cmd                -    command file used by clpru
        
We feel memory corruption either may be issue with command files or due to accessing DDR region from 0x80001000, we use kernel from EVM of AM3358 with RT patch. Kindly share your suggestion for us to continue further.  6012.PRU_AM3358_DBG.zip

  • Does the PRU have "control" of the DDR memory range you are attempting to access or is something else ARM-side potentially accessing this memory? Bear in mind that the PRU cores do not go through the cache controller, so you could be seeing cache coherency problems when the ARM attempts to access the data.

    Have you debugged the PRU code line-by-line to ensure that this code is behaving as expected? The PRU core shouldn't have any specific trouble writing to any of this memory, but depending on what memory is currently "in-use" by the kernel and your user-space applications you could be seeing problems as a result of this.

  • On any case I wonder why without DDR memory access code in PRU the behavior is strange. Do you agree that text and stack is aligned properly. 

    In one other case with DDR + DCAN Rx + DCAN Tx the code exceed limit and as we communicated change in hexpru cmd file solves compilation but behavior with DUT is as same which is strange. 

  • Tim & TI team,

    Kindly share your inputs as which will help us to move further, I have attached full bench which can help you to reach the problem.

    Case 1: Working:

    1.a: Enable Macros as below in file main.c

    #define         PRU_MEM_SHM                      (1)
    #define         DCAN_STATUS                        (1)
    #define         DO_LOOP                                 (1)


    1.b: Observation, the control will reach initDcan and GPIO will go high, point at which GPIO is made high is as below (snippet from attached file main.c)

            (*(volatile unsigned long *)(0x44e0713c)) = 0x80000000;
            while(1);

    Case 2: Non-Working:


    2.a: Set macros as below in main.c

    #define         PRU_MEM_SHM                      (0)
    #define         DCAN_STATUS                        (1)
    #define         DO_LOOP                                 (0)

    2.b: Observation, the control is expected to reach initDcan and set GPIO high, but it is not happening.

    6114.dcantest_v01.tar


    Conclusion: Without DCAN module the other two modules are working fine and with DCAN (which i took from starterware) the expected results are not coming.

  • Suresh,

    What happens in your initDcan routine? Have you been able to step through it and witness where things go wrong? Do you see the GPIO go low prior to hitting this routine? Based on your feedback there is either something preventing you from getting into the routine or breaking before you get there.

    I do not see how modifying the macros can cause your InitDcan() function to not work properly unless you have dependencies you are no longer meeting with the commented-out code.

  • TimHarron said:
    I do not see how modifying the macros can cause your InitDcan() function to not work properly unless you have dependencies you are no longer meeting with the commented-out code.

    I found at least one of these dependencies.

    On line 181 of your main.c you have the line "PRUCFG_SYSCFG &= ~SYSCFG_STANDBY_INIT;". Note that this is required to access anything outside of the PRUSS - this includes ARM GPIO banks.

    On line 177 you are trying to write a low to the GPIO pin - this should not ever work prior to clearing the STANDBY_INIT bit in the SYSCFG register.

  • Hi Tim,

    We followed your valid suggestion and now, we were able to observe the same instability in data transmission that the data was sent only after three to four trials. The attached bench sends data over DCAN after the mentioned trials.

    Snippet from UART log file DCAN_Test_v02.log:

    rxdata:2=74735f5f sharedDram=1 +1=8
    rxdata:3=70006c61 sharedDram=1 +1=8
    rxdata:4=7363775f sharedDram=1
    # ./pruloader

    INFO: Starting PRU_memAccess_DDR_PRUsharedRAM example.
            INFO: Executing example.
            INFO: Loading Data. success
            INFO: Executing example.
     success
            INFO: Initializing example.
    rxdata:0=69007265 sharedDram=80 +1=9


    UART Observation:

    The one in Red is invalid and Green is valid

    During initial trial, the control/code stops in initDcan function, after few trials it reaches till the end of initDcan function and so.

    We are not sure about the cause for the problem, we are trying to debug with memory dumps of text and data region. Would be very helpful if you have some inputs to us.


    7573.dcantest_v02.zip