Pi 3 shutting down-ish

I have a Pi 3B with just the bootloader on a DOS formatted SD card with !Boot on a USB attached harddrive. HDMI output goes via a HDMI to DVI converter, through a KVM to the monitor. I usually download and install a new Beta RPi ROM and update from Nightly Beta HardDisc4 each weekend.

With ROMS from 3, 10 and 17 Feb the Pi sort of shuts down. It doesn’t happen while any particular program is running, or after any set time interval.

What I’ve found so far on separate occasions is:
power light remains on
keyboard caps lock light changes as expected,
blind typing F12 then Ctrl G gives the system beep
audio file playing using !DigitalCD, sound stopped and no beep after F12 Ctrl G
Ctrl/shift F12 return to try restart, still no sign of life
using the KVM to select a pc, displays OK. Changing back still nothing on the Pi
power off then restarting, starts up OK

Simply replacing riscos/img on the SD card with one dated 15 Jan works without the problem. I don’t recall having a problem with 27 Jan ROM, but I’ve not checked recently.

Is it me, my setup, the ROMs or something else?

Any advice or suggestions most welcome.

Maybe it’s the KVM.
After switching back to RISC OS sometimes the mouse and keybord are not recognised anymore.
Even plug out/in has no effekt in this situation. So only reset helps.

Something like this has been happening here for a few weeks now. The RPi3 is usually run headless but it is also plugged into the monitor.

When it fails there are no error messages.

On one recent instance the RPi3 was displayed on both the monitor and VNC on the Mac. The monitor screen went black but the RPi3 was functional via VNC for about half a minute before that seized up too and the RPi3 shares disappeared.

Up to date beta ROMs are used.

Other than a “me too” I don’t have anything useful to add at the moment.

The firmware has been updated, if that does not help the spare card which is a few months old can be tried.

Possibly this is a problem caused by the gamma correction support which went in on the 2nd (and should have shown up in ROMs on the 3rd – BCMVideo 0.49). I’ll start having a play around tonight and see if I can reproduce it.

I’ve had something similar (the same?) where the screen unexpectedly enters sleep mode and no amount of clicking the mouse or tapping the keyboard brings it back to life, short of Ctrl-Break. My ROM is from 12 Feb. I’ve rolled back to 23 Oct as that was the version I was using previously.

I’m glad that someone else is having the same problem (my machine isn’t dying!) and that there’s a narrower date range between it working and failing.

I’m glad that someone else is having the same problem (my machine isn’t dying!)

I was beginning to think my RPi3 was dying so reverted to an RPi2.

In parallel with the above thought I am also beginning to think it may be an RPi3 thing, I have yet to see the spurious shut down on either the RPi2 or RPi1 (yet??).

The RPi3 is now running the ROM from 27Jan18.

Meanwhile, my Pi 3 has been happily running for 3 days straight (mostly unattended) using latest-ish code.

• Does the failure occur if the machine is sat idle, or only when in use? (program running which taxes the CPU? human interaction via keyboard/mouse? network activity?)
• Are there any unusual settings on config.txt?
• Any specific software running?

Does the failure occur if the machine is sat idle, or only when in use?

The failure occurs when the machine is idle.

Are there any unusual settings on config.txt?

This is my config/txt. The Pi had been used ar 2560×1440 but that results in a ‘jerky’ pointer towards the right hand edge of the window when viewed over VNC, at any size screen mode, which is why those lines are commented out. The point is the GPU has been working harder in the past.

## start 2560 x 1440
#hdmi_cvt=2560 1440 60 5
#hdmi_group=2
#hdmi_mode=87
#hdmi_ignore_edid 0xa5000080
#max_framebuffer_width=2560
#max_framebuffer_height=1440
#hdmi_pixel_freq_limit=400000000
##end
gpu_mem=128
hdmi_drive=2
hdmi_blanking=1
disable_overscan=1
fake_vsync_isr=1
# gpu_mem=64
init_emmc_clock=100000000
kernel=RISCOS.IMG
framebuffer_swap=0
ramfsfile=CMOS
ramfsaddr=0x508000

