• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 82 subscribers
  • Views 946 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.

28377D usb_dev_serial_cpu01

Rob Barton
Expert 2220 points

Other Parts Discussed in Thread: CONTROLSUITE

Running the usb_dev_serial_cpu01 test application on the c28377D board, requires that I change A:SW1 such that I can send data through the com port to GPIO28.

However what I am seeing running the app is the interface through the pure USB port (the one on the long edge) is working perfectly.  I can see the characters I type in the processors memory buffer, when I put a breakpoint in it, and when I manually load data into the buffer through code composer studio it sends that data out through the USB to the com window opened.

Now on the USB_UART side, that is the side that sends data through the UART to the USB part, through the USB on the short side of the board (shared with JTAG) I'm seeing data received, and I'm receiving data after changing A:SW1 to allow reception,... however the data sent out is exactly 64 higher than what is sent... for example if I send a '1' = 49... it receives a 'q' = 113 so 113-49 = 64

similarly if I send a '1' into the part it receives 145.

I have set the baud rate to 115200 8 N 1 as instructed in the code, and verified it at both ends...

Why else might I be experiencing this data mutation?  It's very consistent, so every time I type a 1, I get a q output, and every time I type a 2 I get the next letter etc...  so it's reliably.

I have made no altercations to the code as you ship it as an example,and aside from the above mentioned change of A:SW1 which is necessary, I'm not sure why else I might be observing this 'mutation' of the data.  I am currently using putty as a com package, however I tested this by using MATLAB as well to collect the data, and got the same results, so I don't think its the com package.  Right up to where I send the data to the uart in the code, it has the 'correct/desired' value,  SO i'ts a bit of a mystery as to where the issue is happening, other than it's isolated to between the UART/USB on the short side of the board that is shared with the JTAG.

Any suggestions as to what might be causing this alteration of the data would be appreciated.  Thanks.

  • 0
    TI__Mastermind 32995 points
    It sounds like everything is working as expected on the device.

    Problem is likely your connection or terminal.

    Are you seeing this when you send from the USB and when you send from the UART? or just from the USB?

    sal
  • 0 in reply to Sal Pezzino
    Expert 2220 points

    information asked for:

    Tiv6.4.2 compiler code composer studio

    28377D development board  R4.1 base board

    R1.1 control card

    Example code being used is usb_dev_serial_cpu01 from controlsuite.

    I can't agree that its the connection, because as you know the code composer studio talks to the board to load the program through the same connection, without difficulty, successfully loading the board... as such when the usb_dev_serial code then sends data from it's uart which then gets converted through the ft2232hl to usb, it is only this channel that is being corrupted by some offsets.

    the USB port that does not go through this conversion process is working perfectly, and internally on the part the code is working perfectly...

    As for the terminal program, I start two copies of the same putty, so if the same putty executable works on one, it should work on the other, and I also tried using matlab and read the exact same results that putty was returning.

    Is there anything in the 2232hl that could be configured wrong to cause this selectively on data sent from the 28377D uart port as opposed to data sent via the JTAG to load the part?

    Are there any jumpers or other settings I may be missing to configure the board, as I stated I switched the one jumper to emable the connection to GPIO 28... beyond that I have made no changes to the board.

    Thanks.

  • 0 in reply to Rob Barton
    TI__Mastermind 32995 points
    There should not be any other changes you have to make to the controlCard.

    Can you confirm what is being place in the SCI TXBUF please? Is the data in the TXBUF correct or incorrect?

    sal
  • 0 in reply to Sal Pezzino
    Expert 2220 points
    if(HWREGB(ui32Base + UART_O_CTL2) & UART_CTL2_TXRDY)
    {
    //
    // Write this character to the transmit FIFO.
    //
    HWREGB(ui32Base + UART_O_TXBUF) = ucData;

    //
    // Success.
    //
    return(true);
    }

    Yes at this point in the code ucData is correct (49 decimal for '1' ascii character) and when I use the memory viewer to view 0x7200 + 9 (0x7209) for the SCI TX buffer, after this instruction it indeed loads a HEX 0x31 or 49 decimal. yet at the terminal or matlab whichever I use I receive a 'q' ascii character instead of a '1'. It reliably repeats this every time I send a '1'... and if I send a '2' I of course receive a 'r' etc... it works every time, it is just offset? the same when transmitting the other way, but the offset the other way is different, but consistent.
  • 0 in reply to Rob Barton
    TI__Mastermind 32995 points
    My guess it is something wrong with either
    1) You configuration of the SCI. (number of bits, stop bits, parity bits, mode)
    2) Your terminal configuration.

    If the write data is loaded into the TXBUF, then the program is working correctly.

    I suggest running some internal and external loopback tests if you want to double check that it is not the C28x hardware.

    sal