cancel
Showing results for 
Search instead for 
Did you mean: 

Virtual_COM_Port with X-NUCLEO-LIV4A1A works NUCLEO-F4XX fails on NUCLEO-U575ZI-Q

abartky
Associate II

I've been trying to get the Virtual_COM_Port app running on the combination of X-NUCLEO-LIV4A1A and NUCLEO-U575ZI-Q board and the best I can get is where the app will successfully output the first second's group of NMEA messages to the PC running a terminal emulator program and then it stops.  After it stops, the actual LIV4 module on daughtercard cotinues to run as you can see the RED LED blink pattern change.

This happens in all three cases where I:

  1. Try running the pre-compiled build of Virtual_COM_PORT .bin file for the U575XI baord under the repository folder.
  2. Build the example project under STM32CubeMX, code generate it for STM32CubeIDE, build it and load it to the U575ZI board and run it (either in run or debug mode).
    1. NOTE: In this case, I do get one compile warning where I complains about a missing .c file in the Src folder (worked around this by finding it in a different folder, copying and build).
  3. Follow the steps in the GNSS1 FW getting started guide and manually setup the project in STM32CubeMX, code generate to STM32CubeIDE, and load and run.
    1. NOTE: In this case, I get no errors or warnings from MX or from IDE when it builds.

When I then take the exact same LIV4 daughtercard and run it on a NUCLEO-F446RE board running the F401 example code (pre-built or built from example with MX and IDE), the FW runs fine without error and continuously outputs proper NMEA messages back to the PC terminal emulator.

I did try to do some debugging and what I see is sometimes I get an exception and sometimes I don't.  I also see that if I put a breakpoint in the code where the serial data is copied from the LPUART1 to USART1 and hit run on each time the breakpoint is reached, the code continues to run OK and I get lots of messages.  If I then clear the breakpoint and let it run, then it again outputs a few messages and then stops.

I also tried changing the project in MX from I2C to Serial port interface to the Teseo LIV4.  In that case, the program never crashes, but all I see on the terminal emulator is the first $ character from the NMEA messages and nothing else.

So I'm looking for help to get this program working as we've got our own board coming back by the end of the month that among other things has a U575ZI MCU and a Teseo LIV4 module (in our case interconnected by UART interface, not I2C).

I'm running the latest STM32CubeIDE 2.0.0 and STM32CubeMX 6.16.1.  For GNSS1 I've tried both the latest 7.1.0 and 6.0.0 which was what the CubeMX downloaded example app was setup to use.

.ioc file that I manually created from the Getting Started Guide is attached.

Any help, guidelines, suggestions, would be appreciated as right now I am very stuck in trying to get this to work.

Thanks,

Alan

3 REPLIES 3
abartky
Associate II

Screenshot example of when it does fail (see the same thing in downloaded example project, this screenshot is my manually created project).  When it does fail, it appears to be in the area of processing I2C receive message from the Teseo LIV4:

abartky_0-1769197100026.png

 

Fault shown on freshly built example code (6.0.0 GNSS1 version) and attached text file with exported variable values at time of call to Receive_IT (where exception occurred) in attached .txt file (some expansion of fields, not all as all expansion is huge):

BTW, on this fresh build, I didn't get any errors nor warnings and it built and compiled OK first time from building the example "as is" from STM32CubeMX code generation.

abartky_1-1769199258296.png

 

Last piece of detailed info for today, hopefully this helps.

If I put a breakpoint on PRINT_OUT in TeseoConsumerTask, then hit run for each time the breakpoint occurs, then I keep getting messages one for each breakpoint occurrence and it is stable.  As soon as I let it free run, it runs for a few messages and then fails again.

abartky_3-1769200455816.png

 

 

abartky_2-1769200436353.png