2024-07-19 08:19 AM - edited 2024-07-19 08:53 AM
Hi,
We're attempting to update the LIV4F firmware via the UART interface from an embedded device, however, we're unable to replicate the steps documented in UM3009.
Our code works up until the the baud rate configuration step in Figure 2, after which communication from the unit fails. Is there any additional documentation on the LIV4 firmware protocol or reference code? We found an example for the LIV3F but the process in the code differs substantially from what's in the LIV3F manual.
We also noted that the LIV4 module only returns the code 0x98 0x83, rather than the TESEO_FLASHER_SYNC code 0x83984073 documented in the manual. We do receive the ACK code after the DEVICE_START_COMMUNICATION code. Not sure if this is an expected change or if it is an indication that something is wrong.
I also found Quectel documentation for what appears to be the LIV3 upgrade process in the example code, and it show the baud rate being set in the binary image options data block. Is this still the case for the LIV4F? If so is there any documentation on which parameter/values specifies the baud rate for the LIV4F?
Thanks,
Kevin
Solved! Go to Solution.
2024-07-22 07:23 AM - edited 2024-07-22 07:24 AM
With some additional help from ST staff we were able to track down the problem:
1) The CRC calculation for the LIV4F pre-appeneds firmware data size (32bit uint little endian encoded) to the firmware bytestream. Once we updated our CRC calc the update process worked. See Python code below for a working example of the CRC calc.
2) We installed a serial tap on the line from Teseo Suite and discovered that in normal programming mode it uses the NMEA command $PSTMFWUPGRADE to initiate the update process, rather than the reset pin. Once our firmware update completed with STA8041_LIV4F_PVT_ME binary this method no longer worked and we had to use the reset pin to initiate sync.
We also *think* we noticed that the CRC was different when Teseo Suite updated the firmware via the NMEA command method (one of our serial captures showed a CRC without the length pre-appeneded). However, we couldn't recreate/confirm this after updating the firmware as the NMEA command no longer worked. Just something to look out for.
2024-07-22 07:23 AM - edited 2024-07-22 07:24 AM
With some additional help from ST staff we were able to track down the problem:
1) The CRC calculation for the LIV4F pre-appeneds firmware data size (32bit uint little endian encoded) to the firmware bytestream. Once we updated our CRC calc the update process worked. See Python code below for a working example of the CRC calc.
2) We installed a serial tap on the line from Teseo Suite and discovered that in normal programming mode it uses the NMEA command $PSTMFWUPGRADE to initiate the update process, rather than the reset pin. Once our firmware update completed with STA8041_LIV4F_PVT_ME binary this method no longer worked and we had to use the reset pin to initiate sync.
We also *think* we noticed that the CRC was different when Teseo Suite updated the firmware via the NMEA command method (one of our serial captures showed a CRC without the length pre-appeneded). However, we couldn't recreate/confirm this after updating the firmware as the NMEA command no longer worked. Just something to look out for.
2024-08-18 07:03 AM
Hi Kevin,
Thank you for troubleshooting this problem. We will capture this and add this to our X-NUCLEO code.
Under X-GNSS-GNSS library in STM32, there is a project for firmware upgrade. Have you referred to this project?