When creating a new application I do not see an option to select ‘UP Squared’ even though it is listed as supported here: https://www.balena.io/docs/reference/hardware/devices/
I was able to upload an ‘UP board’ image to the ‘UP squared’ board. Most things seem to work if I do this. However, I cannot get the GPIO pins to work.
Hi,
I don’t have an UP board here to test the GPIO. But can you share how are you trying to use GPIO pins and what error messages do you have? How does your application look like? Especially Dockerfile / docker-compose.yml, etc.
P.S. It’s enough to select UP board, this device covers UP board, UP core and UP squared.
I’ve made everything as simple as possible. The dockerfile contains the following:
FROM balenalib/up-squared-ubuntu:bionic
CMD ["bash"]
I push it to a local device using balena push x.x.x.x. Then I login to that device: balena login x.x.x.x main. Then I run the following commands to switch the gpio output (Based on https://wiki.up-community.org/Pinout_UP2):
cd /sys/class/gpio
echo 478 > export
cd gpio478
echo out > direction
cat direction # returns out
echo 1 > value
cat value # returns 0 :-(
I don’t get any errors. I am able to set the direction but not the value.
Based on the link you shared, it seems that 478 is configured /dev/ttyS1 (UART1_RTS). As a first thing, can you try to use any other pin just to see that it works. Like 432 for example?
I tried a couple. None of them work. I tried 432 specifically just now with the same result.
Thanks. I found an issue with similar symptoms. I asked our devices team what’s the UP square support status and if there’s anything you should do to make it working. We’ll come back to you once we have an answer.
Hi,
I opened an issue for you where you can track progress / discussion / … The last thing - what balenaOS version are you using?
I opened it because the devices team said that it should work. Also they confirmed that the UP board covers all three devices (core, squared, board).
2.29.2+rev1
Thanks, I just updated the issue with this information!
I have put the newest version of balena (balenaOS 2.39.0+rev1) on the up squared and I can now control the GPIO pins. So that is one step forward!
However I am now trying to get the i2c working. I can see the device when I run i2cdetect -r -y 1. However when running the code two errors (repeatedly) pop up (in dmesg):
[ 122.612212] broxton-pinctrl INT3452:03: failed to find community for pin 405
[ 123.634857] i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration
I don’t seem to be able to communicate with the device properly. An important thing to mention is that we also control the device using the pin number 18 (Linux gpio pin 405). This is used to turn the device on and off.
Curiously enough (and I don’t know if this is related) when I check for the devices as follows:
ls /sys/bus/pci/devices/*/i2c_designware.0/ | grep i2c
The command returns i2c-1 instead of i2c-6 as is mentioned in the documentation here: https://wiki.up-community.org/Pinout_UP2#I2C_ports
Glad to hear that GPIO is working! Regarding i2c, unfortunately I don’t have an UP board here for me to try, but I wonder if the following Raspberry Pi-centric documentation on I2C also applies to the UP board – especially the point regarding adding modprobe i2c-dev to your Dockerfile:
https://www.balena.io/docs/learn/develop/hardware/i2c-and-spi/#i2c
Actually, that same page I linked has a section about the Intel Edison device, and reads:
“the best and easiest way to interface with GPIO, I2C, SPI or UART on the Intel Edison is to use the MRAA library, this library gives you a simple way to write C, python or Node.js applications that interact directly with the Edison hardware.”
The UP board is Intel-based like the Edison, and looking at the documentation for the MRAA library, it mentions the UP squared board as a supported board:
I already added the modprobe i2c-dev and I am using the mraa library for the code. The same code works on a normal up-board (even without the modprobe i2c-dev) but not on the up squared.
Okay, thanks. I’ve found a thread whether the OP says they got around the arbitration problem by “changing the bus speed to 100Hz”: https://forum.up-community.org/discussion/2058/i2c-arbitration-error-help
And the “failed to find community for pin” error seems to come from this line of driver code: https://github.com/torvalds/linux/blob/master/drivers/pinctrl/intel/pinctrl-intel.c#L134
I have also asked our devices team for suggestions on how to debug this further.
I have tried increasing the bus speed, but that doesn’t seem to help.
I’ve tried a lot of things now to get things working, without success unfortunately. Here is some more detailed info on what kind of problems I’m running into:
The code I am trying to run is the driver for a mpu6050 imu. The board is connected to pin18 (GPIO24 on the up board and BMC24 on the up squared) which I need to set to ‘true’ to turn the imu on (this was made so that we can hard reset the board). The device shows up on the up board and the driver works. However on the up squared the device does not show up (with i2cdetect) nor does the driver work.
Switching pin18 off doesn’t fully switch off the device. Thus it still shows up if I run i2cdetect on the up board. Interestingly it ALSO shows up on the up squared board. The driver does not work on either board. However some communication does happen on both boards. Suggesting that in these settings the i2c is working (but the device won’t work as it doesn’t get enough power).
I noticed that the possible bus frequencies of the up board and up squared differ. See https://iotdk.intel.com/docs/master/mraa/up2.html and https://iotdk.intel.com/docs/master/mraa/up.html . Though it seems that the ‘standard mode’ is used as a default for the bus frequency (see https://downloads.up-community.org/download/up2-uefi-bios-v2-1/) and I couldn’t find it as an option in the bios.
I’m completely stuck at this moment. Any help would be greatly appreciated!
PS: On the balena up board both balenaOS 2.39.0+rev1 and balenaOS 2.29.2+rev1 work
Hi,
August is a bit of a holiday season and quite a few guys are away at the moment.
What I can suggest is that at this point, things are frustrating enough that we need to take a step back and go step by step.
Usually my first try at times like these is to go back to the distro that came with the device and confirm my hardware setup/pinout/wiring combination etc works. Check and note down the exact dt overlays, gpio numbers, i2c numbers, i2cdetect etc.
Also note down the kernel versions and probably the output of cat /proc/config.gz | gunzip -d to know what kernel drivers are enabled/modules.
Output of lsmod perhaps.
If the hardware works fine on up squared default distro, then try via balenaOS hostOS and see what is working/not working going step by step…
Regards,
ZubairLK
Just a small update. I tried to see if I could find my i2c device with an image without balena. But the same behavior seems to occur. I am going to try a different i2c device to see if I can get that to work.