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 issue

Other Parts Discussed in Thread: TMS320VC5501

Hello,

I've configured my McBSP as a serial master to read/write data from a USB host controller. It works most of the time, but occasioncally I have an issue where the transmit clock stops working alltogether. If I try to send data, the transmit clock does not change at all and it is as if the clock logic is broken. I know that internally, the McBSP is still running it's clock generator, because when I turn of clock-stop mode, I can see the correct clock waveform being outputted.

Any idea as to what the issue is?

Here is my initialization code:

void mcbsp_init() {

// Initialize for transfer with MAX3421E
gpio_set(GPIO_3, GPIO_LOW); // Put MAX3421 in reset


// First set up channel 0
SPCR1_0 = 0x1800; // Make sure McBSP receiver is in reset
// Right justify, fill zeros, MSB first
// Clock stop mode with half-cycle delay
// Send RINT when RRDY toggled to 1

SPCR2_0 = 0x0200; // Free run (emulation does not affect McBSP)
// Send XINT when XRDY toggles to 1
// Make sure McBSP transmitter is in reset

RCR1_0 = 0x0040; // 1 frame per receive (1 word)
// 16 bits per word

RCR2_0 = 0x0001; // Single phase frame
// 1-bit data delay after sync

XCR1_0 = 0x0040; // 1 frame per transmit (1 word)
// 16 bits per word

XCR2_0 = 0x0001; // Single phase frame
// 1-bit data delay after sync

SRGR1_0 = 0x00FE; // Divide input clock by 255 to generate CLKG

SRGR2_0 = 0x2000; // Take clock from either internal input clock or CLKX

PCR_0 = 0x0a0d; // Set as master in SPI protocol. Sample rate generator drives internal transmit/receive clock.

wait_cycles(0x28); // Repeat NOP for a bunch of cycles to wait till McBSP configured

SPCR1_0 = 0x1801; // Enable receiver

SPCR2_0 = 0x02C1; // Enable transmitter
// Enable frame sync logic
// Enable sample rate generator

// Next, set up channel 1
SPCR1_1 = 0x1800; // Make sure McBSP receiver is in reset
// Right justify, fill zeros, MSB first
// Clock stop mode with half-cycle delay
// Send RINT when RRDY toggled to 1

SPCR2_1 = 0x0200; // Free run (emulation does not affect McBSP)
// Send XINT when XRDY toggles to 1
// Make sure McBSP transmitter is in reset

RCR1_1 = 0x0040; // 1 frame per receive (1 word)
// 16 bits per word

RCR2_1 = 0x0001; // Single phase frame
// 1-bit data delay after sync

XCR1_1 = 0x0040; // 1 frame per transmit (1 word)
// 16 bits per word

XCR2_1 = 0x0001; // Single phase frame
// 1-bit data delay after sync

SRGR1_1 = 0x00FE; // Divide input clock by 255 to generate CLKG

SRGR2_1 = 0x2000; // Take clock from either internal input clock or CLKX

PCR_1 = 0x0a0d; // Set as master in SPI protocol. Sample rate generator drives internal transmit/receive clock.

wait_cycles(0x28); // Repeat NOP for a bunch of cycles to wait till McBSP configured

SPCR1_1 = 0x1801; // Enable receiver

SPCR2_1 = 0x02C1; // Enable transmitter
// Enable frame sync logic
// Enable sample rate generator


// Setup is almost done
gpio_set(GPIO_3, GPIO_HIGH); // Take MAX3421 out of reset
wait_cycles(0xF); // Repeat NOP for a bunch of cycles to wait till McBSP configured

// Blind write some data to make sure that receiver has correct bits set
mcbsp_blind_write_word(0, 0);

}

  • Another issue I've been having is with the McBSP receiver and it's data buffers. When I run code to clear the buffers and get the data, it only clears occasionally, and almost never when I am running the debugger without stepping. Once I pause the debugger and step slowly, I am able to read data out of the receive FIFO and the RRDY bit toggles. This is a pretty big issue because of how my writes are blocked... here are my read/write functions:

    bool mcbsp_recv_full(bool dev) {

    if(dev == 0) {

    return (SPCR1_0 & RFULL)!=false;
    }
    else{

    return (SPCR1_1 & RFULL)!=false;
    }
    }

    bool mcbsp_trans_empty(bool dev) {

    if(dev == 0) {

    return (SPCR2_0 & XEMPTY)!=false;
    }
    else{

    return (SPCR2_1 & XEMPTY)!=false;
    }
    }

    bool mcbsp_recv_ready(bool dev) {

    if(dev == 0) {

    return (SPCR1_0 & RRDY)==false;
    }
    else{

    return (SPCR1_1 & RRDY)==false;
    }
    }

    bool mcbsp_trans_ready(bool dev) {

    if(dev == 0) {

    return (SPCR2_0 & XRDY)!=false;
    }
    else{

    return (SPCR2_1 & XRDY)!=false;
    }
    }

    char mcbsp_read_word(bool dev) {

    if(dev==0) {

    return DRR1_0 & 0xFFFF;
    }
    else {
    return DRR1_1 & 0xFFFF;
    }
    }


    bool mcbsp_write_word(bool dev, char data) {

    while(mcbsp_trans_ready(0) == false) { }

    while(mcbsp_recv_ready(0) == false) { mcbsp_read_word(dev); }

    if(dev==0) {

    DXR1_0 = data & 0xFFFF;
    }
    else {
    DXR1_1 = data & 0xFFFF;
    }
    }

    bool mcbsp_blind_write_word(bool dev, char data) {

    while(mcbsp_trans_ready(0) == false) { }

    if(dev==0) {

    DXR1_0 = data & 0xFFFF;
    }
    else {
    DXR1_1 = data & 0xFFFF;
    }
    }

  • Hi,

    Which C5000 device are you using?

    Regards,

    Hyun

  • I'm using the TMS320VC5501

  • I'm still having this issue and it's proving to be quite troublesome as I cannot debug further without solving this basic bug. There doesn't seem to be anything wrong that would cause such a problem to arise. What I see is that reading DRR1_0 only clears RRDY in SPCR1_0 sometimes. This causes my program to run in an infinite loop reading and checking to see if RRDY has been deasserted due to the reads. The only way to fix it is to manually step through the code while my memory browser is open to that address so that the emulator reads it and the bit ends up getting cleared.

    It is true that reading DRR1_0 multiple times should clear this bit, right?

  • Hi,

     Are you opened memory read panel in the debugger? Step through debugging may read registers by CCS. I think that there is a synchronization on reading mechanism.

    Is your code based on example or developed by your own? One time reading DRR1_0 should clear the ready bit.

    Regards,

    Hyun

  • Yes, the memory read panel in the debugger is the one I was talking about. When I don't have it open and I run my code to debug, sometimes it gets stuck and isnt able to clear RRDY by reading DRR1_0.

    My code is developed by myself, but it is very simple so I don't know how to could have occured...

    Do you think that stepping through debugging is causing the error? The loop reads DRR1_0 until RRDY is cleared so it should eventually finish even if it's debugging?