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.

重置MCBSP TX需要重新配置MCBSP嘛?

现在项目上遇到一个问题,MCBSP在发送时会出现发送欠载的情况,看tony哥给其他人的回复需要重置mcbsp才行。

我的板子上面mcbsp都使用PINGPONG,收发都一直需要工作着,帧同步和位同步时钟都是从模式,而且MCBSP的收发帧同步都是跟它通讯的外部芯片的同一个管脚分出来的,如果需要重新配置MCBSP的话就要重新打开BFIFO,但是BFIFO得打开必须在没有时钟的情况下(测试过先配置外部芯片产生帧同步和位同步再打开FIFO时无法工作),所以如果要重新配置的话那外部芯片,MCBSP的收发都要重新配置了;

看到手册上说重置发送的话只要重新复位和置位SPCR寄存器的XRST位就可以,但是测试过这样子MCBSP的发送工作不起来,请问tony哥或者遇到这个问题的工程师们有没有重置MCBSP发送,但不重新配置MCBSP的成功案例?

  • 你说的是这个问题吧。按TRM上的建议处理就可以了:

    26.2.12.2 Special Case: External Device is the Transmit Frame Master
    Care must be taken if the transmitter expects a frame sync from an external device. After the transmitter
    comes out of reset (XRST = 1), it waits for a frame sync from the external device. If the first frame sync
    arrives very shortly after the transmitter is enabled, the CPU or EDMA controller may not have a chance to
    service the data transmit register (DXR). In this case, the transmitter shifts out the default data in the
    transmit shift register (XSR) instead of the desired value, which has not yet arrived in DXR. This causes
    problems in some applications, as the first data element in the frame is invalid. The data stream appears
    element-shifted (the first data word may appear in the second channel instead of the first).
    To ensure proper operation when the external device is the frame master, you must assure that DXR is
    already serviced with the first word when a frame sync occurs. To do so, you can keep the transmitter in
    reset until the first frame sync is detected. Software is setup such that it will only take the transmitter out of
    reset (XRST = 1) promptly after detecting the first frame sync. This assures that the transmitter does not
    begin data transfers at the data pin during the first frame sync period. This also provides almost an entire
    frame period for the DSP to service DXR with the first word before the second frame sync occurs. The
    transmitter only begins data transfers upon receiving the second frame sync. At this point, DXR is already
    serviced with the first word.
    26.2.12.2.1 How to Detect First Frame Sync
    Although the McBSP is capable of generating an interrupt to the CPU upon the detection of frame
    synchronization (XINTM = 2h and/or RINTM = 2h in the serial port control register (SPCR)), the McBSP
    requires the associated portion (receiver/transmitter) of the McBSP to be out of reset in order for the
    interrupt to be generated. Therefore, instead of directly using the McBSP interrupt to detect the first frame
    sync, you can use the GPIO peripheral. This can be achieved by connecting the frame sync signal to a
    GPIO pin. Software can either poll the GPIO pin to detect the first frame sync or program the GPIO
    peripheral to generate an interrupt to the CPU upon detecting the first frame sync edge. For more
    information on the GPIO peripheral, see the General-Purpose Input/Output (GPIO) chapter.
    The following are some recommended GPIO pin(s) on the device that you can use to detect the first
    McBSP external frame sync:
    • GPIO pin located near the McBSP pins. Connect the external frame sync to both the McBSP
    FSX/FSR pin(s) and the dedicated GPIO pin.
    • GPIO pin multiplexed with the McBSP FSX signal. Note that on the device, the GPIO pins (of the
    GPIO peripheral) are multiplexed with the McBSP pins. Software can program the device's pin
    multiplexing register (PINMUX) to default these pins to the GPIO function, and only switch them to the
    McBSP function upon detecting the first frame sync. This method is only recommended if the external
    device is both the frame sync and clock master; that is, the external device drives both the FSX and
    CLKX signals. This method is not recommended if the McBSP is the clock master (driving CLKX
    and/or CLKR), as the “on-the-fly” pin multiplexed switching can cause a glitch on the CLKX/CLKR pin.
    For more details on pin multiplexing, see the device-specific data manual.