I am trying to replicate the tutorial “Debug session with simpleRTK2B and STM32” however not having much success.
I am using the same board as in the tutorial (L152RE) and while I’m not very familiar with the nucleo boards I have followed the tutorial video, downloaded the project from github and uploaded the sample code to debug with no issue.
Placing a break point at the ubx message parsing section of the code does nothing however and after further investigation it seems that the HandleGNSS() is never called because HAL_UART_RxCpltCallback() in hardware.c is never called.
So it seems like there is no end of transfer message being received. What might be some reasons for this?
It might mean it is not actually receiving data. On the Nucleo-64 boards I’d expect you might have to do something with solder bridges as D0/D1 pins share functionality with the ST-LINK VCP
I suspected this could be the case but since this is my first time using a Nucleo board so I wasn’t too sure. The solder bridges table in the nucleo-64 manual seems to say that SB62 and SB63 should be ON.
“PA2 and PA3 on STM32 are connected to D1 and D0 (pin 2 and pin 1) on Arduino connector CN9 and ST morpho connector CN10 as USART signals. Thus SB13 and SB14 should be OFF”
Hopefully someone at ardusimple staff can confirm the configuration used in their video.
Remove the resistor from SB13 and SB14 and put it into SB62 and SB63 or simply remove the resistors from SB13 and SB14 and weld the SB62 and SB63
Only getting back to this now. Worked like a charm, thanks!
Small issue. The RELPOSNED values do not update very frequently whereas the PVT values instantly update every time I run the code up to the breakpoint. Removing the breakpoint at line 162 as shown in the video and placing a new break point at line 180 it can take several minutes before the code breaks. If I disable the PVT messages then the breakpoint at 180 is triggered every time I run the code however so this behaviour only occurs when both messages are being sent over UART1.
Any ideas why this might be happening? It seems that the RELPOSNED messages are being missed so possibly related to timing/update rates? It’s odd however as if this is a timing issue I expect it to “catch” the messages at random, not for one message type (PVT) to be parsed significantly more often than the other as is happening here.
To follow up on my last comments above. As can be seen in the screenshots here (https://imgur.com/a/mGuUBxg) it looks like the handleGNSS() function is causing me to lose the first 5 bytes of the second message (NAV-RELPOSNED) which results in this message not getting parsed (although occasionally it will)
To test this I just slowed down the output rate from the F9P and added a buffer in HAL_UART_RxCpltCallback so that I could dump all the values send from a single transmission into an array. I then commented out the call to handleGNSS().
When handleGNSS() is called I consistently miss the first 5 bytes of the NAV-RELPOSNED message. When handleGNSS() is not called the problem goes away so this looks like a processing/timing issue. It only occurs at the end of a message so the time it takes to process a fully received message is causing the program to miss the first few bytes of the second message. I quickly tested this by commenting out the parsing for NAV_PVT messages which resulted in only 4 bytes being missed.
I haven’t had time to try rectify this but any suggestions welcome! I’ll try to get back to this later and will post any updates.
Hi cono44, a few checks:
– Confirm that only UBX messages are enabled in that interface, the parser is not expecting NMEA+UBX.
– If you increased the navigation rate from the default 1Hz, confirm that the UART bandwidth is enough otherwise you will run into buffer overrun problem in zed-f9p.
Thanks for your reply.
– Yes only UBX messages are enabled on UART1. If you look at my code, I have made a simple array (called testbuf) that dumps each byte from the rxBufferGNSS variable as it is received so I can see that there is no other data being received.
– I actually decreased the navigation rate from 1s to 10s to slow things down.
If I understand the code correctly each byte received is processed on the fly (i.e.there is no buffer):
– after each byte is received, handleGNSS() is called
– as soon as a header byte (0xB5) is received it starts to fill a buffer array and does so until the last checksum byte arrives
– the state is set up SM_UBX_END and this triggers the parsing section of the code
Since the first message is read and parsed without issue it seems that there is a delay in the parsing section of code but I’m struggling to see what the issue might be.
…so it seems dropping the baud rate on UART1 down from the default 38400 to 9600 (with navigation rate kept at 1Hz) fixes the issue. So it certainly some kind of timing problem.