pensioner
Posts: 3
Joined: Wed Jan 02, 2013 9:07 am

Uart problem

Fri Jan 11, 2013 8:30 pm

Was given a rev 1 model B for Christmas. Have got the GPIO working OK, but can't get the UART going.

I'm following the recipe given here:

http://www.raspberry-projects.com/pi/pr ... g-the-uart

At this point I'm interested in Rx from another device, not Tx as yet. The open of /dev/ttyAMA0 works OK, but the read fails immediately with return code -1, errno = 11 (Resource temporarily unavailable). But whatever the resource is, it never becomes available. This is before I even connect up the serial comms (and yes, I have done a level change).

I have done the mods to /boot/cmdline.txt and /etc/inittab to disable kernel boot msgs, debug, and login described in the quoted article and other places on the web. I've tried explicitly reconfiguring the pins as ALT0, even though they are supposed to be that at boot. I've pratted with the open and config parameters until I'm out of ideas. Rebooting doesn't fix it.

I'm an old, retired programmer and electronics hobbyist. I'm reasonably fluent in C, but know next to nothing about Unix/Linux. Where should I start looking for further diagnostics?

sdjf
Posts: 1395
Joined: Fri Mar 16, 2012 5:20 am
Location: California
Contact: Website

Re: Uart problem

Fri Jan 11, 2013 10:30 pm

I know zilch about UART but can say that it is pretty tough to debug things if you disable the services needed to do debugging. You might consider re-enabling them until you know you have a working setup.

You want to examine the logs in /var/log, and also run dmesg to see if the device was attached to any drivers.
FORUM TIP: To view someone's posting history, sign in, click on their user name, then on "Search User's Posts." || Running ArchLinuxArm on Model 2B and 512MB Model B

pensioner
Posts: 3
Joined: Wed Jan 02, 2013 9:07 am

Re: Uart problem

Sat Jan 12, 2013 10:12 am

Thanks for the pointers.

demsg shows just one line about ttyAMA0, which appears to be at boottime:

[ 0.576975] dev:f1: ttyAMA0 at MMIO 0x20201000 (irq = 83) is a PL011 rev3

Does this mean a driver is attached? Something seems to know something about it. Nothing in the demsg output changes after the failing 'C' code is run.

None of the logs in /var/log that have been updated recently contain anything about ttyAMA0 that I can find.

Take the point about disabling debug, but I know nothing about kernel debug nor how to use it. Is it debug of the kernel, or debug by the kernel of other things? Debug output to a port that doesn't seem to be working about a port that doesn't seem to be working doesn't sound the most useful to me, especially as I don't have a serial terminal to display it on. I'd have to resurrect an old PC with a COMn port, get it working again, build another level changer, don't have any spare MAX232 chips in the rummage box.. doesn't seem worth the hassle unless I could be sure it would solve the problem.

pensioner
Posts: 3
Joined: Wed Jan 02, 2013 9:07 am

Re: Uart problem

Sat Jan 19, 2013 9:12 am

This post has been up a week now, and it has attracted exactly one response, even that not very helpful. This is my first post on this forum anywhere, and I have to say I'm distinctly underwhelmed by the "very friendly" and "amazing" community who would "do their best to help" which is promised on the download page.

I've solved this problem now, some days ago actually. I now have my pi chatting happily to another bit of kit over a serial comms link using ttyAMA0 from 'C' code. The nature of the fix necessary leads me to suspect that nobody has really got this working properly before - or if they have, they haven't posted the answer anywhere Google can find it. But given the apathy in this forum, I can't be bothered to post the solution either - at least, not here.

User avatar
mahjongg
Forum Moderator
Forum Moderator
Posts: 13818
Joined: Sun Mar 11, 2012 12:19 am
Location: South Holland, The Netherlands

Re: Uart problem

Sat Jan 19, 2013 10:28 am

No replies?
There may be two reasons for this:
  • You posted in the wrong section, which gets less readers, and isn't about debugging hardware problems
  • Your Subject is too terse, and doesn't provide any actual clues about the nature of your problem
Also, did you bother to search the forum for previous answers about this issue?

If the local search engine gives unsatisfactory results, you can use the "search a site" option of google, which in your case would take the form:

site:raspberrypi.org uart

P.S. I took the liberty of moving (copying) this thread to a section where it may "get more eyeballs"

User avatar
rurwin
Forum Moderator
Forum Moderator
Posts: 4257
Joined: Mon Jan 09, 2012 3:16 pm
Contact: Website

Re: Uart problem

Sat Jan 19, 2013 10:56 am

There are a lot of posts on this forum. I regularly scan New Posts, but only the first page or so. I regularly miss many new posts if they do not stay at the top of the heap. This is the first time I have seen yours. You may have done better if you had posted in Hardware-Interfacing. But sorry for your bad experience.

The problem, and it's not really a problem, more that the supplied code doesn't hang together too well, is that the set-up code opens the UART in non-blocking mode, but the read code treats "no waiting data" (EAGAIN=11) as an error.

I think you will find that many people who have implemented a UART have baked their own code, often in a different language.

In fact this problem was posted on the forum and solved back in June. See: http://www.raspberrypi.org/phpBB3/viewt ... =33&t=7500

KC2O
Posts: 2
Joined: Tue Aug 21, 2012 6:44 am

Re: Uart problem

Thu Jan 31, 2013 7:45 am

pensioner wrote:This post has been up a week now, and it has attracted exactly one response, even that not very helpful. This is my first post on this forum anywhere, and I have to say I'm distinctly underwhelmed by the "very friendly" and "amazing" community who would "do their best to help" which is promised on the download page.

I've solved this problem now, some days ago actually. I now have my pi chatting happily to another bit of kit over a serial comms link using ttyAMA0 from 'C' code. The nature of the fix necessary leads me to suspect that nobody has really got this working properly before - or if they have, they haven't posted the answer anywhere Google can find it. But given the apathy in this forum, I can't be bothered to post the solution either - at least, not here.
It's a real shame that you've solved the problem yourself but feel so embittered that you cannot bring yourself to share the solution with others. My search for answers to a similar problem brought me here. Now all I've found is this statement that someone found an answer but is not going to tell me what it is.

Maybe you should examine your expectations of this hobbyist forum. Having one's needs met instantly is usually a feature of commercial support, and requires some kind of service agreement. The fact that other hobbyist users don't feel obligated to provide what you feel entitled to doesn't make them 'apathetic'.

User avatar
hicksonj
Posts: 13
Joined: Wed Aug 01, 2012 11:51 am
Contact: Website

Re: Uart problem

Thu Jan 31, 2013 8:48 am

pensioner wrote:This post has been up a week now, and it has attracted exactly one response, even that not very helpful. This is my first post on this forum anywhere, and I have to say I'm distinctly underwhelmed by the "very friendly" and "amazing" community who would "do their best to help" which is promised on the download page.
<IRONY>The poster is obviously "very friendly" and "amazing". We (the community) are not "underwhelmed" by the attitude of the poster. He has posted exactly one message (excluding the complaint) and is therefore "doing his best" even though he solved his problem some days ago. </IRONY>

Pzz
Posts: 1
Joined: Mon May 02, 2016 8:06 pm

Re: Uart problem

Mon May 02, 2016 8:11 pm

Yo, I had this issue,"Resource temporarily unavailable" is EAGAIN and indicates read came up dry. It gets raised when O_NDELAY or O_NONBLOCK is specified so your code can move on. Maybe adjust VMIN, VTIME, how long you wait for an answer, or check the responding side. In my case there was a terminating character mismatch.
hth

Return to “Troubleshooting”