• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 1184 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.

eCAP on BBB AM3359 not capturing, even when forced

Brandon Matthews
Prodigy 70 points

Other Parts Discussed in Thread: SYSCONFIG, AM3359

After a few days of work, I'm having no luck getting the ECAP module working on my BeagleBone Black running Linux. I've disabled ECAP PWM support in the kernel, and written a brute-force style kernel module to set register values, but I never see the interrupt come down the line.  My module performs the following steps (see below for the resulting register values):

  1. Requests an IRQ using request_irq() with line number 31 (from section 6.3)
  2. Muxes the pin by setting the RXACTIVE bit and mode 0 in register conf_ecap0_in_pwm0_out (9.3.1.51)
  3. Clearing ECEINT
  4. Setting ECCTL1, and ECCTL2 appropriately
  5. Setting the CLR bits in ECCLR
  6. Setting all CEVTx bits in ECEINT
  7. Enabling the module in CM_PER_EPWMSS0_CLKCTRL (8.1.12.1.36)
  8. Enabling the clock in pwmss_ctrl (9.3.1.32)
  9. Setting the "smart" idle mode in register SYSCONFIG (15.1.3.2)
  10. Enabling the ECAP clock in CLKCONFIG (15.1.3.3)
  11. Checking the eCAP_CLK_EN_ACK value in CLKSTATUS

I've built some debugging output into the __init, and here's its output:

[ 8692.061879] The ecap hello-worldish module is loading.
[ 8692.068204] CM_PER_EPWMSS0_CLKCTRL:  0x00000002
[ 8692.068224] pwmss_ctrl:      0x00000007
[ 8692.068236] CM_PER_L4LS_CKLSTCTRL:   0x00004102
[ 8692.068248] CM_PER_L4LS_CLKCTRL:     0x00000002
[ 8692.068259] ecap_evt_cap:    0x00000000
[ 8692.068277] PWMSS register values = {
[ 8692.068277]  IDVER:  0x47400001
[ 8692.068277]  SYSCONFIG:      0x00000008
[ 8692.068277]  CLKCONFIG:      0x00000111
[ 8692.068277]  CLKSTATUS:      0x00000111
[ 8692.068277] }
[ 8692.068327] ECAP0 register values ={
[ 8692.068327]  TSCTR:  0x846610ed
[ 8692.068327]  CTRPHS: 0x00000000
[ 8692.068327]  CAP1:   0x00000000
[ 8692.068327]  CAP2:   0x00000000
[ 8692.068327]  CAP3:   0x00000000
[ 8692.068327]  CAP4:   0x00000000
[ 8692.068327]  ECCTL1: 0x00000100
[ 8692.068327]  ECCTL2: 0x00000090
[ 8692.068327]  ECEINT: 0x0000001e
[ 8692.068327]  ECFLG:  0x00000000
[ 8692.068327]  ECCLR:  0x00000000
[ 8692.068327]  ECFRC:  0x00000000
[ 8692.068327]  REVID:  0x44d22100 }
[ 8692.068388] Everything, it seems, would be all right with ecap

I can see in /proc/interrupts that the kernel is looking for interrupts with ID 31, but writing to the ECFRC registers (mmap /dev/mem to the appropriate address), and strobing the pin externally isn't causing my interrupt handler to write anything to dmesg, nor incrementing the count in /proc/interrupts or even the spurious interrupt count. TSCTR is incrementing (I can see it by re-loading my module and watching the output above), but the capture just isn't happening.

I am totally lost here. Does anyone have any avenues I can pursue?

  • 0
    Prodigy 70 points

    This is a happy update, though I'm not 100% there. It turns out that strobing the pins is indeed working, though not completely predictably. I'm using a quick shell script:

    #!/bin/bash

ecap_pin=$((0*32+7)) # GPIO0_7
control_pin=$((3*32+19)) #GPIO3_19
shared_pin=$((3*32+18)) #GPIO3_18

cd /sys/class/gpio

echo $control_pin >> export
echo $shared_pin >> export
echo out >> gpio$control_pin/direction
echo 0 >> gpio$control_pin/value
echo in >> gpio$shared_pin/direction

echo 1 >> gpio$control_pin/value
echo 0 >> gpio$control_pin/value

echo $control_pin >> unexport
echo $shared_pin >> unexport

    I have pins P9.27 and P9.42 jumpered on the BBB. Running my script and reloading the module repeatedly gives me output in the CAP registers:

    [   83.788734]  CAP1:   0xc168c2b5
[   83.788734]  CAP2:   0x2836fddb
[   83.788734]  CAP3:   0x6f0451c4
[   83.788734]  CAP4:   0x94db670e

    Still no interrupt call or spurious interrupts reported, and the capture doesn't always happen in the register I expect it to.

    Forcing an interrupt by writing to ECFRC still doesn't trigger a capture nor an interrupt.

  • 0 in reply to Brandon Matthews
    TI__Guru**** 393215 points

    What Linux version are you using? Please note that this forum supports only the TI distributed EZSDK. For other versions please turn to the community at http://beagleboard.org/Community/Forums.

  • 0 in reply to Biser Gatchev-XID
    Prodigy 70 points

    Hi Biser,

    I'm running 3.8.13-00729-g8a94e04 with RCN's patch set, which, I suppose, isn't actually supported. Damn.

    Can we just pretend I'm using the EZSDK? :) I suspect my problem lies with some registers in the interrupt controller not being set up correctly, but since I can find exactly zero ECAP example code (even in StarterWare), I'm pretty much flummoxed.

    Regards,

    B

  • 0 in reply to Brandon Matthews
    Prodigy 70 points

    Oh dear. Well, under

    Linux am335x-evm 3.2.0 #1 Tue Jun 25 16:40:47 CDT 2013 armv7l GNU/Linux

    It seems to interrupt just fine.

    It makes me a bit sad that there's no path forward that supports the device tree, but I suppose you go to war with the army you have.

    Is there any roadmap or plan for TI supporting a newer kernel version on the AM3359?

  • 0 in reply to Brandon Matthews
    TI__Guru**** 393215 points

    Yes, the next SDK will be based on kernel v3.12. Release is scheduled for 1Q14.

  • 0 in reply to Brandon Matthews
    Prodigy 10 points

    hello Brandon Matthews, recently i want to use the eCAP, but i can not find a driver on the internet, seeing the post from you, can you send the driver to me ? thank you so much! yu1019594136@gmail.com/yu1019594136@163.com/1019594136@qq.com