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.

AM1806 and PRU Shared Memory Problems

 

I have a developed an application that uses the PRU to capture some data from several I/O pins and then copy this data to a data array of 100 short int values in shared RAM. Once the data is copied to memory the PRU interrupts the CPU to indicate that the data is available and then the PRU spins waiting for a flag in the PRU RAM to be cleared. The ISR in the CPU copies the shared data and then clears the flag in the PRU RAM to release the PRU to can capture a new set of data.

The handshake between the CPU and PRU work as expected but sometimes the data in the shared RAM is not valid. When the data in the shared RAM is not valid it is as if the PRU fails to write to the shared RAM locations. Normally the bad locations are lumped together in groups of 10 to 20 locations but the boundaries of good vs. bad locations are not repeatable or on powers of 2. This problem happens when I have the shared RAM in external DDR and in L3 memory.

I have verified that the problem is with the write of the shared RAM memory by the PRU since I have the PRU writing a constant value into the shared RAM and then checking for this constant value in the ISR.

All of the examples on the PRU transferring data into shared RAM only do the transfer once then halt. In my code the first time the transfer takes place it is always successful but on successive transfers there is a problem.

Is there some limitation on how shared RAM is used with the PRU? Is there a memory speed issue between the PRU clock speed and the clock for the memory? Is there an issue in using shared RAM while running SYS/BIOS? I am using SYS/BIOS ver 6.32.5.54 with this code.

 

  •  

    Additional information.

    In the first post I stated that the initial write of data to the shared RAM by the PRU was successful. This is not the case. On further testing the PRU will write to the shared RAM but not consistently. In the latest test of the 100 short int locations that are in the shared RAM the PRU successfully wrote to locations 0-9, failed to write to locations 10-25, wrote to locations 26 - 39, failed on locations 40 & 41, successfully wrote to location 42 failed locations 43 etc. Very inconsistent.

  • Hi Thomas,

    One debugging suggestion is to simplify your code to have the PRU read the shared RAM content, instead of interrupting the ARM.  Does the PRU read the same value back that it supposedly wrote?

    A few additonal questions about your test and results:

        1.  Are you writing / reading to the same shared RAM address each loop?  
        2.  You mentioned that "it is as if the PRU fails to write to the shared RAM locations."  Is the non-valid data completely erroneous?  Or is it simply not updated (i.e. the same as from the previous write / loop)?

    Regards,
    Melissa  

  • Melissa,

    I am reading and writing to the same shared RAM address on each loop. As a debugging effort I have had the PRU halt at the end of the loop so that the ARMISR can be the only application accessing the data memory at that time. The problem still exist.

    When the problem occurs, the data in the memory locations is the last data written to the memory location. If I have the ARM write to the buffer location the data is always updated correctly but when the PRU writes to the buffer the data is sometimes changed and sometimes not changed.

    As a debugging effort I have had the PRU write then read back the buffer location, if the read back was not the same as the write the PRU would repeat the write/read back operation. This code results in the PRU getting stuck in an endless loop trying to write to a memory location, indicating that the problem is with the PRU write to the memory location.

    Recently I have discovered that if I disable the cache in SYS/BIOS for all memory then the PRU can successfully write to the buffer and the correct data is read by the ARM ISR. Problem is that this solution may have performance impacts since cache can only be disabled for all of memory. Is there a way to disable cache for only a section of memory?

  • Problem was resolved. See "PRU Shared Memory when using SYS/BIOS" in BIOS forum.

    http://e2e.ti.com/support/embedded/bios/f/355/t/157148.aspx