Debugging RS-232 With Logic Analyzer
Mathilda Gibby
I am using the TX1 and RX1 pins to communicate with a UART device but I am sending a bad command somewhere. So I am trying to debug using a logic analyzer(haven't used one in 25yrs). The only problem is I can't seem get the right data when connected to the transmit line. Does anyone know a good source for figuring out how to set the # of bits, parity and such...I've read a dozen or so wiki pages and understand that the it can be half or full duplex, 8 bit, no parity....it depends on the hardware. The device I have hooked up seems to work, but fails on one command and i just want to see what is actually being sent.
Generally 8 bits, no parity, 1 stop bit.
Do you have a RS223 to USB adapter cable? You can connect your TX pin & ground to the RX pin and ground on the cable and monitor on a PC also, might be easier than a logic analyzer (since what you really want is a protocol analyzer). I have several of these laying around for some reason. I think mine have a Prolific chip in them.
If the above is true... fails on one command -- but not others then how can you have it set wrong? Unless you have tried only one sequence and it always fails in the same place -- then it could be a multitude of issues -- but probably handshaking...
If you have an old PC with two serial ports lying around, there's a Linux app called "scope" that's great for simple protocol analysis. No fancy graphics, but it creates a text log file that makes it easy to see what's going back and forth between the two devices.
Afaik, it's only available in source form (here's the website). So you'd need to run it on a PC with gcc, or use a "compact" distro that makes it easy for you to build custom images on a desktop system. Does Puppy do that? I've used Pebble when I needed a tiny "embedded" Linux, and DSL for "rescue" CDs, but never really researched Puppy.
RS-232 serial interface is still quite widely used in many applications. Usually RS-232 Mini Tester with LEDs for indicating state of different signals is all that is needed to make things work. But sometimes seeing signals with your eyes is not enough for troubleshooting and testing.
There are nowadays cheap logic analyzers (like Saleae Logic and USBEE) that can easily record many channels of fast changing digital signals and even decode the serial data on the line. Those would be ideal tools for serious debugging of RS-232 signals. But those devices have one downside: they are designed only for TTL (5V) and LV-TTL (3.3V) level logic signals. Standard RS-232 signal levels (typically +3..15V and -3..15V, but can be up to +-25V) are too much for those logic analyzers. Connecting logic analyzer directly to RS-232 signal will most probably damage the hardware. So I need some form of converter that can convert RS-232 signals to TTL signals.
One option would be to use several MC1489 Quadruple Line Receiver or MAX232 ICs to do the conversion. The downside is that this need power to operate. Another option that comes to my mind is to use zener diode voltage limiting circuit (resistor and zener diode). I tried that but with the zener diodes the first trials did not give well working implementation.
I ended up building my circuit inside a RS-232 Mini Tester I had lying around. This construction gave me nice boxed device that works as an useful debugging too with and without connection to logic analyzer. I taped wire pieces next to each LED on the RS-232 Mini Tester to be instructions how to connect the adapter to logic analyzer (which wire carries which signal).
In some sense the flagship of the LA suite, lars232 determines timing,
word size, and parity information for any RS232 data which is recorded
using one of the status pins on the port. This allows for rapid and
fairly reliable determination of the parameters of an unknown signal,
without resorting to trial-and-error methods.
I just received my AD2 yesterday and am positively surprised on the possibilities of this device. I have worked in testing for many years (decades) specifically on IEEE 1149 (JTAG) and immediately started looking for jtag/swd support of on the device.
I found this post, and see that it went in beta in January 2018, but the official release I find is a version 3.18.1 more than 4 years after the beta. Will there be a release or will I have to go for beta versions?
SVF file support would also be great as this could help in configuring FPGAs and the use SWD for MCU programming so the device serve even more purposes on top of all the awesome stuff it already does.
I was looking for a solution for Serial wire debug (SWD), not sure if you already on it or it is planning phase. I am using Analog Discovery and Digital Discovery, but was not able to find anything regarding serial wire debug
After installing the new release, digilent.waveforms_beta_v3.19.23_64bit.exe, i observed that SWD is there in Logic analysis but couldn't find it in Protocol section. Can you also please add SWD in protocol section, so that i can send command via protocol and analyze response on Logic section
However I was also using another HW from Saleig which was also decoding the SWD and gave attached decoded response. I was able to see a more detailed decoding. Would request you to incorporate these details in Digilent software also.
I tried the SWD protocol using Digital Discovery to send SWD Read pattern, but i didn't received response as i was receiving earlier. Further i have attached the snapshot for a read command captured via Logic analyzer. I am not sure if the read command is sending the right pattern. Please suggest.
In above command, address (in hex format) is the address location from where the data value will be read and the Numbytes represents number of words/data values to be read from that location. If we type Numbytes as 1, then it will read and show 1 data value (in hex format) at the address location, whereas if we type 2, then it will read and show 2 data values at that address location.
I agree with the above mentioned steps quoted by you. I also agree that we need to write first with a data value based on a specific A32 address. My query here is, for example, if we need to write the above mentioned data hDEADBEEF to a memory address for example, 0x40086ff8. Then how will that be possible ?
Here, A32 is an address of AP or DP register access and is a part of 8 bit pattern request. The above mentioned address location 0x40086ff8 represents 32 bit address which comes after ACK and Trn. Mainly, you will have to add this field in your version so that we can access 32 bit address because currently we are only able to access address A32 which is a part of 8 bit pattern request.
I think you should share both the scenarios, one in which part is able to communicate (wherein you are sending commands via different SWD hardware (Seger). You should capture the same via Logic Analyzer and share both command and response.
I captured the the waveform against a read command on Digillent logic analyzer (LA) in SWD mode. The Digilent LA is showing incorrect debugging sequence. I have compared the Digilent LA results with another LA and have attached both the digilent project file and sequence captured from another LA (in pdf file). You can match the sequence which appears incorrect in digilent LA. The correct sequence is in pdf file in the order Abort>Select>CSW>TAR>DRW. Please see and let me know.
There is one more thing to add to my previous post, at some places in captured Digilent LA sequence, you can see that 32 bit data is not being displayed completely. For example, in the case of ABORT register at the end, there are only ACK bits (3 bits) being displayed and the 32 bit data is absent. In addition, you can compare the results with the attached PDF file which shows results captured from different LA.
Here I'll show you how to use a single GPIO line on an MCU as a serial output device, emulating the transmit side of a UART. This is useful for debugging in situations where you can't otherwise get data out of the system to see what it's doing.
This uses a technique known as bit-banging, where you toggle a line via software to implement the behavior that's normally built into a hardware peripheral. The software implements the same hardware signaling protocol as the peripheral.
This is useful when there are no other peripherals available on the MCU (because they've all been used for other things, they haven't been brought out in the board design, or they've been deliberately disabled for security purposes).
I've also taken this opportunity to provide more than just the source code, treating it as an example of applying disciplined engineering. Discipline takes more time in the short term, but saves time and trouble in the long term. It's an investment, with significant return on investment over the life of a package, from its initial development through its use in fielded end products for years.
My preferred method for debugging embedded systems is to fire up a debugger and examine things directly. But sometimes that's impractical, particularly if there are timing dependencies, or the system transitions between images, disrupting the debug context.
In the first case, halting execution and examining things at human timescales (seconds to minutes) can't be done because the other MCU is expecting things to happen at machine timescales (microseconds to milliseconds); similarly with multi-threaded, timer-driven, or other interrupt-driven designs. In the second case, the debugger knows about the image being debugged, but not about the image being jumped to. The third case might be on a production board design where debugger access has been removed as a security precaution, but it does have provisions for internal bootloading so that it's still programmable.
If the MCU has serial or other logging available, that's the other main option, affectionately known as "printf debugging". That can still have timing issues due to excessive logging, but at least the logging is at machine speed. You can instrument the logging to print the relevant data you need for debugging.
7fc3f7cf58