Description
Recently the RISC OS video driver has enabled the gamma unit. There doesn't appear to be a mailbox message to do this, so instead we program the 3*256 tables in (using auto-increment, by setting b31 of the respective DISPCTRLx register) then setting b29 of the respective DISPBKGNDx register to enable.
The gamma correction itself operates as expected.
However, after ~4h (sometimes longer, but always less than 12h) the screen blanks as though the pixel clock has stopped - ie. the monitor reports no signal, as opposed to the image being black.
Of 9 recorded reports all have been on a Pi 3B or 3B+, other models seem unaffected, though that could just be skew because new purchases of Pi 3's need to get the newer OS to run on it.
Having found issue #407 it sounded like the GPU may have run out of memory bandwidth, but (via VNC) we find the OS is still running and:
*vcgencmd get_hvs_asserts
hvs_asserts=0
*vcgencmd dispmanx_list
display:2 format:RGBX32 transform:0 layer:-127 src:0,0,1280,1024 dst:0,0,1280,1024 cost:801 lbm:0
display:2 format:ARGB8888 transform:0 layer:2000 src:0,0,32,32 dst:516,499,32,32 cost:107 lbm:0
which seem comparatively low cost values compared with that issue, and no asserts.
The whole Pi is drawing ~600mA consistently during normal operation and after the video cuts out, from a TTi bench power supply. The chip package temperature is ~60C (40C above ambient) from a thermocouple. Heating the package with a hot air gun to ~100C (80C above ambient) didn't trigger the problem when applied for 5 minutes constantly.
The ARM can be idling or busy.
When the problem occurs it is still possible to read values via the mailbox interface.
Removing the setting of b29 of DISPBKGNDx allows good video output for several days (ie. all the other code is still active, still using autoincrement to write 3*256 table entries). It's the action of enabling then waiting a few hours...then no video signal.
Activity