I want to analyze the Serial data (UART) through STM32F2 series board (Nucleo 144). How one can develop Network Tap or Packet analyzer using Nucleo 144 Board. Any rough idea is most welcomed. Thanks in advance
The flow parameters are known? - Use UART.The unknown parameters of the flow - use a timer.Analysis for flow control commands and data.First, you need to accumulate a base character fused data (separated by zero) and so as to fix the amount of data after the command word. The second option: the control word - variable length data -Individual -Team word. By repeating the conditions - be considered a successful design, and used for analysis.
On the fat stream much memory you need, about 128-512mbit.
Проект не требует большого количества кода, можно написать за вечер. Или найти га гите.
just to add. In the next step you would need to transfer the acquired data/frames etc. into the PC. For this you can use Ethernet (not sure it's present on F2) or USB. The protocol can be user defined, not sure there is a suitable USB class for this.
Have a nice day,
One can certainly connect an USART RX pin and monitor traffic on the wire non-invasively.
The bigger question is how you plan to analyze the data, and where you are going to output or store the analysis? I'd expect the analysis output to be much more verbose than the data being monitored, but you should perhaps explain more completely the system expectations.
The Nucleo-64/144 don't have a MicroSD socket, or a screen, there are Disco boards that do. For serial data logging applications I like the GHI FEZ Lemur boards (Arduino shield connector), or cheap VCCGND/TAOBAO boards.
Thank you for Reply.
Currently i am planning to Output the Analysis on PC (Not fixed yet but may be using Ethernet connectivity of Board can be Option). I want to Monitor the data going from bus (Most imp is address of the communication devices) & if a device Fails or an error occurs track a device which is failed (Mostly for Troubelshooting). I have to develop a System from raw idea so ist open (Provided that at the end i can get all info on pc Esp. Address of the devices). You can suggest if anything more feasible in design or idea.
I was doing something similar. A SENT analyzer, so I had to use a timer to acquire data on the bus and transfer it to PC. Unfortunately the project was stopped for now, but I was able to prepare a demo to Tx/Rx SENT frames + I created a WinUSB driver on STM32 so it can communicate as a CDC class.
Good luck with your development!
Thank you for Reply. Its great to hear from you about the similar development. Is it possible for you to share your experience or development if possible. I am just planning to do some Detail Research in this area (Using Nucleo 144 Board)
sure I can share some experience. :-) Well, in general the project was meant to be a bus analyzer (SENT protocol with SPC feature).
After reading the SENT specification I knew I need to use a timer in PWM mode or input capture mode (edge detection) depending on whether I receive or transmit. Because I wasn't experienced much with the timers on ST devices, I've started using CubeMX to generate the PWM transitter on one timer and the receiver on the other. After figuring out the capabilities of the timer I've started to create some SENT API. This API was atop of the HAL timer. I needed to create a link between my API and the HAL, so I had to do a slight change in the timer HAL.
After some time I had a functional receiver/transmitter as a demo for my friend. The concept has proven implementing this is possible/easy on ST. So I switched to the connection with the PC side.
Unfortunately the USB support in Cube is weak. Also I knew there are some issues with the VCP class etc. and I wanted to learn the USB a bit. Another point is for latest Win you need to have a signed driver, otherwise there are some issues installing such a driver or so. So after some hours of investigations I've found that Win supports a so called WinUSB driver. The advantage should be, that you connect your device and you don't need to take care of the driver on the PC side. You just need to provide proper descriptors etc. and Win will recognize the device as a WinUSB device... So I started to develop the "class" on the ST MCU. At the end I've succeeded and I was able to transfer/receive frames with this class. There are some pitfalls etc. but I didn't have time to investigate the whole thing. So maybe at the end there will be some limitations or so, but the USB part was also ready.
After that my friend asked me to continue with the SENT side, as this was more critical. So I continued implementing all the features. Actually I've figured out, that the project is getting more and more complicated and I started to draw Flow charts to see the whole thing from a different perspective and to have a global overview of the whole "driver". That time my friend told me to stop the development, because some other projects get a higher priority!
At the moment I'm working on it by my own in my free time, I'm re-implementing the SENT layer to have general interface so it can be used on any device, not just ST. Because I'm not a SW architect, it's a bit challenging, but its fun.
So to sum up my observations and to give you some advice:
Gather as much information as possible about the UART + USB/Ethernet
Try to make those peripherals running, get familiar with USB/Ethernet, if you never worked with it before to know it's benefits/limitations/obstacles
Start with creating flow charts (how you think your code should work)
Define your interface - how are the gathered UART data going to be transferred into PC, how the frame will look like, how error frames will look like etc.
After you have this, start implementing one part (UART | PC side) according to your flow charts. The better you design your charts, the easier it would be for you to do the job. If you underestimate this, you will see troubles, which means you need to update your diagrams etc.
If you figure our there is a mistake in your logic/diagrams, go back, update them and adjust your code accordingly/continue.
That's all, it's an iterative process of defining your task, implementing it, validating it and if something is wrong, redefining your task, implementation/fix/adjustment and validation...
A big advantage of such an approach is, that your work is somehow documented. Of course you should document also your work. So after some time you just look into the flow chart and you know, how the code works or should work... then looking deeper into your code would be much simpler...
I hope this helps a bit with the development! Good luck and have a nice day,
Subject seems a bit WIDE OPEN but.....
You're tapping onto a uart "bus" ? RS232 level? Vdd Micro voltage level?
Log first then analyze maybe ?
If you are talking about an RS232 level signal, and have a PC with a real com port, you're in business.
I'd think if it goes the "connect a USART RX pin and monitor traffic on the wire non-invasively".
If RS232 level, and your PC doesn't have a com port, use a level converter and use the HAL VCP example.
You could empirically determine baud. If slow enough, stream your uart trappings back to a PC with USB and VCP (HAL DEMO WORKS)
and use one of the many terminal apps that let you log the stream live to a file.
If you want the micro to do the analysis, well now THATS a project.
I will use real com port for the initial Analysis. But when i am receiving data through some external device (May be device address Information of the devices) i Need to develop some app or can i use existing terminal app (& which one will be good)??
Further how i can stream uart trappings back to a PC using USB?? (For Nucleo 144 HAL DEMO works quite uncertain). May be this can be a nice Option if ellaborated in Detail.
Thank you so much for Detail description. I will use it as reference while development. So first Task will be implementation of Functional TX & RX & then carry further. Abouth the sent API can you explain Little bit in Detail?? As link is created between API & HAL what exactly we Need to Change to establish it?
Regarding the API, I had a structure describing one SENT channel, however the channel needed an info about it's timer, so I needed to create a link between the SENT structure and HAL timer. Thus I expanded the timer structure by a pointer to some user data (in my case SENT channel structure) and the same in the SENT structure. So in case the timer interrupt has been generated, I had the information which sent channel it corresponds to and vice versa, when I worked with SENT channel, I had the information about the timer being used.
But this highly depends on your implementation, needs etc. Maybe you won't need it...
Retrieving data ...