Project

General

Profile

Actions

Bug #5664

closed

icE1usb GPS module I2C connection creates conflicts

Added by tnt over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
08/26/2022
Due date:
% Done:

100%

Spec Reference:

Description

The GPS has an I2C connection that is currently un-used. I thought that this was to talk to the GPS module as a slave. And indeed that's the case for the uBlox M8W modules (alternate part).

But on the chinese ATGM336H modules, this is not the case. That interface can be used by the module to connect an external EEPROM (although I really can't find much doc about that either) just like it was the case on older (6-series) uBlox modules and so the side effect is that this creates a conflict on the SCL line because the GPS module is actively driving it and not in open-drain mode.

In use in "normal" firmware, this has no impact whatsoever because we don't use the I2C bus (the GPS module is the only thing there by default), and the FPGA drives it in open drain mode.
But when trying the rs422 interface (which uses the i2c bus with some io expander for some 'config' signals), this doesn't work out.

Holding the GPS module in reset actually does release the lines so that's the work around I will use for the OCTOI datacenter deployment.
But obviously if we wanted to use the rs422 modules for the "other direction", emulating a GPS-02/03, then we need the on-board GPS to be running and not be held in reset ...

I think the best solution is to just disconnect those lines by default. They are routed and go through an area with plenty of free space, so I'd put a couple of "normally-open" solder bridges (or DNP 0402 footprints) in case there is ever a use-case.

Actions #1

Updated by laforge over 1 year ago

tnt wrote:

I think the best solution is to just disconnect those lines by default. They are routed and go through an area with plenty of free space, so I'd put a couple of "normally-open" solder bridges (or DNP 0402 footprints) in case there is ever a use-case.

yes, that makes sense. thanks!

mschramm, we shoulud include this fix for the new production batch

Actions #2

Updated by mschramm over 1 year ago

  • Status changed from New to In Progress

ACK

Actions #3

Updated by tnt over 1 year ago

mschramm Just to make sure, I'm the assignee, I'm already working on the change but there is also the kicad 5 -> 6 conversion that I want to do in a specific way.

Actions #4

Updated by mschramm over 1 year ago

Yes, I'm well aware; ACKing it was to indicate that I won't use a design for next production run which does not include a change regarding this issue. - The status change to progress was .. a reflex.

Actions #5

Updated by tnt over 1 year ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)