Sprow
Posts: 4
Joined: Thu Feb 09, 2017 1:25 pm

Configuring the pull resistors on the FXL6408 on CM3

Thu Feb 09, 2017 1:41 pm

Hi,
I'd like to use some of the spare IO pins on the expander (U8) on the CM3 board. Using the mailbox message described in viewtopic.php?p=989907#p989907 I can read the pins via the GPU OK.

The extra pins are added to the dt-blob as described in https://www.raspberrypi.org/documentati ... w-guide.md. For example

Code: Select all

[email protected] { function = "input";  termination = "pull_up"; }; // IO6
However, as it's a bit fiddly to solder to I don't want to have the extra burden of pull up or pull down resistors on my inputs since they're integrated into the chip, but the termination attribute on the pin doesn't seem to do anything. I tried both, but the IO line reads the same in both cases with nothing connected, whereas I'd expect it to follow the pull setting.

Register 0x0B and 0x0D in the FX6408 datasheet shows both states are possible.

Have I got the syntax wrong? Or is there a firmware bug which means the termination setting isn't propagated through to the pins, only the input/output direction setting?

Thanks,
Sprow.

aBUGSworstnightmare
Posts: 1492
Joined: Tue Jun 30, 2015 1:35 pm

Re: Configuring the pull resistors on the FXL6408 on CM3

Thu Feb 09, 2017 2:52 pm

out of curiousity: how do you want to access these expander I/Os? Soldering wires to the CM3? Why not add an I/O expander to your baseboard in case you're running out of GPIO?

Sprow
Posts: 4
Joined: Thu Feb 09, 2017 1:25 pm

Re: Configuring the pull resistors on the FXL6408 on CM3

Thu Feb 09, 2017 3:13 pm

aBUGSworstnightmare wrote:out of curiousity: how do you want to access these expander I/Os? Soldering wires to the CM3? Why not add an I/O expander to your baseboard in case you're running out of GPIO?
Only need 2 lines, and want them to be carried round with the Compute module itself (ie. the state should transfer from one box to the next if the Compute modules get swapped round).

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7302
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Configuring the pull resistors on the FXL6408 on CM3

Thu Feb 09, 2017 3:21 pm

The firmware driver hardcodes register 0xB to 0x2f, and 0xD to 0x00.
There isn't an expectation that the unused pins are to be available for general purpose use, particularly as on the CM3 they don't come through the SODIMM connector, and therefore it needs to fulfil the basic purpose and no more.

There is a request to allow reconfiguration of the FXL6408 GPIOs (mainly for controlling the power LED on the Pi3), so if I'm bored enough when looking into that I may look at adding pull up/down control at that point. It requires extending quite a few APIs though.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Sprow
Posts: 4
Joined: Thu Feb 09, 2017 1:25 pm

Re: Configuring the pull resistors on the FXL6408 on CM3

Thu Feb 09, 2017 4:52 pm

6by9 wrote:The firmware driver hardcodes register 0xB to 0x2f, and 0xD to 0x00.
Shouldn't register 0xB be 0xFC because there are discrete pullups on IO0 and IO1 that you'd conflict with otherwise (R7 & R8)? It's the upper bits which are floating and hence want pulling to some known level.
6by9 wrote:There is a request to allow reconfiguration of the FXL6408 GPIOs (mainly for controlling the power LED on the Pi3), so if I'm bored enough when looking into that I may look at adding pull up/down control at that point. It requires extending quite a few APIs though.
That'd be brilliant if it's possible. My inspection of lines 1335 & 1336 of https://raw.githubusercontent.com/raspb ... t-blob.dts which include termination = "no_pulling" made me think all the hooks were in place. ie. I'm not wanting to adaptively fiddle with the settings via a mailbox property, just one shot setting from the dt-blob.

Thanks in advance,
Sprow.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7302
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Configuring the pull resistors on the FXL6408 on CM3

Thu Feb 09, 2017 5:22 pm

Sprow wrote:
6by9 wrote:The firmware driver hardcodes register 0xB to 0x2f, and 0xD to 0x00.
Shouldn't register 0xB be 0xFC because there are discrete pullups on IO0 and IO1 that you'd conflict with otherwise (R7 & R8)? It's the upper bits which are floating and hence want pulling to some known level.
I just looked at the firmware source code and copied what I found there!
I'd agree for IO0 that there appears to be a conflict. For IO1 there isn't as it is defined as an output, and as per the text in the datasheet "If the pin is defined as output in register 03h, the corresponding bit has no effect".
The settings were probably written for the Pi3 (IO4 and IO7 used as inputs, pulling disabled. All others outputs) and not considered in detail for CM3.
6by9 wrote:There is a request to allow reconfiguration of the FXL6408 GPIOs (mainly for controlling the power LED on the Pi3), so if I'm bored enough when looking into that I may look at adding pull up/down control at that point. It requires extending quite a few APIs though.
That'd be brilliant if it's possible. My inspection of lines 1335 & 1336 of https://raw.githubusercontent.com/raspb ... t-blob.dts which include termination = "no_pulling" made me think all the hooks were in place. ie. I'm not wanting to adaptively fiddle with the settings via a mailbox property, just one shot setting from the dt-blob.[/quote]
Gordon just made the comment of "didn't I implement that bit?".
He has implemented the parser and handling of the the initial state, but the API between the generic GPIO handler and the GPIO expander driver is missing any notion of pulling (or reconfiguration after open). If it was going through the standard GPIO driver instead of the expander one, then it would all be there.
Not a huge job to fix, but also a little way off the top of the priority list, and I currently couldn't suggest a timescale on it.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Sprow
Posts: 4
Joined: Thu Feb 09, 2017 1:25 pm

Re: Configuring the pull resistors on the FXL6408 on CM3

Thu Feb 09, 2017 5:48 pm

6by9 wrote:
Sprow wrote:
6by9 wrote:The firmware driver hardcodes register 0xB to 0x2f, and 0xD to 0x00.
Shouldn't register 0xB be 0xFC because there are discrete pullups on IO0 and IO1 that you'd conflict with otherwise (R7 & R8)? It's the upper bits which are floating and hence want pulling to some known level.
I just looked at the firmware source code and copied what I found there!
I'd agree for IO0 that there appears to be a conflict. For IO1 there isn't as it is defined as an output, and as per the text in the datasheet "If the pin is defined as output in register 03h, the corresponding bit has no effect".
...
Gordon just made the comment of "didn't I implement that bit?".
He has implemented the parser and handling of the the initial state, but the API between the generic GPIO handler and the GPIO expander driver is missing any notion of pulling (or reconfiguration after open). If it was going through the standard GPIO driver instead of the expander one, then it would all be there.
Not a huge job to fix, but also a little way off the top of the priority list, and I currently couldn't suggest a timescale on it.
I suppose the cheeky request, given bigger fish to fry, would be to tweak the defaults for CM3 to

Code: Select all

reg 0x3 = 0x02, reg 0xB = 0xFC, reg 0xD = 0xC0
which solves the conflict on IO0, and at the same time achieves the setting I'd been trying to do from dt-blob. At <some point in the future> when the parser settings make it to the expander my dt-blob will take effect (and the reg 0xD default becomes irrelevant).

Now I see the qualifier on the bit being ignored for output pins, I agree IO1 isn't really a problem, just IO0,
Sprow.

Return to “Compute Module”