UART1 issues

[arnaudlanger]

Hi,

I tried to use the serial port (UART1) on the DevBoard, but i can’t even open the file /dev/ttys1.

Indeed, the function open("/dev/ttys1", O_RDWR | O_NOCTTY | O_NDELAY)
returns the following error open failed with errno 2 (No such file or directory)

In the /dev directory, the file “ttys1” (lowercase ‘s’) is enumerated and not “ttyS1” (uppercase ‘s’). Although, just to make sure, i tried to open both of them and the same error occurs.

How can I open the file corresponding to the serial port on UART1 ?

Regards

[davidc]

Hiya,

I’ve just had a look at the /dev directory on my board here. There are a couple of devices - ttyHSL0 and ttyHSL1 that look promising - especially since the device is (a) a character device; (b) belongs to the group ‘dialout’, and © the major number (249) is in the experimental device nodes range.

There are no character devices with a major node of 4 and a minor node of 64(or greater) which is where the traditional serial ports (ttyS0 etc) are located. the ttys0 node you’re trying is a pseudo-tty device and may not even be physically present…

There’s a few posts in mailing lists indicating that ttyHSL0 is mapped to the console in some adb/android devices … so I would look at trying to open ttyHSL0 (UART0) and ttyHSL1 (UART1) - just watch that you don’t clobber the serial console when opening ttyHSL0.

Just my thoughts.

ciao, Dave

[amitchell]

Hi,

David is right. ttyHSL0 is actually UART1 on the dev kit and is normally allocated to be the console. ttyHSL1 is UART2 on the dev kit. They are the only 2 available on this chipset.

You can find out a lot about the peripherals by looking at the BSP test report spreadsheet that is included with the Yocto source bundle we provide. It has test procedures for exercising the various peripherals. If you don’t have the Yocto source bundle and don’t want to download it let me know and I’ll put it somewhere for you.

Andrew

[arnaudlanger]

Hi,

Thanks for the hint, indeed it seems more logical to use ttyHSL1 …

I encountered another problem though.
The open C function returns now an errno 13 : Permission denied. I suspect a group membership problem …

I have trouble understanding which user is used inside the sandbox, is it root (the login user) or appRS232 (my application is named RS232) ?

If it’s appRS232, how can I add him to the dialout group ? (useradd isn’t available on the AR7)

Thanks by advance !

Regards,

[amitchell]

Hi,

did you map the device into your application in your adef file?
(legato.io/legato-af/14_04/de … importAdef)

If you did, and you don’t have permissions to access it, then we may have a bug there. If you can detail what you did then I can have the guys here have a look at it. In the meantime, you can always directly modify permissions on the target as you have root access - just remember what you did so that you can undo it again.

Andrew

[arnaudlanger]

Hiya,

So there is the content of the project:

• Here is the .c file:

