• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 336 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.

TMS320F28388D: SysConfig Resource Conflict When Using QEP2 via PWMXBAR and SCIB on Same GPIOs

Allen Jiang
Prodigy 30 points

Part Number: TMS320F28388D
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hi TI team,

I’m working on a test using the F28388D controlCARD and encountered a potential SysConfig issue when combining QEP2 and SCIB functionality on shared GPIOs.

Test Setup:

I routed the ABI signals from GPIO60, 58, and 59 via PWMXBAR to QEP2. In SysConfig, I configured QEP2 inputs to use GPIO54 (A), GPIO55 (B), and GPIO57 (Index). At the same time, I wanted to use GPIO54 and GPIO55 for SCIB_TX and SCIB_RX, respectively.

Issue:

When assigning SCIB_TX and SCIB_RX to GPIO54 and GPIO55 in the SysConfig SCI module, I receive a resource conflict error and the project fails to build.

 [Image 1: SCI resource conflict]

 [Image 2: EQEP2 via PWMXBAR configuration]

Observation:

If I manually configure GPIO54 and GPIO55 for SCIB after calling Board_init(), the project builds and both QEP2 and SCIB functions work correctly at runtime.

Here’s the relevant code after Board_init():

// SCIB GPIO manual setup
GPIO_setPinConfig(GPIO_55_SCIB_RX);
GPIO_setPadConfig(55, GPIO_PIN_TYPE_STD | GPIO_PIN_TYPE_PULLUP);
GPIO_setQualificationMode(55, GPIO_QUAL_ASYNC);

GPIO_setPinConfig(GPIO_54_SCIB_TX);
GPIO_setPadConfig(54, GPIO_PIN_TYPE_STD | GPIO_PIN_TYPE_PULLUP);
GPIO_setQualificationMode(54, GPIO_QUAL_ASYNC);

// SCIB initialization
SCI_clearInterruptStatus(SCIB_BASE, SCI_INT_RXFF | SCI_INT_TXFF | ... );
SCI_clearOverflowStatus(SCIB_BASE);
SCI_resetTxFIFO(SCIB_BASE);
SCI_resetRxFIFO(SCIB_BASE);
SCI_resetChannels(SCIB_BASE);
SCI_setConfig(SCIB_BASE, 50000000, 115200, (SCI_CONFIG_WLEN_8 | SCI_CONFIG_STOP_ONE | SCI_CONFIG_PAR_NONE));
SCI_disableLoopback(SCIB_BASE);
SCI_performSoftwareReset(SCIB_BASE);
SCI_setFIFOInterruptLevel(SCIB_BASE, SCI_FIFO_TX0, SCI_FIFO_RX0);
SCI_enableFIFO(SCIB_BASE);
SCI_enableModule(SCIB_BASE);

And PWMXBAR routing:

XBAR_enableEPWMMux(XBAR_TRIP4, XBAR_MUX01);
XBAR_setInputPin(INPUTXBAR_BASE, XBAR_INPUT1, 60);
XBAR_setEPWMMuxConfig(XBAR_TRIP4, XBAR_EPWM_MUX01_INPUTXBAR1);

XBAR_enableEPWMMux(XBAR_TRIP5, XBAR_MUX03);
XBAR_setInputPin(INPUTXBAR_BASE, XBAR_INPUT2, 58);
XBAR_setEPWMMuxConfig(XBAR_TRIP5, XBAR_EPWM_MUX03_INPUTXBAR2);

XBAR_enableEPWMMux(XBAR_TRIP7, XBAR_MUX05);
XBAR_setInputPin(INPUTXBAR_BASE, XBAR_INPUT3, 59);
XBAR_setEPWMMuxConfig(XBAR_TRIP7, XBAR_EPWM_MUX05_INPUTXBAR3);

Questions:

  1. Is this a known SysConfig limitation or bug?

  2. When routing signals to QEPx using PWMXBAR, should the corresponding QEPx GPIOs remain available for other peripheral muxing?

  3. Is manually overriding the muxing after Board_init() the recommended workaround in such a case?

Thanks in advance for your support!

XBAR_ENABLEEPWMMUX（XBAR_TRIP4，XBAR_MUX01）;
xbar_setInputpin（inputxbar_base，xbar_input1，60）;
XBAR_SETEPWMMUXCONFIG（XBAR_TRIP4，XBAR_EPWM_MUX01_INPUTXBAR1）;

XBAR_ENABLEEPWMMUX（XBAR_TRIP5，XBAR_MUX03）;
XBAR_SETINPUTPIN（inputxbar_base，xbar_input2 ...代碼