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.

AM5729: PRU: how to reset to clear all event issues?

Part Number: AM5729

Hi all,

I've seen that at times the PRU is put in a strange state where it won't run code due to a previous issue of maybe interrupts not being cleared, or stack overflow etc.

How does one fully reset the PRU?  I assume its through the power and clock management.

I don't believe rproc_pru does this when stopping and starting firmware.

I've had to resort to restarting the board.

Thanks,

Fisher

  • Hi Fisher,

    Can you provide more details on this ?

    1. Which SDK version are you using ?

    2. Are you looking for a remote proc specific option ?

    I found this function in drivers/remoteproc/pru_rproc.c pru_rproc_start() which writes to the PRU_CTRL_CTRL register. You can write to that using devmem. The register description is also available in TRM. It's called PRU_CONTROL

    I will check for a proper solution internally.

    There is a soft reset bit

    Regards

    Vineet

  • Hi Vineet,

    Thanks for the reply, I'm looking for an option from the Linux side.

    I'm using the Linux SDK, yes, hoping for a RemoteProc solution (or if I may send different parameters to remote proc myself).

    While one may put this register reset value in the first few lines of PRU code, I'm wanting to sort out a solution so that regardless what firmware one runs, Linux can reset the PRU if it acts funny and doesn't run code or react to events.  So, yes, a remoteProc solution would be great.

    I have yet to understand how to use RemoteProc besides echo "start", "stop".  Maybe one can pass other parameters, I've not found much documentation for it.

    Resetting the PRU is to easily debug if the issue is the code, or previous uncleared events.

    I've had a number of experiences where I've thought my interrupts weren't working (even though I had put code to clear them), only to find out that it worked after restarting the board.

    I'm also now having trouble with xin() and xout(), and restarting my board has helped me make progress, but it wastes a lot of time, and I have to set up all my environment variables again.

    Thanks,

    Fisher

  • Hi Vineet,

    This issue relates to a separate post I've put up:

    https://e2e.ti.com/support/processors/f/processors-forum/992869/am5729-pru-how-to-debug-l3-main-errors-and-configure-them

    I'm trying to trace occasional dmesg messages which seem to show the PRU locking up when not running code, or having uncleared events.

    While resetting the PRU fixes it, I put that post up to find out how to trace specifically the issue..

    Thanks,

    Fisher

  • Hi Fisher,

    Re-opening the thread.

    Are you still facing this issue ?

    Regards

    Vineet

  • Hi Vineet,

    Yes, I'm still having this issue, it doesn't occur a lot, but usually when I'm trying to implement a new feature in software.

    It may likely occur when there are interrupts uncleared, but previously, I believe my first experiences were due to heap overflow, and others my be due to many uncleared events/interrupts.

    It's probably best to just use my previously linked thread for this issue if you'd like to just keep it to a single thread as I have more specific information there:

    https://e2e.ti.com/support/processors/f/processors-forum/992869/am5729-pru-how-to-debug-l3-main-errors-and-configure-them

    So it's fine if you'd like to close this thread and just reply to the one I've linked above.

    I suspect that the RemoteProc kernel module may reconfigure IRQ_CROSSBAR for this sort of error, when some form of hardware event has happened that locks up the PRU or some other HW system.  As I mentioned in that link above, the default configuration for that IRQ number goes to PRU IRQ 35 and 36 which are for the IEP.  I've not checked the crossbar settings as I've not had the time yet.  It's been a long time since I've done microncontroller firmware, and each part of this SoC is a totally separate device with at least 100 or 200 pages of documentation.

    If I was working in a team, it would be a lot easier.

    When ever I see this error, I have to restart the board, I've tried your advice for doing a soft reset by adding this command to the first line of main, but it doesn't seem to properly reset the PRU:

    PRU0_CTRL.CONTROL_bit.SOFT_RST_N = 0x0;

    Thanks,

    Fisher