Archived Forum

Hi,

If you go go into /dev

cd /dev

Then see the full permissions of the serial port

ls -lah | grep ttyUSB

or

ls -lah | grep ttyACM

If you can send in the results of this, it may give us a pointer towards the solution.

Jimmy

Using a wildcard one liner is another method to get all 

ls -la /dev/tty*

or for just the serial devices

ls -la /dev/tty*[a-zA-Z]*[a-zA-Z0-9]

however the permissions were amoung the first thing I checked and appear the same 

eg Working Pi

pi@mediaPi ~ $ ls -la /dev/tty*[a-zA-Z]*[a-zA-Z0-9]
crw-rw---T 1 root dialout 204, 64 Mar 17 13:53 /dev/ttyAMA0
crw-rw---T 1 root dialout   5,  3 Jan  1  1970 /dev/ttyprintk
lrwxrwxrwx 1 root root         12 Feb 13 16:37 /dev/ttyS0 -> /dev/ttyAMA0

eg Non working Pi

pi@raspberrypi ~ $ ls -la /dev/tty*[a-zA-Z]*[a-zA-Z0-9]
crw-rw---T 1 root dialout 204, 64 Mar 17 15:17 /dev/ttyAMA0
crw-rw---T 1 root dialout   5,  3 Jan  1  1970 /dev/ttyprintk
crw-rw---T 1 root dialout 188,  0 Jan  1  1970 /dev/ttyUSB0

​also it doesn't seem to complain about permissions as linux usually does, in fact I have tried removing "pi" from dialout to confirm the warnings are still being given when permissions are an issue, and they do seem to be

Paul.

Hi,

I didn't realise it was you Paul (oops)

However as you say this has confirmed it is not a permissions thing.

I guess these ones that are not working have been upgraded from older versions of raspian, not a fresh install?

If so do you get the same results in minicom?

Also what about plugging in a USB to Serial device or arduino?

Jimmy

Hi Paul, 

Thanks for letting everyone know.

Just to clear things up, the emonPi update and emonPi first boot update do not do an sudo apt-get update or upgrade. It merely git pulls from all our repos. Please, could you edit your first post not to mislead?

The RasPi3 has indeed changed things with regard to the serial ports. By default UART0 (ttyAMA0) is connected the the BT. See my post for how to remap UART1 back to UART0 and why we need to do this:

https://openenergymonitor.org/emon/node/12311

Please, could you test this on a Pi2 with the changes I mention in my post above?

Update: just tested on a RasPi2 and full serial comms (including AVR upload) is working after adding

dtoverlay=pi3-disable-bt

to /boot/config.txt, then running:

sudo systemctl disable hciuart​

Hi Glyn

I am aware of the Pi 3 BT v UART issue, it's the reason mine's sat here not being used yet, I'm not really overly interested in the boost in power if it means "hacking" it to get the serial port working. I hope it gets fixed in future updates or if push comes to shove, I would drop the clock rate to retain BT and wifi, but I'm happy to wait for now.

With this issue, the serial port is reading fine so mapping probably isn't the issue unless it can affect writing without affecting the reading. For that possibility, (and pure desperate optimism AKA clutching at straws) I tried the dtoverlay anyway, on both wheezy and jessie, and on a model B+ and a 2 B too, (just 2 B sure) but no change on any of them. The wheezy machines didn't recognise the "systemctl" command and have no "hciuart" service to halt. {EDIT - BTW Yes I did reboot for the changes to be picked up}

Paul

PS - I have now deleted the "if using emonpi update" warning. I had already edited it after checking the code and only left the correction there as it is better to be safe than sorry.

Just for the record, the Kernel on the Feb emonSD image (before any updating) was 4.1.18 and after the updates, the kernel is at 4.1.19. However, serial issues are more likely to be part of RaspberryPi firmware. Did you run rpi-update?

My Pi2 is working fine with serial sending and receiving after the dtoverlay=pi3-disable-bt change. 

I don't think dtoverlay=pi3-disable-bt is too much of a hack as it's the official solution from the RaspberryPi team. I agree, we don't really need the extra power of the Pi3. However, on-board WiFi is nice. I have no use for BT, hence for most applications it's no big loss. From what I have read, dropping the clock and using UART1 to communicate with the RFM69Pi / emonPi still has issues since UART1 has less buffering and baud rate could still fluctuate due to undervoltage or overheating throttling.

You are probably wise letting the dust settle on the Pi3! It took me most of a day, a couple of days after the Pi3 was launched to find a fix for the UART issue. This is how long it took the Pi team to implement the 'fix'!  

After many hours of debugging, I found what I had believed to be a "known good" rfm69pi, used to debug what started out as an "avrdude" related issue, is actually faulty. It is blind to any activity on it's RX line.

I will report back if I find anything of use when I look at the rfm69pi, but for now I must put it aside and press on with the original task.

Thanks for the suggestions.

Paul