Can you please connect to on of the M8U qwiic boards and download the configuration file and send it to me?
Right not I can not even get the PPS led to flash even thought I reenabled it.
Thanks
Bruce
Can you please connect to on of the M8U qwiic boards and download the configuration file and send it to me?
Right not I can not even get the PPS led to flash even thought I reenabled it.
Thanks
Bruce
OK, so I tried again and the firmware is running now with UDR ver 1.3.1 but now the board will not communicate will not communicate at all.
Did this get disabled in the configuration some how with the firmware update? Can someone send me the as delivered configuration file for the NEO-M8U QWIIC board to see if this fixes the problem?
Any thoughts?
Thanks
Bruce
These ship with the factory defaults and there’s a button in U-Center that resets the GPS back to factory defaults. Have you tried that?
So this issue is not with the firmware upgrade but specifically with the DUE and the M8U QWIIC board I figured out.
Before the firmware upgrade it was just WIRE1 with Native USB issue. After the firmware upgrade, (latest and greatest) is doesn’t matter WIRE/WIRE1 Programming or NativeUSB…neither work.
So I have been fighting with the DUE both real and copies (2 boards) with the latest version of the IDE from Window 10 apps.
I am trying to run the Example_3 Get Position from the Spark fun u blox library.
The M8U and a Nano 33 IOT work great together on WIRE.
The DUE and a Sparkfun Serial LCD/Sparkfun External_EEPROM, and Adafruit BMP390L all work great. No problems on either WIRE or WIRE1.
So with the same wiring/connector as used above that worked fine at both 100K and 400K with the other components, it does not work with the M8U.
The M8U says it has internal pull ups but I mesure and open between the 3.3 and the SDA/SCL. I read there is issue with the WIRE pull up so I removed them from the board. Did not work. I added 4.7K, which did not work. But the WIRE original pull ups and the 4.7K work fine for the other QWIIC based components.
So the long and the short of it is the M8U and the DUE WIRE do not like each other.
Any ideas why it is just these two combinations?
Thanks
Bruce
Hmmm, I can’t think of a specific reason why the Due and M8U don’t like each other, especially if you have already tried just the 2 boards with the 4.7K pull ups enabled.
How long are the wires used for I2c communication? Have you tried different wires or shorter wires? There could be a resistance issue on the i2c lines.
The wires are 4". Exact same wiring I have used with the Sparkfun Serial LCD/Sparkfun External_EEPROM, and Adafruit BMP390L @100K and 400K with no problem.
It worked find before the firmware upgrade now no joy. I can’t understand what the firmware (UDR 1.3.1) upgrade could have changed the communication characteristics of the M8U. I did have a problem, only on WIRE1 when the SERIALUSB was being used but WIRE worked fine. Now it does not matter no combination of pull ups (or lack of) work again only with the M8U.
Again, any ideas would bel helpful.
I see you posted on the ublox forum. I think that you might get the best answer over there I am afraid to say. It seems to me like it is an issue with the firmware upgrade for the M8U.
I suppose it is possible that the firmware upload could have had a failure point. Maybe try re-uploading and see if that fixes the issue.
Could just be a bug? If you could try a different microcontroller dev board, that might help.
I wish it was that simple. The M8U still communicates with a Nano 33 IOT so it is some quirk between the DUE and the M8U.
The Nano begin looks like this:
Nano 33 IOT Repeat Begin 1.png[/attachment]
The OScope looks similar:
Due:
Due looks cleaner than the Nano with the QWIIC cable and QWIIC BOB
The decoded begin messages look like this:
Nano:
Nano 33IOT QWIIC BOB Begin.csv (3.24 KB)
Due decoded messages:
DUE.csv (8.25 KB)