Container can´t access /dev/ttyAMA0

Product support balenaOS
, , ,
1

Hi there,

our Application does need access to /dev/ttyAMA0 to use Bluetooth in our Stack. On our pre-balena raspbian with docker installed the container can easily access the interface with the --devices flag:

docker run --device=/dev/ttyAMA0 tower -h 172.16.10.13

Using this as our base to deploy our application to balena we figured out following procedure, which is still not working:

FROM balenalib/armv7hf-debian-openjdk:11-jre-stretch

WORKDIR /app


COPY wiringpi_2.50_armhf.deb wiringpi_2.50_armhf.deb 

RUN dpkg -i wiringpi_2.50_armhf.deb

RUN apt-get install bluez

ADD tower.jar tower.jar

COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

CMD ["java","-jar","/app/tower.jar"]

version: '2.1'
networks: {}
volumes:
  resin-data: {}
services:
  tower:
    build:
      context: .
    privileged: true
    tty: true
    restart: always
    network_mode: host
    volumes:
      - 'resin-data:/data'
    command: -h 172.16.10.13 --debug
    devices:
      - '/dev/ttyAMA0:/dev/ttyAMA0'
    labels:
      io.resin.features.kernel-modules: '1'
      io.resin.features.firmware: '1'
      io.resin.features.dbus: '1'
      io.resin.features.supervisor-api: '1'
      io.resin.features.resin-api: '1'
    cap_add:
      - SYS_RAWIO
      - NET_ADMIN
  hostname:
    build: ./hostname/
    restart: no                               # Required to avoid container restarting indefinitely
    labels:
      io.balena.features.supervisor-api: 1    # Required to interact with the supervisor

I already run out of ideas, maybe we are missing just a small part of it.

Feel free to ask questions, ill give my best to answer all of them.:smiley:

2

Maybe some ideas of the problem:
Inside the container:

image
image709×185 3.73 KB

Host os:
image

3

Hi,

thanks for your report. Just to be sure - do I understand correctly that the device in question is a Raspberry Pi 3? As for the device - I can see your container is privileged, that should mean all the devices are populated inside the container on creation and accessible. So to debug further, could you please check the following:

  • Can you see /dev/ttyAMA0 on the host OS?
  • Can you see /dev/ttyAMA0 within the tower container?
  • Is there any particular error message you are getting from your application?

Thanks

6

hy @mtoman
thank you for your reply!!!

Indeed the fleet runs on RPi3

I asked the question on my company user account again @Markus.Kohn.GWA

Anyway:
Im able to see /dev/ttyAMA0 inside hostOs and Tower container.

The problem is:
The software running in the tower container does not use hci. It wants to send its ohn commands to the serial interface/ Bluetooth device.
Which is most likely already in use by another process.

So the goal would be to ensure that nothing else is initializing a bluetooth.service or hciattach beside the tower container

Best Regards

Markus

7

Hello,

Did you get a chance to look at our documentation regarding the serial interface? I2C and Other Interfaces - Balena Documentation

Also, you can try some of our examples that use serial to compare with your code:

8

If you’re able to see /dev/ttyAMA0 from host and from inside the container, the issue might be with the software (either trying to acquire multiple locks, or something else?), if you try another container, is it able to communicate with the serial interface?