• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 312 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.

AM2634: SysCfg Configuration for EQEP Signal Source from Device Pin

Matthew Mascioli
Prodigy 10 points
Part Number: AM2634
Other Parts Discussed in Thread: SYSCONFIG

Hello, I think I've found an issue with the SysCfg tool in CCS version 12.1.0.00007 with the AM2634 running SDK version 08.05.00.24.

I'm trying to use the EQEP0 module with ABI Encoder signals appearing on GPIO pins.

If I configure the QEPA, QEPB, QEPI signal sources to "Signal comes from Device Pin" (0x01), this doesn't yield a change in count in the EQEP module. 

I was able to get the counter to behave correctly if I started out with the QEPA, QEPB, QEPI signal sources to "Signal is 0" (0x00) and then manually changing the QEPSRCSEL register with the debugger to "Signal comes from Device Pin" (0x01).

The only difference I noticed is in the IOMUX_EQEP0_CFG registers. If I start with QEPA, QEPB, QEPI signal sources to "Signal is 0" (0x00), this results in the IOMUX_EQEP0 CFG Registers set by SysCfg to a value of 0x00000508, which turns off the overrides and is FUNC_SEL = 0x8. If I start with QEPA, QEPB, QEPI signal sources to "Signal comes from Device Pin" (0x01), the IOMUX_EQEP0 CFG Registers are modified by SysCfg to a value of 0x000005F7.

Screenshots are below.

/cfs-file/__key/communityserver-discussions-components-files/908/EQEP-SysConfig-Setup-Issue.png

Thanks!

  • 0
    TI__Mastermind 29388 points

    Hi Matthew,

    Thanks much for the feedback. I'll review you findings and get back with you shortly.

    Regards,
    Frank

  • 0
    TI__Mastermind 29388 points

    Hi Matthew,

    I'm unable to reproduce this behavior.

    I experimented with changing the EQEQ_A,B,I signal source select in the SDK EQEP frequency measurement example: https://software-dl.ti.com/mcu-plus-sdk/esd/AM263X/08_05_00_24/exports/docs/api_guide_am263x/EXAMPLES_DRIVERS_EQ

    By default, the signals selections are set for "Signal is 0". In this case, I see as below.

    Sysconfig generated code:

    Drivers_eqepOpen():
    EQEP_SourceSelect sourceSelect;
    sourceSelect.sourceA = EQEP_SOURCE_ZERO;
    sourceSelect.sourceB = EQEP_SOURCE_ZERO;
    sourceSelect.sourceIndex = EQEP_SOURCE_ZERO;
    EQEP_selectSource(CONFIG_EQEP0_BASE_ADDR, sourceSelect);

    EQEP_QEPSRCSEL after execution of EQEP_selectSource(): 0x5027006C: 0x00000000

    IOMUX:

    • U18 0x53100084  00000508 => EQEP_A
    • T18 0x53100088  00000508 => EQEP_B
    • N18 0x5310008C  00000508 => EQEP_I

    I changed the signal source selections as follows:

    • EQEP_A: Signal comes from device pin
    • EQEP_B: Signal comes from device pin
    • EQEP_I: Signal comes from PWM Xbar out 0

    In this case, I see as below.

    Sysconfig generated code:

    Drivers_eqepOpen():
    EQEP_SourceSelect sourceSelect;
    sourceSelect.sourceA = EQEP_SOURCE_DEVICE_PIN;
    sourceSelect.sourceB = EQEP_SOURCE_DEVICE_PIN;
    sourceSelect.sourceIndex = EQEP_SOURCE_PWMXBAROUT0;
    EQEP_selectSource(CONFIG_EQEP0_BASE_ADDR, sourceSelect);

    EQEP_QEPSRCSEL after execution of EQEP_selectSource(): 0x5027006C: 0x00020101

    IOMUX:

    • U18 0x53100084  00000508 => EQEP_A
    • T18 0x53100088  00000508 => EQEP_B
    • N18 0x5310008C  00000508 => EQEP_I

    I can debug further if you can sahre an example code with me demonstrating the problem.

    Regards,
    Frank

  • 0 in reply to Frank Livingston
    Prodigy 10 points

    Hi Frank,

    Thanks for looking into this! I've noticed a few differences your example's configuration. I'll try them out on my own and see if that makes a difference.

    I'm using B14/A14/D11 for the A/B/I source pins as U18/T18/N18 are used by the ethernet configuration in my project.

    I'll let you know where I get to.

    Thanks!

    Matt

  • 0 in reply to Frank Livingston
    Prodigy 10 points

    Hi Frank, I think we've found the issue and settled on a solution. It looks like it was a multicore resource conflict.

    Initializing multiple cores at the same time caused an unpredictable behaviour in multiple places involving I/O pins. Since serializing all the core initializations (using Sync_Set, Sync_Wait), we haven't had any more issues.

    Matt

  • 0 in reply to Matthew Mascioli
    TI__Mastermind 29388 points

    Hi Matt,

    Thanks for taking the time to share your feedback.

    Regards,
    Frank