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.

AM335x broken of internal of PRU

Guru 10570 points
Other Parts Discussed in Thread: AM3356

Hello,

I have encountered PRU broken issue.
In our 3 target boards, AM3356 ZCZ package [R12] pin is broken for some reason.

And, system block is like below.
[R12] pin is used as DIO output (pr1_pru0_pru_r30_15).

AM3356's PRU DIO output[R12] ----> Resistor 330ohm ----> other device(5V power).

Phenomenon:
- When u-boot is booted up and configure the pinmux as PRU, the [R12] pin broke.
After that,
- After reset, [R12] drives Low(It is same as datasheet spec). Then, [R12] pin drives high when pinmux is set as PRU.

I am assuming that it does Not I/O broken, it might be broken of internal of PRU.

I would like to find any wrong in our system.
Do you have any idea for debugging?
Or, can you provide me equivalent circuit or hint of PRU?

If you need any other informations, please let me know.
I am appreciate any trivial informations.

Best regards, RY

  • Hi RY,

    First you should check that the other 5V device does not bias the pin to a voltage higher than the VDDSHVx from which it is supplied. AM335X I/O pins are not fail-safe.

  • Biser-san,

    Thanks for your response.
    I think so. Although we checked voltage higher than VDDSHVx, we could not see it.

    So, we assume IO pad is not broken. Because the [R12] drives Low after reset. (It's correct operation.)
    However, PRU drives high after pinmux configuration, It's strange. we assume PRU module is broken.

    How do you think?
    Do you know the case PRU is broken?
    Where can I find PRU's absolute maximum ratings?

    Best regards, RY

  • Which pin is it finally? In your first post you talk about R12. Now you talk about R13. What is the processor package - ZCZ or ZCE? And have you checked that there is no pullup enabled in the pinmux?

  • Biser-san,

    I'm sorry.
    - R12 is correct.
    - Processor package is ZCZ.
    - I have checked R12 is pulled down. But, it drives high.

    Best regards, RY

  • Is PRU register R30 initialized? Is pin R12 pinmuxed to mode 6? If you remove the 330Ohm register do you see the same behavior with pin R12 floating?

  • Biser-san,

    Thanks. I'll check it.

    Best regards, RY

  • Biser-san,

    I found:
    R30 register is NOT initialized (not zero) after release of PRU reset.
    It causes the R12 drives high.
    Thanks for your support!

    In our system, we expect R12 drives low during system initialization.
    So, I would like to clear R30 to zero before pinmux configuration.
    And, we could see R12 maintains low by oscilloscope in our exam.

    Question)
    - Can you see any violations about below sequence? (pinmux is configured after PRU reset)
    - If you have recommendation to place the PRUSS initialization code, please let me know.

    Our workaround)
    a) u-boot code
      /board/ti/am335x/mux.c
      void enable_board_pin_mux(struct am335x_baseboard_id *header)

        // PRU initialization code
        writel(0x2, 0x44e00c00); // PRU reset
        writel(0x0, 0x44e00c00);
        writel(0x2, 0x44e000e8); // PRU enable
        writel(0x2, 0x44e00c00); // PRU reset
        writel(0x0, 0x44e00c00);
        writel(0x0, 0x4a322478); // PRU0 r30 clear (output low)
        writel(0x0, 0x4a324478); // PRU1 r30 clear (output low)

        Then, pinmux is configured.

    b) kernel code
      /arch/arm/mach-omap2/board-am335xevm.c
      static void setup_general_purpose_evm(void)

      we would like to insert same sequence.

    Best regards, RY

  • If it works I can't see a reason not to use it.


  • Biser-san,

    Thanks for your comment!

    I have read TRM PRUSS section.
    and I can not see R30 is initialized after reset.
    It seems the spec of AM335x PRUSS. right?

    My customer says R30 must be initialized.
    Because if it drives high, conflict in outside PRUSS may happen, and system will be broken.

    If you do not think it is restriction (just spec), and R30 is not initialized, PRUSS initialization sequence should be exist in TRM.

    Here is proposals. Can you consider to add following Note in TRM PRUSS section?

    Note: R30 may not be initialized after reset. To avoid outside effect, R30 should be initialized before PINMUX configuration.

    Best regards, RY

  • You can use the "Submit documentation feedback" link at the bottom of each page in the PDF document to reach the TRM team directly.

  • did this work?

    we are not using the EVM,  so the generic board file is built which does not have this init call.  Is there another spot that would be good for this operation?

    In our case,  we need to initialize PRU0_R30 to 4

    Thanks!

    Bob Bailey