• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 161 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM2434: AM2434 PRG1_PRU1 can to be re-started by R5_0_0, but fail to run into the main of PRG1_PRU1.

Jason Chiu
Prodigy 160 points
Part Number: AM2434


Tool/software:

Hello Specialists,

I was able to enable/disable PRG1_PRU1 core. But the second time activated PRG1_PRU1 core seemed not able to run into PRG1_PRU1's main: assembly program. 

The following screen capture was the main() in R5_0_0, (it was the MCU+ SDK 10.0.0 example gpio_led_blink example). 

I put in enable PRG1_PRU1 enable command and the PRG1_PRU1 core could be started and can put captured ADC data into PRG1 share memory address (red color to show updated). 

The second screen capture was the test assembly code I put in PRG1_PRU1 for reading pins (connected to ADC parallel output pin) and place them into PRG1 share memory:

The third screen capture was to show PRG1_PRU1 could be stop by R5_0_0 using command inside gpio_led_blink.c:

The following screen capture was to show the PRG1_PRU1 core was re-started by R5_0_0 core.

The problem was that the PRG1 share memory was not updated. 

It seemed the re-started PRG1_PRU1 core could not run the assembly code in main to read ADC result on I/O pin to update PRG1 share memory.

I think I maybe missing some control command to cause the problem.

Can you please help to check this problem?

Thank you very much.

Best Regards,    Jason Chiu.

  • 0
    TI__Expert 7385 points

    Hi Jason,

    I have a few questions about your approach:

    1. On restarting the PRU core, are you expecting it to run from the starting main function again or to continue from where it was paused?

    2. What is your intent behind pausing the PRU core, can you give me more information about your use case?

    Regards,

    Nitika 

  • 0 in reply to Nitika Verma
    Prodigy 160 points

    Hi Nitika,

    Thank you very much for your reply. I seemed this is not a simple problem.

    My application case is a Time-of-Flight measurement system.

    I didn't know the PRU couldn't be used as a "state machine" when involving Enable/Disable/soft-reset operation (couldn't start from "main:" after soft-reset, and no time delay spec.).

    I also don't know the latency time for PRU to be really running from "main:" after I issue "enable PRU" command from R5F core? I also don't know if PRU could be soft-reset then enabled to run directly from "main:" ? 

    To overcome the above 2 problems, I changed my design to "Not to disable 1st PRU core" by change assembly code to let 1st PRU core to wait on an input pin (similar to disable 1st PRU). I can use 2nd PRU to send out signal to the first PRU via first PRU's input pin, to do a similar job to activate 1st PRU to read ADC parallel data. Both PRUs can be in continuous running condition. System send signal to 2nd PRU to control an input pin in 1st PRU.  

    Problem solved.

    Thank you very much.

    Best Regards,   Jason Chiu.