I am sorry that need your assistance here. Please also tell us if there is an easy way to reproduce this issue on pure devkit. We tried to reproduce this issue for several times but always not able to trigger it. or maybe you could tell us the reproduce rate so that we can estimate how many times we need to hit it.
(although running the system at a higher load seems to trigger it more often).
We were told this info by another customer too. He told us when device is in high temperature, it is easy to hit this issue. As you know high temperature just indicates high workload.
I was looking at the pinmux spreadsheet again. Where does that pin go? It is highlighted in yellow (GPIO), but is it accessible anywhere? Thanks.
This gpio pin is registered by the bluedroid_pm driver to be used for IRQ. That is why the first workaround is to remove this driver. But it is not a good solution I think.
Just to confirm my setup (without any USB devices) - I have a 16GB Xavier with this SSD installed:
I still get the bluetooth interrupts occurring (with no USB devices and the bluedroid_pm module loaded). I was looking at the schematic and the I/O pin is connected to a 3.3V to 1.8V level shifter. It seems like even if the internal pullup is enabled, it may not solve the problem because the level shifter is driving the pin. Unfortunately, there is no pullup on the M.2 side of the level shifter.
We have a method to configure the pinmux directly without reflashing the board. You could directly use the userspace tool devmem2 to change the pinmux.
register addr for this pin is 0x0243d048. Please set the status to PULL_UP in bit2:3
I am assuming it is a byte? I just wanted to double check because when I read the location, I get 0x55. So, I should write the value 0x59? I have not written it yet.
At the moment, I am not getting the interrupts anymore - it is a difficult intermittent bug!
Hi Wayne,
I can confirm that this does fix the problem! I ran the following command: sudo devmem2 0x0243d048 byte 0x59
Before I ran the command, my CPU #1 had 75% load with nothing running and the number of bluetooth interrupts was continually increasing. After I ran the command, the CPU load dropped to 0% and the number of bluetooth interrupts did not change. It seems to work and I will continue testing.
If you still hit this issue, please let us know. BTW, for the M.2 connector you mentioned in previous comment. Actually, according to released schematics on Jetson Download Center, there is a pull up on the M.2 side of the level shifter (R748).
Okay. Also, to be clear, would you like me to read the register with the fix applied (the pullup enabled) or when the problem is occurring (no fix applied)?
I have my system back up and running and I was able to trigger the problem. Here is the output for 0x02212200 without the fix: 0x59. Here is output with the fix: 0x59. The value is the same before and after running the command (sudo devmem2 0x0243d048 byte 0x59).
