• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 202 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: Question on ECAP implementation with PRU and EGPI

Keito Katafuchi
Intellectual 295 points
Part Number: AM2434

Tool/software:

Just want to check my understanding.
The AM243x PRG0 PRU1 - if set for EGPI 28-bit Shift-In, the PRG0_PRU1_GPI0 pad is used for the DATAIN.
On the TRM, the remaining GPI1~GPI19 pads are greyed-out (Table 6-412. PRU GPI Signals and Configurations)

Does this mode force the remaining GPI1~GPI19 pads into EGPI mode, so they can't be MUX'd for other functions?
Or is it possible to set the pad that would have been GPI15 or GPI19 for ECAP operation?

According to the Datasheet, PRG0_ECAP0_IN_APWM_OUT is mapped to F3 or M4, which are also the GPI15/GPI19 pads.

  • +1
    TI__Intellectual 1940 points

    When choosing EGPI 28-bit Shift-In mode you cannot use the remaining PRU_GPI1~GPI19 from PRU. This is a limitation inside ICSS. If you choose a different mux mode on padconfig e.g.  mode 10, you can us the PRU to work with ECAP peripheral which is via register interface and not direct PRU_GPIOs .

  • 0 in reply to Thomas Leyrer
    Intellectual 295 points

    I think I got it...will check and post back if I get confused.
    Thanks!

  • 0 in reply to Keito Katafuchi
    Intellectual 295 points

    Hi Thomas,

    I am having trouble with the PRU ECAP0 implementation. (no egpi usage, just setup for ecap)

    I have the following code in assembly:

    main:

init:

    zero &r0, 128
    qba ecap_setup
    
ecap_setup:

    ldi32   r2, 0x001E01EE
    sbco    &r2, c3, 0x28, 4
    
    qba     ecap_loop
    
ecap_loop:
    wbs     r31.b3, 7
    halt

    Then when running in CCS I use Memory Browser w/ PRU1 core to check PRU_Device_Memory at 0x00030000

    I see the counter running continuously at offset 00h.
    I see the PID value 44D22100h at offset 5Ch.
    I also see the value I wrote to ECAP_ECCTL2_ECCTL1 at offset 0x28.

    I believe I setup operation for CAPTURE, CONTINUOUS, enabled the counter and reset/re-armed mod4, and enabled loading of capture events to cap registers. I set it up so cap1~cap4 is rising, falling, rising, falling -> then since continuous goes back to rising, falling, rising, falling...and I used CTRRSTn = 1 so after each event/timestamp the counter should reset, so I can get the time between edges.

    I expect to see capture values appearing at offsets 8h, Ch, 10h and 14h on each edge, but the registers and continuously blank = 0x00000000.

    I am using the LP-AM243x with a 6MHz square wave applied to J6.59 (J6.2) as shown in the launchpad schematics.

    Am I missing something...?

    PS: I also have syscfg configured so in the PRU (ICSS) settings I have PRU (ICSS) ECAP enabled, and the IN_APWM pin set to M4

  • +1 in reply to Keito Katafuchi
    Intellectual 295 points

    Nevermind. I stupidly forgot I needed to tick the "Rx" box in syscfg when setting up M4 as the PRU1 ECAP0 input.

    Problem solved!