• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 84 subscribers
  • Views 901 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.

TMS320F28069M: Serial Communication Issues

Dave Reagan
Intellectual 800 points
Part Number: TMS320F28069M
Other Parts Discussed in Thread: DRV8301

Hello,
We have a PCB we’ve designed, with the objective of using InstaSpin to control a BLDC motor. The micro we’re using is the TMS320F28069M. I have to communicate with an LCD, using a UART at 115.2 kBAUD, 8 bits, one stop bit, no flow control, or other fancy stuff. So, I’ve been trying out some of the examples provided by TI. The loopback example works perfectly. Running the Echo Back example, however, I received only gibberish, using RealTerm, or TeraTerm as the terminal program. At first, I thought that the USB to Serial Converter was at fault (it was not explicitly supported in Windows 10). I got a new USB to Serial but got the same results. Now I’m going straight into a genuine serial port on a machine that (luckily) has one. Still the same thing…
I pared the Echo Back example down little by little, so that now I’m using it to just transmit a single character repeatedly, at 9600 BAUD, rather than the original 115.2K.
You can see in the scope output in the attached files, that the output is as expected, and is at the appropriate BAUD rate. I see this over and over for every character I try to transmit. At one point I was thinking it might be a big-endian vs. little-endian issue, but you’ll see in the attached word document that this is not the case. Using Code Composer, I can monitor the value of "msg", the variable in which the eventual output of the serial port is stored, and it is also always what I expect.
One big difference in the way that I’m using Echo Back is that I’m trying to transmit and receive using the B Serial Port, and the example is set up for the A Serial Port. The pins for the A port are just not available to me, as they are being used for something else.

I've tried every possible permutation (I think) of settings in RealTerm, and this is just driving me crazy that such an apparently simple process should come out so wrong.
I’ve provided the .c files that I’m currently using for this example project (including the alterations I’ve made). If you need any of the .h files, please let me know.

Outputs.zip

Thanks,
Dave

  • 0
    TI__Expert 4145 points

    Hi,

    Can you verify of what is the position of SW3 (TRST/ ISO SCI communication signal enables). Is the communication happening through  FTDI – FT2232 chip?

    1780.qsg_hw_cncd28069miso.pdf

    As you are saying the scope output is as expected including the baudrate, the issue seems to be how the host pc is interpreting it.

    Have you tried with CCS serial monitor (debug session -> view ->  terminal -> serial terminal)

    Regards,

    Yashwant

  • 0 in reply to Yashwant Temburu1
    Intellectual 800 points

    Hi Yashwant,

    This board is a (somewhat) original design. Most of it was lifted from the DRV8301 evaluation kit. There is no SW3. I've attached the relevant page of the schematic. I have not tried using the CCS serial monitor. I'll try that today.

    I agree that the issue seems to be one of interpretation on the receiving end. I've tried this with two PCs (both of them Windows 10).

    I've also tried connecting those 2 PCs, using RealTerm, and the communication is flawless.

    Note: The schematic shows the RS232 signal being converted to RS485. I started off using the RS485 signal, run through an RS485 to RS232 converter, to talk to the PC. When I noticed the garbled output, I started using the signal straight off the microcontroller. Maybe I'm making the issue worse by using the wrong levels for RS232 (0 to 3.3V), but I was seeing the same thing when using the converter.

    Strange - it was easy to include an attachment in my original message, but now in a reply I can't seem to find how to do it...

    For now, I'll send this without the schematic page attached. If you need to see it, please let me know how to send it to you.

    Thanks,

    Dave

  • 0 in reply to Dave Reagan
    TI__Mastermind 25800 points

    Hi Dave,

    Please let us know the outcome after you have tried the CCS serial monitor.

    Best Regards,

    Marlyn

  • 0 in reply to Marlyn Rosales Castaneda20
    Intellectual 800 points

    Hi Marlyn & Yashwant,

    Well that's weird. I posted yesterday about the output of the serial monitor. Now it's gone...

    Anyway, when I send CCCCCCCCC, etc..., the CCS Serial monitor puts out yyyyyyyyyyy, etc..., which is 79hex, the same thing RealTerm displays.

    I also tried going through the RS485 converter on board my PCB, then through an RS485 to RS232 converter to communicate with the PC. The reasoning being that perhaps the computer's serial port was misinterpreting the data it received because it was at the wrong voltage levels. I got the exact same results as I do when I take the output directly from the Serial Port output. The only reason I ended up using the output directly from the Serial Port B output pins was that the output was garbled, and I was thinking that maybe the converters were messing it up. That is not the case.

    To summarize -

    Loopback works fine. The F28069 interprets a "C" sent as a "C" received, as long as the device is talking to itself.

    When I try to receive the serial output on some other device, the message is garbled. This is true for 2 different Windows 10 machines. And it is true for any terminal program I use (including when I look at it using CCS Monitor).

    At first glance, it appears as though the output is inverted and the order reversed, but not every character is treated that way (see the zip file I attached to the original post). When I look at it with the scope, it looks fine - the BAUD rate, the signal quality, and the message itself are all as expected. The endianness of the message may not be what the Terminal program expects, but RealTerm can supposedly read big-endian or little-endian input (just select or deselect the "BigEndian" checkbox). In any case, endianness would only account for the difference in bit order, and not the anomalies in bit value.

    The next thing I'm going to try is using Port A, since the echoback example is set up that way.

    Maybe I missed something when setting it up as Port B.

    Thanks,

    Dave

  • 0 in reply to Dave Reagan
    TI__Mastermind 25800 points

    Hi Dave,

    This is a strange issue. I have looked through the code that you have provided and nothing stands out. Please let us know the status once you configure SCI-A.

    You mentioned that the loopback worked okay. Did you confirm this by using the loopback example? This type of loopback is internal to the device. As another check I would run the loopback example but disable the loopback bit and then connect the tx/rx pins to actually create an external loopback where the signals make it to the pins and back. If this works and the device reads the correct values then I think you can rule out any issues with the pins/device.

    Best Regards,

    Marlyn

  • 0 in reply to Marlyn Rosales Castaneda20
    Intellectual 800 points

    Hi Marlyn,

    Yes - I went through the loopback example, but did not try actually connecting Tx & Rx. I'll do that, and let you know the results of both that experiment and the SCI-A.

    Thanks,

    Dave

  • 0 in reply to Dave Reagan
    Intellectual 800 points

    Hi Marlyn,

    I think I've gotten to the source of the problem. What I thought was an RS485 to RS232 converter is not. It's a 485 to straight serial data for talking direct to the serial ports on a micro. RS232 is negative logic, including the START and STOP bits. When I looked closely at the data, it looked like the terminal program (or something) was inverting everything, then treating the STOP bit like a START bit, and the START bit like data. It finally dawned on me that if literally everything is inverted, it's probably the fact that the PC's serial port expects everything in proper RS232, and that wasn't what I was sending. Likewise for when I was connecting the output of the micro's serial port directly to the RS232 to USB converter. The micro doesn't put out data in RS232 format. I've got some RS232 driver chips. I'll run the signal from the micro through a breadboarded ckt using one of those for now. I've also ordered an RS485 to USB converter. Such an embarrassing mistake! Sorry to have wasted your time. Let's consider this ticket closed. Thanks for your help!

    Best Regards,

    Dave