I want to use a BBBlue with a minimal Debian 12 image and apparently the devicetree is incomplete/wrong/broken. My initial list of broken peripherals is
Uarts are also working. LibRobotControl just uses the wrong naming Scheme which is fixed by this commit.
The Issue with the Power Button is caused by a second include of the PMIC file which invalidates all changes from the SOC file, e.g. disables the Power Button again. Fixed by Commit .
Why is the property “ti,pmic-shutdown-controller;” still in am335x-osd335x-common.dtsi and then removed in the board file? I read it can break the board.
BTW: I’ll move my gitlab work to github, if it is possible to start a merge request from there.
I’d noticed that trying to use the PRU to control the servo output pins on Debian 12 wasn’t working. The same code was fine on Debian 10. I suspected something to do with device trees, but didn’t have the time or knowledge to dive deeper into it. I hope this will fix it.
The PWM pins are currently not the top of my list. I’m trying to get the Motors running via PWM.
But absolutely nothing happens.
Is there some trick to it?
I believe I set the correct pins, and I basically copied the steps from librobotcontrol.
# set MOT_STBY
gpioset gpiochip0 20=1
# set MDIR_1A
gpioset gpiochip2 0=1
# set MDIR_1B
gpioset gpiochip0 31=0
# goto PWM for Motor 1
cd /dev/bone/pwm/1/a
# set period nanoseconds for 25kHz 1'000'000'000 / 25'000 = 40'000
echo 40000 > period
# set polarity to normal
echo normal > polarity
# set duty cycle to 20%
echo 8000 > duty_cycle
# enable pwm
echo 1 > enable
Note: the state of a GPIO line controlled over the character device reverts to default when the last process referencing the file descriptor representing the device file exits. This means that it’s wrong to run gpioset, have it exit and expect the line to continue being driven high or low. It may happen if given pin is floating but it must be interpreted as undefined behavior.
This section actually does spin a 12V-something motor from an arduino kit.
gpioset -m signal gpiochip0 20=1 &
gpioset -m signal gpiochip2 0=1 &
gpioset -m signal gpiochip0 31=0 &
cd /dev/bone/pwm/1/a
echo 40000 > period
echo normal > polarity
echo 8000 > duty_cycle
echo 1 > enable
OK, shit happens, apparently I fried my board today.
I ran this setup for a week or two now with a 12V 2A power supply, a self soldered 2S 18650 battery pack and I thought everything was fine.
Until that 12V power supply broke down this morning and I replaced it with a new one. 12V 3A.
Some sparks later I pulled the plug and was left with a burnt charger chip and a shot on the 12V line.
Just for info,
the board is ok, the MP2615 was desoldered with a hot-air-reflow-station.
Had to go up to 390 degC because the board sinks heat too well.
With the MP2615 removed the 12V domain is ok and V_Batt is obviously 0V.
Measured the MP2615 and it had short circuit between Pins 1, 2 and 16, means the transistors burnt through. I see there is a Revision C available, so I’ll order that as a replacement.
If it’s any help, I’ve got a Blue happily running by soldering a diode (to drop a volt or two) from the incoming 12V to the high side of the battery connector. I did this as I wanted to use the servos without needing a LiPo. Obviously, adding a battery to this setup would be a bad idea, so I covered the battery connector.
I already have the MP2615 after Digikey / UPS broke a 2-day record from Minnesota to my doorstep in Germany.
Just have to fetch new solderpaste, the old one from 2018 has gone bad in the fridge and after one appempt to handsolder it, I gave up because the pads are too short for that.
Just wanted to tie some loose ends here.
I have Hot-Air-Soldered a MP2615GQ-Z and I’m sure it has connection and no shorts.
But for whatever reason I’m only getting 0.7V from Batt_Minus to Batt_Mid and 2.2V from Batt_Mid to V_Batt.
There must be something other broken as well, so I’ll drop this project