COMPONENT_INIT { // Open the serial port. int fd1 = open("/dev/ttyHSL1", O_RDWR|O_NONBLOCK); LE_ERROR_IF(fd1 == -1, "HSL1 open failed with errno %d (%m)", errno); }

• And here is the .adef file:

executables: rs232 ( "rs232.c" ) import: [rw] "/dev/ttyHSL1" "/dev/" processes: envVars: LE_LOG_LEVEL = DEBUG run: (rs232)

• And here is the output when I start the app

13:55:33 INFO | supervisor[835]/supervisor T=main | proc.c StartProc() 849 | Starting process rs232 with pid 2539
13:55:33 INFO | supervisor[2539]/supervisor T=main | proc.c StartProc() 823 | Execing ‘rs232’
13:55:33 INFO | serviceDirectory[840]/serviceDirectory T=main | serviceDirectory.c DispatchClientToServer() 540 | Client (pid 2539) connected to server 844 for service (LogControlProtocol:LogClient).
13:55:33 DBUG | rs232[2539]/default T=main | _main.c main() 33 | == Log sessions registered. ==
13:55:33 DBUG | rs232[2539]/default T=main | _main.c main() 42 | == Starting Event Processing Loop ==
13:55:33 =ERR= | rs232[2539]/default T=main | rs232.c _default_Init_Function() 433 | HSL1 open failed with errno 13 (Permission denied)

The file ttyHSL1 is imported into the sandbox correctly

13:55:33 INFO | supervisor[835]/supervisor T=main | sandbox.c ImportFile() 415 | Imported ‘/dev/ttyHSL1’ into sandbox ‘/tmp/legato/sandboxes/RS232/dev/ttyHSL1’.

Here it is

root@swi-mdm9x15:/var/volatile/tmp/legato/sandboxes/RS232/dev# ls -al
drwx—r-x 2 root root 100 May 26 13:55 .
drwx-----x 7 root root 140 May 26 13:55 …
srw-rw-rw- 1 root root 0 Jan 1 1970 log
crw-rw-rw- 1 root root 1, 3 Jan 1 1970 null
crw-rw---- 1 root dialout 249, 1 Jan 1 1970 ttyHSL1

Thanks for the help,

Regards

[johnofleek]

Hi

I am trying a similar thing -i would like to use /dev/ttyHSL1

I am trying to use without a sandbox

my .adef looks like this:

sandboxed: 
    false

executables:
    helloWorld ( "helloWorld.c" "modbus/modbus.c" "modbus/modbus-data.c"
"modbus/modbus-rtu.c" ) processes:
    envVars:
        LE_LOG_LEVEL = DEBUG

    run: (helloWorld)

When i execute the app I see

06:36:31 INFO | helloWorld[29828]/default T=main | modbus-rtu.c _modbus_rtu_connect() 327 | Opening /dev/ttyHSL1 at 115200 bauds (N, 8, 1)
06:36:31 INFO | helloWorld[29828]/default T=main | modbus-rtu.c _modbus_rtu_connect() 477 | ERROR Can’t open the device /dev/ttyHSL1 (Permission denied)

Any ideas ?

Thanks in advance

John

[esun]

Hi,

I have trouble understanding which user is used inside the sandbox, is it root (the login user) or appRS232 (my application is named RS232)?

Each app has its own user ID and primary group ID. User name and primary group name is “app-xxxx”, where the “xxxx” is replaced with the name of the app.

If it’s appRS232, how can I add him to the dialout group ?

Sandboxed apps aren’t allowed to be members of other groups and are not allowed to have any capabilities (see “man 7 capabilities”) set on their executables.
Unsandboxed apps are allowed to have executables with capabilities and be members of other groups (see the “groups:” section).

So using the .adef example from John, include a groups: section and add ‘dialout’

sandboxed:
    false

executables:
    helloWorld ( "helloWorld.c" "modbus/modbus.c" "modbus/modbus-data.c"
"modbus/modbus-rtu.c" ) processes:
    envVars:
        LE_LOG_LEVEL = DEBUG

    run: (helloWorld)
groups:
    dialout

I was able to get it running without the ‘Permission denied’ error.

Hope this will work for you guys,
Enoch

[johnofleek]

Hi Enoch

Thanks for the help.

I’m (trying) using Dev Studio. I tried adding groups yesterday to the .adef but the Dev Studio tool:

1. Doesn’t have groups (actually it doesn’t have sandboxed …) in its section selection
2. I manually hacked groups into the .adef file - but when I open the .adef in Dev Studio the tool moans and messes up the .adef file - then the app won’t build due to the messed up .adef

Am I just seeing a bug in Dev Studio?
Did you build outside Dev Studio?
Do the .adef sections have to be in a particular order?

In a practical system:
Will the apps which talk to real hardware need to be outside sandboxes?
Will sandboxed apps be able to communicate with unsandboxed apps (I’m guessing not)?

Thanks in advance

John

[daav]

We still have some troubles on the adef files editor (currently still working on it).
To avoid being annoyed by the editor, you can simply open the adef file in the text editor (Right Click Menu > Open With > Text editor)
Improvements on that are coming with DS 3.1

[esun]

1. Did you build outside Dev Studio?
2. Do the .adef sections have to be in a particular order?

In a practical system:
3. Will the apps which talk to real hardware need to be outside sandboxes?
4. Will sandboxed apps be able to communicate with unsandboxed apps (I’m guessing not)?

1. Yes I did.
2. Nope, order does not matter
3. No, but at the moment (UART) yes because sandbox does not provide the capability of adding a user to groups.
4. Yes, a sandboxed app should be able to communicate with an unsandboxed app via IPC.

[arnaudlanger]

Hiya,

I unsandboxed my app and added the ‘dialout’ capability to the executable file like Enoch suggested.

This solved my problem, now I can send and receive characters through the UART1 port (ttyHSL1) using GtkTerm.

I have an error when editing the .adef file though,

groups: dialout

no viable alternative at input ‘groups’

But it doesn’t prevent me from compiling the app. Is it an error which comes up with the DS3 parser ?

Thanks for the help !

[esun]

Nice, I’m glad it worked for you

As for the error editting the .adef file, it seems like it’s an issue with the current DS3 parser. To workaround this issue, please follow the suggestion provided by daav.

To avoid being annoyed by the editor, you can simply open the adef file in the text editor (Right Click Menu > Open With > Text editor)
Improvements on that are coming with DS 3.1

[daav]

@arnaudlanger

Is it an error which comes up with the DS3 parser ?

Yes, this is a known issue of DS 3.0; this will be fixed in DS 3.1

[buzzag]

Hi! I’m facing another problem accessing UARTs…

I have normal access to ttyHSL1, currently in use as debug port (UART2), but no HSL0 is shown in my /dev.
Is there any AT command I must perform to make it visible? Or it’s hidden somewhere?

Thanks,

[shruthipawar]

hii…
I have started wrking on the AR-WP series development kit .
I went through the user guide . It says that to connect UART 2 for the serial communication. I enables the UART2 ON and plugged . But i dint see any reply in serial console window .
Just fr cross verification i plugged to UART1 and enabled the UART1 ON , I could see the booting n poer on the kit i could see thebooting sequence .

Kindly help me out which is correct to wrk with . in all the manuals they have mentioned UART 2 only

[amitchell]

Check out this post:

https://forum.sierrawireless.com/t/uart1-with-beta-14-07/11959/1

Hopefully that will help.

[shruthipawar]

Thanks amitchell …

[buzzag]

Thanks amitchell … [2]