High CPU usage when idle


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.

Hi jseng,

Sorry for late reply.

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.

Thanks for testing. Please keep trying.

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).


Could you also dump the register GPIO_Y_ENABLE_CONFIG_00_0 ( 0x02212200) ? When you hit this issue?

Hi jseng,

Any update for last comment? Thanks.

I am in the middle of rebuilding some of robot wiring, so it will be a few days until I can boot it up again - maybe on Friday.

Sure. We need your input for this issue.
Wait for your reply.

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)?


Could you dump it from both cases (fix and no fix)?


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).

Hi jseng,

Sorry for late reply. Are you sure the output value is same before and after fixing this issue?

Is it correct based on your observation?

0x0243d048: before: 0x55 , after: 0x59 (and fix this issue)
0x02212200: always 0x59

Yes, that is correct.