I want to take advantage of the PRUs quick IO. However I have come across this oddity: A few bits in R31 are set even tho I have nothing connected to the pins.
For my particular problem I want to read the first byte of R31 on PRU1 (That would be P8_39 to P8_46)
To achieve this I have installed a fresh version of Linux 4.19.49-ti-r42,
deactivated the video overlay by commenting in disable_uboot_overlay_video=1 in /boot/uEnv.txt,
rebooted,
and set the pinmux with config-pin P8_39 pruin (and so on)
My program just reads R31 for a few cycles and puts the results in an array that is send via rpmsg.
Now here is the bit that I don’t understand. For some reason I receive an array filled with 3C instead of zeros. Only when I ground the 4 middle pins I get zeros across the board. The other 4 bits behave as I expected.
I was wondering why that would be? I tested this with another device as well with the same result, so it isn’t broken. Is there another setting that I have to do? Is something else interfering?
I’d like if all my pins behaved the same. It feels like there should be a nice solution that doesn’t involve peripheral electronics or additional data manipulation on my end. Any help or advice would be greatly appreciated!
Capacitive effects pull up some lines over the 0V8 high-level → enable pull-down resistors. I’m not sure if config-pin can set pull-down resistors for PRU-GPIO; libpruio can.
finally had the opportunity to try it out (seemed like overkill at the time, but I needed it for something else later). Making a device tree overlay with the help of dts_custom.bas fixed the pull-down. It’s actually rather handy for making device tree overlays in general.
The guide is horribly out of date, so if anyone ever needs it in the future here are the steps:
Install FreeBASIC on your bone, clone the git
cd libpruio/src/config/
fbc -w all dts_custom.bas
sudo ./dts_custom /lib/firmware
nano /boot/uEnv.txt
and add this line uboot_overlay_addr4=/lib/firmware/pruio_custom-00A0.dtbo
P8.31 - P8.46 have external pull-up or pull-down resistors (direction varies per pin) on the board, since these pins are sampled at power-on to select boot configuration. Configuring internal pull-up/down on these pins is not recommended since if the internal and external pull oppose each other, this will create an intermediate voltage level (neither quite logic-low nor logic-high) that can cause unpredictable results.
If you want to use these pins as inputs, they should be driven push-pull by external hardware, i.e. if you want them to read low, drive them low, and their level when undriven should be regarded as undefined. Be careful however to avoid driving these pins until after reset has been released, since overriding these pins immediately at power-on is likely to result in boot failure.
For per-pin details, see the P8 tab of my pins spreadsheet. It shows the external pull direction of these pins (L* = external pull-down, H* = external pull-up), and it also shows for which of these pins the logic level at power-on is critical for boot (highlighted in eye-stabbing yellow). Note also that the S2 button (aka boot button) pulls P8.43 down with 100Ω while pressed.
Does that mean that I am just lucky that it even boots? Should I be concerned or is it one of these ‘if it works it works and we never touch it again’ situations?
If you know, how would I detect a successful boot, so that an external pulldown can be applied by external hardware? Not that It is too big of a deal disconnecting the cables for booting, it might be nice to know for the future.
Depends on what you’re doing with which pins. If you are externally driving (or strongly pulling) one of the critical sysboot pins (the ones marked in yellow in my spreadsheet) to a level opposite of their default, and you’re doing this during power-on (between the 3.3V supply powering up and reset being released) then you will almost certainly fail to boot.
Once the reset line (P9.10) is high it’s safe to externally drive these pins. For example you could use a push-pull buffer with active-high output-enable input connected to P9.10.