This is the firmware.

bootcode.bin  28Jul17
fixup.dat     01Dec17
start.elf     01Dec17

Currently the RPi3 is running the ROM from 27Jan18, BCMVideo 0.49, without issue, (yet??).

To be fair it remains unclear to me what the issue really is, defective Pi, overheating or a ROM issue.

Something a bit weird has happened. The RPi3 with ROM 27Jan18 was having its CPU hammered with a huge BASIC FOR NEXT loop running in a TaskWindow. The screen blanked but did reappear after a few mouse clicks but all the running tasks had gone, it was as if the machine had rebooted. CPU temperature was 70C at the failure point.

Are there any unusual settings on config.txt?

Mine’s fairly standard but like David I have hdmi_blanking=1 in there.

fake_vsync_isr=1
framebuffer_swap=0
gpu_mem=64
init_emmc_clock=100000000
ramfsfile=CMOS
ramfsaddr=0x508000
kernel=RISCOS.IMG
max_usb_current=1
hdmi_blanking=1
scaling_kernel=8

Hey, David. Funny you should post that. Overnight I was considering the issue I’ve been having with my Pi3 in RO which kind of forces me to use the Pi Zero.
My Pi3 very quickly hits 70*C and throttling kicks in. Even then the temperature still wobbles about a bit above that. I’m glad CPUClock has my back.
My Pi 0 running the same SD card (this), and with no heatsink sits around 50*C

*fx0

RISC OS 5.23 (30 Jan 2018)

My Pi3 very quickly hits 70*C

My RPi3 ran a bit cooler than that, the maximum was 65°C.

I have taken it out of its official case and it is running about 5°C cooler.

In my case the failures have occurred whilst being in use. I can’t recall specifically what was in use at the time except on one occasion I was playing an audio file with !DigitalCD with the screen already blanked due to keyboard, etc inactivity.

My config.txt file is fairly basic;

hdmi_blanking=1
fake_vsync_isr=1
framebuffer_swap=0
gpu_mem=64
init_emmc_clock=100000000
ramfsfile=CMOS
ramfsaddr=0×508000
kernel=RISCOS.IMG

With firmware;

bootcode.bin 28 Jul 2017
fixup.dat 11 Jan 18
start.elf 11 Jan 18

The only module I have unplugged is BootFX.

For the last 3 day I have been running with the ROM dated 27 Jan with no problems.

I updated with HardDisc4 (on the USB attached harddrive) and installed riscos.img (both dated 23 Feb) about 8 hours ago. The Pi has been running OK since then, mostly idle with a CPU temp of late 50’s. Over the last couple of hours I have been using a number of applications with the temperature creeping up to the late 60’s.

I’ll not get much chance to run the Pi until this evening, but will try to note more details of any failure.

Have any of you got heatsinks on your Pi3’s? The Pi3 idle temp has always been high, it’s been mentioned several times over the past year, including by myself when I queried if the OS was actually halting the CPU when idle.

Left at the command prompt, mine used to hit around 60 with no software running and would invariably misbehave. I’ve since fitted a copper heat sink which has cured most, if not all of the heat related issues.

Has anyone tried turning the screen saver off to rule it out?

Have any of you got heatsinks on your Pi3’s?

I haven’t. My RPi3 had been just fine up to a few weeks ago. It has now been taken out of its case which reduced the temperatures by about 5°C. It hasn’t fallen over since.

(The RPi2 did switch itself off overnight, presumably it did this to just add to the confusion.)

it’s been mentioned several times over the past year, including by myself when I queried if the OS was actually halting the CPU when idle.

Thank for the pointer.

Has anyone tried turning the screen saver off to rule it out?

I have done that now on both the RPI3 and RPi2 and commented out the hdmi_blanking=1 lines.

