Hi,
Again I have a strange issue, this time with the I2C bus.
The uBlox GPS ZOE-M8Q is connected to the Artemis Openlog via the Qwiic Connector. I’m using the ubx binary protocol which works fine.
In rare cases I get an checksum error. I have tracked the issue down and found that the received bytes by the Ambiq Apollo 3 differ from what I’m seeing on the oscilloscope.
The oscilloscope decodes the data to
0x00 17 DA 00 00 00 11 39 00 00 00 11 00 26 10 01 00 00 11 39 00 00 00 13 00 20 2C 01 00 00 11 39 00 00 00 15 00 24 94 00 00 00 11 39 00 00 00 16 00 3B 4F 00 00 00 11 39 00 00 00 1F 00 1D 46 00~A
Whereas the Ambiq Apollo 3 receives
80 17 da 00 00 00 11 39 00 00 00 11 00 26 10 01 00 00 11 39 00 00 00 13 00 20 2c 01 00 00 11 39 00 00 00 15 00 24 94 00 00 00 11 39 00 00 00 16 00 3b 4f 00 00 00 11 39 00 00 00 1f 00 1d 46 00
So the first bit of the first byte differs. I have probed the data with the x10 multiplier of the oscilloscope, because even more strange is the fact, when I measure with x1 the issue disappears.
Needless to say, the issue is present without the oscilloscope, so it needs to be fixed. I’m quite puzzled at the moment. What can be the source of the problem?
These two lines were read by the Apollo3
b5 62 01 35 a4 00 30 94 aa 09 01 0d 00 00 00 01 00 37 94 00 00 00 11 39 00 00 00 03 00 4f 02 00 00 00 11 39 00 00 00 04 00 39 ca 00 00 00 11 39 00 00 00 06 00 0b 39 01 00 00 11 39 00 00 00 09
The first was ok, but the second one
b5 62 01 35 a4 00 00 9c aa 09 01 0d 00 00 00 01 00 37 94 00 00 00 11 39 00 00 00 03 00 4f 03 00 00 00 11 39 00 00 00 04 00 39 ca 00 00 00 11 39 00 00 00 06 00 0b 39 01 00 00 11 39 00 00 00 09
caused a checksum error.
Clock speed is 100kHz.
Other speeds than 100kHz do have lots of errors or no connection at all.
I have tried different port pullup settings, without success.
The signals looks clean and thus I would not expect a pull-up issue. Looking at the picture clock stretch is begin applied on SCL by the GPS ZOE-M8Q. Also the datasheet is referring to that " The interface stretches the clock when slowed down while serving interrupts, so real bit rates may be slightly lower".
The Apollo3 IOM is initialized to detect clock stretch and on 100Khz and 400Khz it is waiting for 3 Base clk cycles to wait before sampling the SCL clock to determine if a clock stretch event has occurred. Now this clock stretch from the GPS could JUST be on the boundary of 3 clock cycles (hard to see).
Normally I would advise trying with a lower speed like 35Khz but on Sparkfun 1.2.1 only 100Khz / 400Khz and 1 Mhz are valid. On V2.0.6 you can select different speeds (thus also lower). However, OpenLog is only available on V1.2.1.
As a test you could try the following and see whether it makes a difference. In the file 1.2.1/cores/arduino/am_sdk_ap3/mcu/apollo3/hal/am_hal_iom.c around line 2203 change the line :
_VAL2FLD(IOM0_MI2CCFG_SMPCNT, 3)
Change the 3 to another number (say 2):
_VAL2FLD(IOM0_MI2CCFG_SMPCNT, 2)
Save and then recompile the sketch, maybe it works. Maybe try another number like 1 or 4.
