I am trying to use GPIO03 as interrupt pin for the BNO086 IMU but I’ve noticed that it goes low (it’s active low) a lot more often than it should. This is our own custom carrier board so it’s not easy to test using another GPIO as the IMU is soldered onto the board. But I did test the official devkit and used GPIO01 which worked a lot better.
When looking at the schematics of the official devkit I noticed that GPIO03 is used as “BT_M2_EN” on that one, so I wonder if that might be the issue somehow? I based the image of our custom carrier board on the official devkit.
Here is the pinmux settings for GPIO03 on our custom board:
spi2_sck_pcc0 {
nvidia,pins = “spi2_sck_pcc0”;
nvidia,function = “rsvd1”;
nvidia,pull = <TEGRA_PIN_PULL_UP>;
nvidia,tristate = <TEGRA_PIN_ENABLE>;
nvidia,enable-input = <TEGRA_PIN_ENABLE>;
nvidia,io-high-voltage = <TEGRA_PIN_DISABLE>;
nvidia,lpdr = <TEGRA_PIN_DISABLE>;
};
Thanks in advance,
Fredrik
Hi fredrik.tegnell,
What’s the Jetpack version in use?
Do you mean the issue is specific to your custom carrier board and you suspect the issue is caused from the pinmux configuration for GPIO03?
If so, please simply run the following command to check and compare the result on both custom carrier board and the devkit.
$ sudo busybox devmem 0xc302048
Hi,
The Jetpack version in use is 6.2 (L4T 36.4.3)
Yes exactly. Just note that I do use GPIO01 on the devkit and GPIO03 on the custom carrier board.
Output from your command:
Devkit:
0x00001001
Custom carrier board:
0x00001059
Could you verify the same pin on both the devkit and custom carrier board?
Please update the pinmux register with devmem command to check if it helps for your case.
$ sudo busybox devmem 0xc302048 w 0x1001
The pin is hardwired on the custom carrier board so I can only use GPIO03 there. And on the devkit the GPIO03 isn’t available since it’s used for “BT_M2_EN” according to the schematics.
I tried your command:
sudo busybox devmem 0xc302048 w 0x1001
And that resulted in the interrupt not working at all, it never went low.
Btw shouldn’t I rather test taking the devmem output of GPIO01 on the devkit and applying it to GPIO03 on the custom carrier board?
A bit hard to explain but I mean something like this:
sudo busybox devmem <GPIO01 hex>
sudo busybox devmem <"GPIO01 hex> w <output of previous command>
Because I suspect that “0xc302048” is the hex of GPIO03? I would then need the corresponding hex for GPIO01.
For the devkit:
GPIO03 seems configured as GPIO/Output/Drive 0 by default.
GPIO01 is configured as GPIO/Input/Int PU by default
Okay, please refer to the following addresses for their pinmux.
GPIO03: 0xc302048
GPIO01: 0x2430068
You can also update the pinmux spreadsheet(according to your use case) and reflash the board to apply the change.
I did try my suggested solution of copying the configuration of GPIO01 on the devkit to GPIO03 on the custom carrier board but without success, it still functioned but only as bad as with previous configuration.
I’ve already updated the pinmux spreadsheet to what should be correct for the interrupt:
But it still won’t function as good as the devkit, any idea what to debug next?
Do you have custom design for GPIO03 on your custom carrier board?
Have you also checked if other pins on your custom board can work as Interrupt as expected to clarify if the issue is specific to GPIO03?
GPIO03 is hardwired to the interrupt pin of the IMU (BNO086) on the custom carrier board. But other than that there is nothing special about it, just directly connected.
Since it’s a soldered solution it isn’t possible to compare other pins on the custom board. Is there some way of seeing if some other part of the system is affecting the GPIO03? Like if there is some old remains in the device tree from the devkit, since I used the devkit image as base for the custom carrier board image.
You can simply run sudo cat /sys/kernel/debug/gpio|grep PCC.00 to check if any driver is using it.