0
\$\begingroup\$

I am working with the TI TM4C MCU. Connected to one UART of this MCU, I have a GSM module or a GPS Module (let's say UART1). I need to establish communication between the MCU and the module by sending some "AT commands" and receiving some replies to verify what the module is doing.

Therefore I need to see what AT commands are sent by the MCU to the module and I need to see what the module replies to the MCU. Of course those commands are defined via C files, but I need to check what is sent when and how and what is received when and how.

I suppose that I can not use CCS to visualize those data flow, correct?

Therefore to achieve this, I am thinking to use MCU UART0 and connect that to my computer, where I use "Tera Term" software to receive a copy of what is sent and received by the MCU on UART1.

I am not an expert in C but I have some notion of it. I found some example of UART use in the TI lab workshop for TM4C, but I am not sure fully about how to implement this "forwarding" (copy like). I think I need to copy the value in the FIFO/ buffer of the UART1 to UART0 and then sent them to UART0.

I am a bit confused about how to operate it.

I would appreciate if someone got experience about it to explain how you usually process to analyze sending and receiving of data via UART, which are not directly linked to a computer terminal.

\$\endgroup\$
4
  • \$\begingroup\$ Are you using TM4C launchpad? \$\endgroup\$
    – Andrejs Gasilovs
    Aug 31, 2016 at 12:36
  • \$\begingroup\$ The best way to sniff a serial bus is to use a logic analyzer, if you have one. \$\endgroup\$
    – Synchrondyne
    Aug 31, 2016 at 18:21
  • \$\begingroup\$ @chris: I've done exactly this for an STM32 and a modem. If you're still interested I can write a proper answer (not exactly for your TI chip but the concept will be the same) \$\endgroup\$
    – user72833
    Sep 30, 2016 at 18:55
  • \$\begingroup\$ @Tibo i would be glad of it \$\endgroup\$
    – chris
    Oct 2, 2016 at 17:30

2 Answers 2

Reset to default
1
\$\begingroup\$

I am not sure fully about how to implement this "forwarding" (copy like)

An (often quicker) alternative to this type of software "forwarding" approach, is to monitor the two signals you mention, directly via hardware.

I'm short of time, so excuse the lack of a diagram at the moment. In brief:

MCU Tx -> GSM module Rx -> Here connect Rx of UART-to-USB adapter 1
MCU Rx <- GSM module Tx -> Here connect Rx of UART-to-USB adapter 2

Note: You only connect the Rx inputs of those two UART-to-USB adapters. Leave the Tx pins of those adapters unconnected.

Then you can monitor (and, although I've forgotten the name at the moment, I'm sure I've used software to merge or view) these two data streams on a PC. You could even run two simultaneous copies of "Tera Term" as you suggested, one opening the PC COM port for UART-to-USB adapter 1; the other opening the PC COM port for UART-to-USB adapter 2.

This avoids adding complexity at the MCU now. You can add this MCU functionality later, if you need to and when you have learned those programming skills. However during development, using hardware monitoring can be a quicker way to achieve the end result (i.e. monitoring those serial data streams) which you want.

\$\endgroup\$
5
  • \$\begingroup\$ This is a possibility but you can actually end up needing 3 serial ports - one to interact with the firmware, and two more to see both sides of its communication with the GSM module. \$\endgroup\$
    – Chris Stratton
    Aug 31, 2016 at 13:43
  • \$\begingroup\$ @ChrisStratton - Hi - Yes, agreed, but I don't find that a problem. It's not like in the old days where "real" serial ports were more limited; with USB we can have lots of them! Do you see things differently? If the OP is struggling with doing the original task in software (I've done UART forwarding code before, but not for that MCU, so I don't know what "gotchas" might apply), then I've offered a quick, alternative approach which I've used successfully many times. It depends what the OP wants more quickly; to actually do the monitoring, or to learn that specific programming :-) \$\endgroup\$
    – SamGibson ♦
    Aug 31, 2016 at 14:09
  • \$\begingroup\$ @ChrisStratton - PS - As I understand the OP's "forwarding" suggestion, that would also add one PC serial port requirement, to receive the forwarded data. Therefore my suggestion only adds one more. :-) Also its worth noting that if the MCU forwarding code is combining 2 datastreams (ie. the send & receive from UART1) into just one stream to UART0 to the PC, then any overlap of send & receive data on UART1 cannot be easily represented in the merged datastream on UART0 and the temporal information is lost. While that may be unlikely, my suggestion does not have that disadvantage. \$\endgroup\$
    – SamGibson ♦
    Aug 31, 2016 at 14:20
  • \$\begingroup\$ Presumably the serial port to be forwarded to is the primary one already used for command/control/monitoring. Note that if you use USB serial converters, the USB polling means you cannot accurately capture the time when something actually happened, to reconstruct a closely intermixed flow. Fortunately most flows are decide to do something -> send -> receive \$\endgroup\$
    – Chris Stratton
    Aug 31, 2016 at 15:01
  • \$\begingroup\$ @ChrisStratton - "Presumably the serial port to be forwarded to is the primary one already used" - Ah, that was not my interpretation. IIRC the data path back via the debug USB link of the TM4C is not UART0 as the OP stated he would use. Hence why we see things differently. "USB polling means you cannot accurately capture the time" - True. My experience is that this timing jitter can be less than the jitter deliberately introduced, when trying to store-and-forward two datastreams to avoid mixing the commands & replies. || I just gave an option for the OP; I didn't say it was perfect :-) \$\endgroup\$
    – SamGibson ♦
    Aug 31, 2016 at 15:15
0
\$\begingroup\$

A totally different approach would be to use a JTAG debugger connection (if you have one) back to the PC - if you don't mind that you wouldn't be using UART0 for the PC connection. (Thanks to Chris Stratton for comments on my other suggestion, which reminded me about this possibility.)

If your TM4C is connected via JTAG to a typical USB-JTAG debugger (I use Segger, but I believe the debugger built-in to the TM4C Launchpad has similar functionality), then you can send simple text strings back to the host, to be displayed in a debugger window (the presentation of the data depends on your PC software & toolchain).

It would be easy to duplicate any sending of data to your UART1 also to the Cortex-M ITM port in the TM4C. A common approach is to write (or use, if already included in your toolchain) a simple printf() routine which writes to the ITM port and can be called like any other C function. Then, when you receive any data from your external GPS/GSM module, your MCU code again uses printf() to send that data to the ITM port and therefore to the PC.

You would need to create some type of encoding to differentiate the "send" and "receive" data, as you printf() both of them to the ITM port e.g. prefix a string sent to the external module with "S:" when you printf() it to the PC, so that on the PC you can see it was Sent to the module. Something similar with characters Received from the module.

This is just another approach, with pros and cons, compared to my previous suggestion, or compared to forwarding to another UART on the MCU. Depending on what you really want to do (i.e. do you really want to learn UART programming, or do you really want to monitor the data you mentioned; do you mind doing some more MCU programming or do you prefer a solution which is mostly hardware and no additional MCU programming), then you have options. As is typical in engineering, there is no single "one size fits all" solution - you have various options, with different compromises, from which you can choose. :-)

\$\endgroup\$
2
  • \$\begingroup\$ I have JTAG setup on TM4C indeed and I have debugger to my disposal: XDS 100 V3.. This is the ITM port tips and trick which I miss :) What I want to achieve is to have a reliable methodology which can allow to develop quickly and efficiently what need to be done :) \$\endgroup\$
    – chris
    Aug 31, 2016 at 17:30
  • \$\begingroup\$ @chris - Thanks for this new information about your debugger. I'm not familiar with the XDS100 V3, but if it doesn't support ITM then obviously this "answer" isn't applicable to you. However my suggestion may be useful for other people with different JTAG debuggers, who read this question in future :-) If speed of development is the most important factor for you, then my other "answer" seems more applicable. \$\endgroup\$
    – SamGibson ♦
    Sep 1, 2016 at 13:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.