STMicro's Unicleo-GUI PC Application breaks when connecting through STMicro's ST-LINK in-circuit debugger and programmer pod. Why? [SOLVED]

[Rstua.1]

Hi,

I have used the STMicro's Unicleo-GUI PC Application to test both the LSM9DS1 STMicro's HAL and STMicro's Compass Middle Ware (from X-CUBE-MEMS1) - and - the LSM6DSO-LIS2MDL combination using almost the same software. All STMicro code (HAL for the LSM9DS1, LSM6DSO & LIS2MDL) and our code worked together well to provide the STMicro's Unicleo-GUI PC Application data to display graphically.

Since then I have ported all code from an STMicro's NUCLEO board (using an STM32L412 processor) to our target platform (using the same STM32L412 processor). This caused the USB interface to change from the built in USB on the STMicro's NUCLEO development board to the STMicro's ST-LINK in-circuit debugger and programmer pod.

It would appear this switch has broken STMicro's Unicleo-GUI PC Application. The STMicro's Unicleo-GUI PC Application no longer finds and advertises a suitable Win10 Comm Port to connect to. Where as before the STMicro's Unicleo-GUI PC Application found the correct Win10 Comm Port automatically. Apparently the STMicro's Unicleo-GUI PC Application was able to search through all Win10 Comm Ports as no matter what Comm Port the target code showed up on, the STMicro's Unicleo-GUI PC Application would find it.

Using a normal terminal program in place of the STMicro's Unicleo-GUI PC Application, it has been verified that the target code is sending out data over a Win10 Comm Port through the STMicro's ST-LINK in-circuit debugger and programmer similar to when the target code ran on a STMicro's NUCLEO board back when the STMicro's Unicleo-GUI PC Application worked. Further, when typing into the normal terminal program, the target code breaks on programming which normally receives data from the STMicro's Unicleo-GUI PC Application.

It occurred to us to try and "simulate" the STMicro's NUCLEO USB interface by advertising the same USB-VID and USB-PID when connected through the STMicro's ST-LINK in-circuit debugger and programmer. This, however, did not work. The STMicro's Unicleo-GUI PC Application did not connect to the target as it did to the NUCLEO board. The new VID and PID were verified using a Win10 USB Application.

1. Has anyone been able to get the STMicro's Unicleo-GUI PC Application to work through the STMicro's ST-LINK in-circuit debugger and programmer?
2. Is there another version of the STMicro's Unicleo-GUI PC Application which will connect "blindly" to a valid data stream no matter what Win10 Comm Port the data is received on?

-thanks

[louda.marian · Accepted solution]

Hi,

Regarding first question: I do not know what do you mean " through the STMicro's ST-LINK in-circuit debugger and programmer".

Regarding second question:

It is possible to enable listing of all COM ports without any filtering for "suitable" ports.

Settings->Application Settings->List All COM ports.

If it will not help, let me know.

Best Regards,

Marian

[Rstua.1]

> ...what do you mean " through the STMicro's ST-LINK in-circuit debugger and programmer".

The Unicleo-GUI PC Application works great when connected to our software running on the NUCLEO-L412 board and the NUCLEO-L476 board. Both of these boards have built in USB adapters which appear similarly (i.e. USB-VID, USB-PID & other attributes) to the Windows 10 computer running the STMicro's Unicleo-GUI PC Application.

However, when connecting to our software running on our target board through an STMicro ST-LINK pod, the Unicleo-GUI does not show any available USB communications ports. To verify our software is in fact creating, transmitting and receiving over a USB communications port, we stopped the Unicleo-GUI PC Application and started a RealTerm Applicatoin on the PC. We immediately found the USB serial port, connected to it and observed the data stream intended for the Unicleo-GUI PC Application. Were even able to send data and break in our software on the target board when the USB data was received.

We then used a USB Application on the PC to study the USB characteristics of the STMicro NUCLEO boards verses the STMicor ST-LINK pod and found hey are different.

So, there is a possibility that the STMicro Unicleo-GUI PC Application can not tolerate a USB interfaces with characteristics other than those of the integrated USB interface on the STMicro's NUCLEO boards.

> It is possible to enable listing of all COM ports without any filtering for "suitable" ports. Settings->Application Settings->List All COM ports.

When connected to our target board through the STMicro's ST-LINK in-circuit debugger the Unicleo-GUI PC Application did not offer any USB serial communications port. I know of the Settings->Application Settings->List All COM ports options. However I can not specificaly say I tried this option while connected to our target board. I will try this over the next 2 hours and post a follow up.

[Rstua.1]

Followup:

Turning off the Unicleo-GUI PC Application filtering using the Settings->Application Settings->List All COM ports options works. The Unicleo-GUI PC Application now sees the USB communication port. However the Unicleo-GUI PC Application does not offer up the "Start" option. Indicating the software on the target is not responding to the Unicleo-GUI PC Application correctly. But now we have something to work on, thanks.

[louda.marian]

Your firmware must respond to command

#define CMD_Read_PresString           0x02

Unicleo uses this response to identify firmware and to setup its GUI.

Do you see some messages in User Messages tab?

[Rstua.1]

I can see the commands that the Unicleo-GUI PC Application is sending out through inspection of the receive buffers in our software. Currently I am struggling to parse this data. I don't believe there is any documentation - so I am forced to backward engineer what is supposed to happen by looking at the Cube-MEMS example code. I am not sure, but I think when the Unicleo-GUI PC Application sends an 0xf0 this means end-of-message.

But this effort is being severely hampered due to lack of IDE support. When breaking on any data associated with the USB feature, TrueSTUDIO reports absolutely impossible variable values. Yet the code executes (makes decisions) as if the values were reasonable. It is impossible to debug the code! I've been using TrueSTUDIO for about 2 months now and this is the first time it has truly failed to help write code.

[louda.marian]

It is not necessary to do any reverse engineering, source code for all examples is available. You can find everything you need by browsing of source code.

You have to port more code from our example to your software to be able to communicate with Unicleo-GUI application.

[Rstua.1]

The easiest path to get the Unicleo-GUI PC Application to work with our target was to switch to a USB CDC port. I believe communications is working. But now I need to write code to connect the Unicleo-GUI PC Application to our software. It is a matter of understanding if I can just pass each character individually (does not work as the STMicro example software does not appear to handle the 0xf0 character appearing in between each Unicleo-GUI PC Application command) or if I need to pass complete individual commands (difficult as I need to reverse engineer what a Unicleo-GUI PC Application variable length message is).

But - at this point the STMicro IDE TrueSTUDIO is failing me! I can not see the actual values of many if not all the USB variables!

Why?

-thanks

[Rstua.1]

Turns out that a watch dog timer was active while TrueSTUDIO had stopped on a code break point. This apparently reset some variables making it appear the USB CDC code did not work. I disabled the watch dog and was able to debug the USB CDC code. I believe that STMStudio worked as expected because the code was allowed to run while connected to STMStudio and the watch dog was "kicked" so as not to disturb the USB CDC variables.

-thanks