Added The screen saver used was DPMS. A quick check shows that a graphical screen saver can use a lot of, warming, CPU.

Yes. My Pi3 has heatsinks. Just idling without screensaver the temp goes up pretty quickly. Just the Pi3 though.

Just idling without screensaver the temp goes up pretty quickly. Just the Pi3 though.

Yes, it does seem to be affect the Pi3 more than earlier modules. It will also affect the revised Pi2, which uses the same SoC.

Question is…is the issue SoC design related or is RISCOS simply not halting the CPU enough and/or halting it correctly?

With using RISC OS, the Pi3 gets hot, even when idle ( no screen- saver) around 60°C.
If using Raspian instead, it stays below 53°C, even when heavy using cpu (surfing the web – watching youtube videos on fullscreen.
Looks as if RISC OS is using more cores as linux?!

Have any of you got heatsinks on your Pi3’s?

Yes. I found temps averaging 60-65deg, rising to over 70deg under heavy use (this with the Pi3 in an open VESA mount as opposed to a closed case). Fitting a heatsink to the CPU/Memory chip reduces average operating temps by 4deg or so, but more importantly, appears to disproportionally reduce the higher temp ranges, which haven’t approached 70deg since. Definitely a recommended upgrade.

Looks as if RISC OS is using more cores as linux?!

I think RISC OS only uses the one core, and I suspect that running one core regularly up to 100% creates more of a ‘hot-spot’ than running 4 cores at typically much lower percentages – just speculation on my part, I have no evidence either way.

No heatsink here, although the ambient temperature has been relatively cool for the past week or so. The issue usually occurs when the machine is idle, but I’ve had it happen while in use too. I don’t use the machine for music so I can’t say whether or not it keeps playing.

I have the DPMS screensaver enabled. I haven’t actually done any further testing as I’ve rolled back to an earlier ROM.

I’ve managed to get one crash so far with hdmi_blanking=1 (sat idle with the screen blanked), but no more since then. Grr!

FWIW my Pi 3 idles at around 50 degrees (caseless).

My Pi3 has been running with ROM dated 22 Feb 2018 with no problems since Sunday evening. At times it was idle with and without the screen blanked by the DPMS settings, and at other times running quite hard transferring hundreds of files across my network causing the CPU to throttle back to 600 MHz when reaching 70°C as per my settings on !CPUClock. I used !Sunfish and !Omni at various times to transfer the files. Also I had used !NetSurf to browse and download, and !NetFetch and !Messenger for e-mail.

A short while ago it failed. I had been accusing a SD card via USB and using ’count’ from the Filer to count the number of files both on the card and on my USB attached harddrive with about 5 windows and their count result windows open. There wasn’t any system activity nor was I using the mouse or keyboard when the screen shut down – too soon to be caused by the screen saver kicking in. The Caps Lock key was responsive, no response to Ctrl-Shift F12, however Ctrl Break did cause the Pi to restart normally. The CPU temperature on reboot was 60°C.

The Pi has heatsinks attached and in a ’offical’ case. I think I’ll trying running without the hdmi_blanking=1 setting to see if that makes any difference.

I don’t know if this information will help to pin down this annoying ’feature’. Thanks for everyone’s input to this, at least it’s some relief to know it’s not just me.

Nope, made no difference.

Most the time since my previous post the Pi had been idle with the screen blanked by DPMS. I had just brought the screen awake, opened up a couple of directory windows on my NAS via !Sunfish, and while moving the mouse pointer acros the screen it blanked with the lack of response as previously described.

I’ve put hdmi_blanking back on.

I have had a further instance of this crash, an apparently dead Pi but recoverable with Ctrl-Break. One small difference, it was an RPi2.

Has anyone managed to narrow it down to a specific build date? Appreciate that’s going to be a royal pain if the crash is so infrequent. Must have been prior to 3rd Feb, mentioned in the OP and after 27th Jan mentioned in a later post.