Posts made by Sylvain Joyeux
I have created EP. The NAK was caused by a bug I introduced somewhere in the packet-to-type conversion logic. As was, it seems, the issue with flashing the firmware.
Thanks for the confirmation.
For those that would be interested, I've written down a protocol documentation - it has some stuff that's specific to our firmware, but most of it isn't: https://github.com/tidewise/drivers-imu_aceinna_openimu/blob/master/Protocol.md
OK ... so it seems that it was my fault. Sorry for the noise guys.
Hi guys. Thanks for the info
To clear any confusion: the unit boots fine. The problem I have is that it becomes non-responsive after a JA command, which means that I can't upload a new firmware through the UART (works fine with JTAG)
I'm trying to update a few configuration messages (in sequence) with uP. It works ... mostly. After a few uP, I get a message that looks like
0x55 0x55 0x00 0x00 0x02 0x45 0x50 0x37 0x62
The message is valid (good format, good length, CRC passes). I don't know if it makes any sense, but the payload (0x45 0x50) is EP, which is the name of the configured periodic packet.
I'm assuming it is sent from the messaging layer ... would you guys have some insights for me ?
I had some trouble flashing a new firmware, so I decided to try to upload the firmware using the JTAG adapter and PlatformIO's Upload task in VSCode
It seems that now I can't upload a new firmware anymore. Would the upload have overwritten the bootloader ? If it did, how can I re-establish it ? If not, how can I find what is happening ?
Thanks in advance
Thanks. That did the trick. I would suggest moving the GPS to UART_CHANNEL_1, which would make it easier to wire with the user UART, keeping the two pins of CHANNEL_2 for debugging.
I found out that the GPS channel is actually "Serial 2", not "Serial 1" as it seems the documentation hints. Is that expected ?
I tried to find out how to change that in the firmware, but I couldn't find how. Could someone help there ?