UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor trjeppsdl
Visitor
6,491 Views
Registered: ‎02-09-2015

Can't send break command via UART in Petalinux 2015.2

Jump to solution

I'm working on two very similar zynq projects, one running Petalinux 2014.4 and the other 2015.2

 

ctr+c break commands are recognized in 2014.4 but not in 2015.2

 

Electrically, the hardware is the same for both. Is there a kernel setting somewhere that might be at fault?

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Visitor trjeppsdl
Visitor
11,769 Views
Registered: ‎02-09-2015

Re: Can't send break command via UART in Petalinux 2015.2

Jump to solution

Progress! It seems to stem from using autologin, rather than the version of Petalinux.

 

if I "exit" then re-log in as root, all break commands I send are successful. 

 

I used the autologin method described here:

http://www.xilinx.com/support/documentation/sw_manuals/petalinux2014_4/ug1144-petalinux-tools-reference-guide.pdf

 

Is there any part of this that is restricting my permissions? 

View solution in original post

0 Kudos
4 Replies
Scholar austin
Scholar
6,474 Views
Registered: ‎02-27-2008

Re: Can't send break command via UART in Petalinux 2015.2

Jump to solution

t,

 

Are you in the PetaLinux shell, and if so, are you executing the exact same command (application)?

 

Does it not work for all/any commands (applications)?

 

As the only change is software, that must be the cause.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Visitor trjeppsdl
Visitor
6,455 Views
Registered: ‎02-09-2015

Re: Can't send break command via UART in Petalinux 2015.2

Jump to solution

Yes, I'm in the PetaLinux shell, but I'm not executing the same application. However in both scenarios I'm executing elf files compiled in SDK.

 

Your next question led me to some interesting things. in my 2015.2 project, I can successfully terminate "top" and "fdisk" with ctrl+c, but I can't terminate a "ping localhost" command.

 

From there, I logged into the same system via telnet in a second instance of teraterm. Through the telnet terminal, I can terminate any application.

 

All in all, it almost feels related to permissions/process priorities. The terminal is correctly sending the break command, and the system is correctly interpretting it (in the cases of top and fdisk) it just seems like I'm not being allowed to terminate processes based on some other criteria.

 

 

0 Kudos
Highlighted
Visitor trjeppsdl
Visitor
11,770 Views
Registered: ‎02-09-2015

Re: Can't send break command via UART in Petalinux 2015.2

Jump to solution

Progress! It seems to stem from using autologin, rather than the version of Petalinux.

 

if I "exit" then re-log in as root, all break commands I send are successful. 

 

I used the autologin method described here:

http://www.xilinx.com/support/documentation/sw_manuals/petalinux2014_4/ug1144-petalinux-tools-reference-guide.pdf

 

Is there any part of this that is restricting my permissions? 

View solution in original post

0 Kudos
Scholar austin
Scholar
6,446 Views
Registered: ‎02-27-2008

Re: Can't send break command via UART in Petalinux 2015.2

Jump to solution

Interesting,

 

Why would the telnet allow it to always work?

 

Note that there is such a thing as a break command, which is NOT control-c, but a true de-assertion of the receive, which is left over from the teletype days where an open current loop was a real 'break' and was recognized as a kill command.  UART hardware to this day can be commanded to 'send' a break, and will create an interrupt if it receives a break.

 

Control-z is sometimes used to stop a process as well.  If you are using a getchar() from the Linux libraries, that should be able to return the control-c, and thus you have to check it to see if you need to stop if your program is waiting for keboard data.

 

If you never call getchar() in your program, then maybe the control-c is never being caught.  The telnet session is a layer which always is able to get a character?

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos