Hi,
I need to free up some UARTs on the Fin. I could do with two but I’d settle for one. It seems the coprocessor setup is hogging the only available UART on the board, bu Al my firmware is already on an STM32 and I dont want to port it over.
How can I achieve this?
Thanks.
Hi @clong - the balenaFin has a full-spec compliant HAT that exposes UART0 on GPIOs 14 ,15. You can also remap UART1 on HAT pins and achieve 2 UART interfaces by setting the dtoverlay=uart1,txd1_pin=32,rxd1_pin=33 (change 32and 33with the pins you want to map against). Compared to a standard RPI3/3+ , when you remap UART1 you don’t loose Bluetooth functionality because the balenaFin radio chip handles it via SDIO and not UART.
I’m having this issue too. I tried enabling a second uart using dtoverlay=uart1,txd1_pin=32,rxd1_pin=33 but it can’t seem to connect to it as a Linux device - should I expected it to be /dev/ttyAMA1, or /dev/ttyS0, or something else? And are there any other boot arguments I need to add?
Also, the docs here https://www.balena.io/docs/reference/OS/advanced/ seem to suggest that Bluetooth is on uart0 and that the mini-uart is still on uart1, have they just not been updated?
EDIT: I’ve tried the following
dtoverlay=uart1,txd1_pin=32,rxd1_pin=33
dtparam=uart0=on
dtparam=uart1=on
It causes the second UART to show up under /dev/ttyS0. However, it also causes the device to reboot after a minute
Hey @joshbot we’ve been looking at this for you.
The docs that you’ve linked are referring to the Raspberry Pi which is a little different to the Fin. On the Pi the Bluetooth module is connected via a UART whereas on the Fin it’s connected via SDIO and does not conflict with the use of either UART.
I’ve just tested it on my personal balenaFin v1.1 and I only needed to add uart1,txd1_pin=32,rxd1_pin=33 to enable /dev/ttyS0. You definitely should not be getting any rebooting after a minute as a result of this! Could you confirm what Fin version and what OS version you’re using?
Hi @chrisys, it is on a balenaFin v1.0, running balenaOS 2.29.2+rev7. It seems that just enabling the uart is enough for it to cause the reboot after a minute of powering on, without connecting up anything to the pins.
Is this something that works differently on the Balena Fin v1.1 compared to v1.0? Most of the pins look identical. I know the coprocessor is different though
@joshbot the difference is that on the v1.0 the coprocessor is interfaced from the CM3 via USB through a FTDI USB->serial converter IC. On the v1.1 it is directly connected to the CM3 via GPIO 32/33.
What are you trying to achieve? If you could give an overview I can try and work through it. Also, if you’d like us to take a look you could enable support access on your device and share the link here, but I’ll set up a test on a v1.0 and see what happens too. 
Just to confirm, I’ve just tested the same uart1,txd1_pin=32,rxd1_pin=33 setting on my v1.0 Fin and it looks healthy, so if you’d like to enable support access and share your device we’ll take a look.
Thanks for your response @chrisys. I am wanting to have two independent uarts enabled, the first one (uart0) pins 8 and 10, and the second one (uart1) also enabled on pins 32 and 33
To my understanding the first uart pins are fixed to 8 and 10, but the second one can be chosen. The second uart does not work correctly - it shows up at /dev/ttyS0 when enabled but the device reboots shortly after. I have tried other pins for the second uart but with no success. We need both uarts since we need to be able to have to TTL lines for comms.
I’ve sent you a message about support access.
Hi Josh, sorry for the delay, I’ve only just got a chance to look at this again. I can see the device online now. I see your current RESIN_HOST_CONFIG_dtoverlay is set to "balena-fin". I have my test v1.0 set to "balena-fin","uart1,txd1_pin=32,rxd1_pin=33" which is working OK. Our team accounts are not permitted to change your app otherwise I’d try it for you.
Just for clarity’s sake and incase you weren’t aware: the numbers that are specified are BCM GPIO numbers rather than pin numbers on the HAT connector, and there are some limitations with regards to what you can define. If you take a look at this page: https://elinux.org/RPi_BCM2835_GPIOs you’ll note that the only pins exposed on the HAT connector that can be used as TXDx and RXDx are GPIO14 and GPIO15. There are a few other GPIOs that can be used with the UARTs but these aren’t exposed. GPIO32 and GPIO33, which can function as a UART, are connected to the co-processor on the board. Therefore you are able to switch UART0 and UART1 around into either position, but you aren’t able to expose both on the HAT connector simultaneously. I hope this makes sense.
That being said however, you should not be experiencing reboots when you set up the second UART on 32 and 33 so we can continue to look in to what’s going on there.
Hi Chris, no worries. If it is only possible to have EITHER UART 0 or UART 1, this won’t be any use as the only reason we wanted to enable both was to have two UARTs functioning simultaneously. I didn’t realise that there weren’t any other pins that it could be mapped to.
About the rebooting issue - perhaps it is sending a signal that is misinterpreted by the coprocessor and then rebooting it?
@joshbot I’ve not looked into it in great detail (yet) but thinking about it, it seems theoretically possible to build a firmware for the coprocessor that functions as a passthrough for the second UART from the CM and exposes it on the second GPIO header.