Pi Serial1 device

Does anyone know if the Serial1 device on a pi is supposed to work?

I have Tanks piserial rom working but I’m testing DeviceFS serial devices and can’t get any output when sending to Serial1 on the pi.

I think we use Tank’s module exactly because the internal serial doesn’t work…

The odd thing is that the pi hal outputs to the serial port so someone has worked out how the pi serial port works.

I have a Pi serial port and I mean it was working with RISC OS (e.g. debug via terminal).

I hope I find the time to try at the evening. Should I try other things than terminal.

The odd thing is that the pi hal outputs to the serial port so someone has worked out how the pi serial port works.

Working out how the serial works is easy (it’s documented in the public TRM).

Finding someone to finish the HAL implementation is the hard part.

Despite the many threads on the subject, for some reason this task wasn’t on the port status page. It is now.

Ok so it’s not supposed to work. Sounds a easy way into the hal I may have a look at it.

I notice you are keeping an eye on keypress problems. I find that this seems to be more voltage critical with the latest fiq change. And one other oddity I wonder if anyone else has noticed. When you shut down and the pointer is put in the window with the restart button sometimes stopping the mouse doesn’t stop the pointer – it can be fun timing your click so that the pointer is over the reset button. I’ve only seen this in the restart window.

Colin, if you want the source to the PiSerial module, to see if it can be reused, please email me webmaster@tankstage.co.uk (its assembler BTW)

Are there drivers for the (a?) serial port of a Raspberry Pi 2?

I have an app and some specialised level shifting hardware that was working on a Pi and thought it would be straightforward to run it on a Pi 2. It simply freezes, requiring Alt-Break to recover it. So I started to research whether I have an up to date PiSerial module, but all I can find is something whose date is prior to the Pi 2’s existence. I’ve spent quite some time searching, but without success or even an unequivocal answer as to what I need.

The port in question is on some very low-numbered pins of the 40-pin header (8 and 10).

Let me ask some slightly different questions:

Has anyone managed to get the serial port of a Raspberry Pi 2, on pins 8 and 10 of the 40-pin header, to work?

If so, what did you use?

Is the question specific to the Pi model 2? I used something off ebay for the revision 0002 model B 256Mbyte – it came with a cable to connect to the header. Can’t remember whether I had bought it for the Beagleboard in the first instance.

It simply freezes, requiring Alt-Break to recover it.

Is handshaking enabled?

I know handshaking can cause devicefs serial devices to lock up the machine:

1) you send some data on the local machine
2) the remote machine tells you to stop sending
3) the remote machine disappears
4) local machine waits forever to flush its buffers.

You don’t even need step 2 if you are using handshake pins instead of xon/off as they will default to stopping you sending.

You may be seeing the same problem if tank’s driver flushes its buffers in non blocking mode.

Is the question specific to the Pi model 2?

Yes. The serial blockdriver and associated module, and my code, work on all the earlier RPi’s that I have tried.

Is handshaking enabled?

It is set to “none” by one of my initialisation steps.

I know handshaking can cause devicefs serial devices to lock up the machine

It isn’t via DeviceFS, it’s via the serial blockdriver.

It isn’t via DeviceFS, it’s via the serial blockdriver.

Yes I know but it would have the same problem if it flushes its write buffers in non blocking mode but as you have disabled handshaking in this case that won’t be the problem.

Do you see anything appear while the machine boots from cold?

I have a serial-in-a-USB-socket dongle attached to my Pi1, and when it is connected to the PC, I see a debug dump as RISC OS boots.
This is done by the beta kernel at a lower level than the blockdrivers (indeed before the OS has even initialised itself). If you don’t see that, I wonder if there is a problem with the serial connection?

Do you see anything appear while the machine boots from cold?

Yes. My oscilloscope tells me it’s at 115200 baud. (My custom hardware is also attached, although it won’t respond – it operates at 2400 baud.)

I should add one fundamental observation: with the PiSerial blockdriver and module, the UART Tx line just stays high. I trust this oscilloscope – if the line went low, I would see it. So nothing gets transmitted.

Has anyone got this RPi 2 UART to work from RISC OS? I can’t be the first to try, surely? From what I read above, Colin, you’ve tried without success.

I’m working through a disassembly of the PiSerial module (I now have a later one, from 2015 March) to see if I can find where the GPIO lines are set for UART0 operation. References elsewhere suggest that, since no data sheet for the BCM2836 is available, the BCM2835 one is sufficiently accurate. It’s a worrying leap of faith to have to take.

From what I read above, Colin, you’ve tried without success.

No I don’t have a pi 2. I did find that Tanks module only works on a pi b+ up to 115200bps – There’s no output after 115200 baud – I have usb devices working at 921600bps.

I was going to write a devicefs driver for the pi – I’ve written one for usb devices – but I discovered the problem with flushing transmits locking the machine in certain situations and have been trying to figure a way to avoid the problem before tackling a pi driver.

Maybe the pi2 doesn’t do 2400bps have you tried the block drivers at 115200bps to confirm it’s a driver problem – you know the pi2 should do 115200 bps as you can see that on booting.

Dave, the PiSerial module does not set the GPIO lines.
When the Pi boots, they are set up as UART.
If they have been changed by another program after boot, then you will need to set them up.
Also theres no need to work from a disassembly, if you want the source just email me.
The difference between The BCM2836 and the BCM2835 is just the processor.
All the I/O is the same, just at a different address.

I solved the problem last night by installing a later RISC OS image. The previous one was dated 2015 February, the replacement one was 2015-12-20.

For my curiosity (and that’s all, because the problem is solved), I would be interested to hear any ideas of why that solved it.

(I would have posted this last night, but the forum was giving a Rails error.)

Is it about time that the Pi’s RC14 SD card image was updated? It has RISC OS 5.21 (Feb 2015) and firmware from Feb 2015. Something similar was done to RC12 (RC12a was issued with updated firmware (only), neatly avoiding an ill-fated RC13) when the Pi Foundation updated firmware to cope with newer hardware.

The reason might be the GPIO Device not reporting the correct machine type, as the Pi2 uses a different method of reporting the version via the mailbox system.
If this happens, the PiSerial module might think its running on a Pi1 and try to access the wrong memory locations.