Hi, I am trying to power the Jetson Nano via the barrel jack using a 3S 2200 mAh battery and a BEC. When I measured the voltage with a multimeter while powering the Jetson, it showed about 5.2 V being supplied. However, the monitor displays an “overcurrent” error.
If anyone has experienced this issue, I would appreciate it if you could share your experience and possible solutions.
Thank you.
Hi, please read the Jetson Nano Developer Kit User Guide first to check if your power supply settings fulfill the requirements. You may also need to measure the real voltage level on board to check if it is ~5V.
Also be sure to mention exactly how you have determined there is an overcurrent, e.g., via log message (and if there is a log message, be sure to provide the log, including log which leads up to the error and not just the error).
Thank you. I will check again according to the guide you provided.
Thank you for your advice.
When I booted, I saw the “OC ALARM” error as shown in the first photo, and I also saw the warning sign as shown in the second photo.
Suggest to baseline or characterize your system/application using a bench power supply first where you could change voltage and current limits conveniently. That way you will know how much current your system and the peripherals are demanding. Also check your system temperatures. Once you know this then you could try with your battery choice and optimize the application to operate from a battery.
Someone can correct me if I’m wrong, but most of the time I think the OC alarm is not an error or problem. Jetsons are designed to be efficient for power, and they have different “power models” you can select. Mostly any mode other than the max power mode reduces consumption via the clock speeds being reduced. The message about OC alarm is probably telling you that a clock is being reduced to comply with the current power mode.
The program for setting power modes is nvpmodel. The program which maxes out clocks for the current mode (model) is jetson_clocks.sh. I’m guessing, but I think this isn’t really a power issue. Check:
sudo nvpmodel -q --verboseNote that one can get a max performance mode or any other mode and then max out the clocks for that mode via “sudo jetson_clocks.sh”.
OC alarm 0x1 on Jetson nano means input voltage drops below safe operating voltage ~4.5V. Please make sure you have a stable input 5V@4A power supply.
Thank you for clearly explaining the meaning of the error message.
However, as I mentioned earlier, when I powered the Jetson with a LiPo battery and checked the voltage, the multimeter showed 5.2V… The LiPo battery I used was 2,200mAh 3S with a BEC of 5.2V.
I’m not sure what the problem is..
Could this issue cause an infinite reboot?
In fact, most of the test flights went smoothly, but Jetson did experience an infinite reboot on one occasion.
You need to get the UART logs when the reboots happen to debug this issue further. Screen shots won’t help here.
Battery voltage when powering up does not help here. You need to know the actual measured voltage VDD_IN input to the Jetson module connector when the reboots happen. The battery voltage may be dropping below the minimum threshold required for normal operation. You could experiment with other battery topologies like 2S2P if that is an option. For example, if you have four 3.7V 2000mAh Li-ion cells, a 2S2P configuration would result in a 7.4V (3.7V x 2) 4000mAh (2000mAh x 2) battery pack.
Overcurrent would most likely not cause infinite reboot. It is quite likely that the nvpmodel and enforcing a power model is completely unrelated.
As mentioned by @sgursal, by far the easiest and most detailed way of finding a reboot reason is via serial console. Unlike the dmesg command which only runs in Linux, the serial console is active even during boot phases long before the Linux kernel is even loaded. Even if the failure is within Linux it is often just a symptom to something which was previously set up during a boot phase, and thus knowing the full serial console log is rather important.
As an added detail, serial console is very simple. It is just a serial UART with a stream of characters and almost no driver requirement. Even when the rest of the system is crashed and burning the serial console usually survives and provides output. The actual interactive part, including logging, occurs on another computer; thus the display of serial console has no software and no hardware at all for the system being diagnosed (that requirement falls to a known working host PC). The settings for a serial console are speed 115200, 8 bits, 1 stop bit, and no parity. Here is some information on serial console:
https://www.jetsonhacks.com/2019/04/19/jetson-nano-serial-console/
Is this a Jetson Nano developer’s kit? If not, and if this is a module attached to a third party carrier board, then use of the wrong firmware is probably the most common issue. A third party carrier board requires different firmware.
Regarding the battery, does this particular Jetson work correctly when powered by some other method? My guess is that you will say “no” since the OC limit has been the topic, and what OC limit does is normally to limit performance and not cause a shutdown. By the time you get a power supply which is too high of an output, or if something on the board is for some reason drawing a pathological amount of electric current, something most likely has obviously “fried”. When there is an actual component failure of power, then the unit just doesn’t turn on at all, even for a fraction of a second.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.