Pi Support for RTC module broken

I can confirm other reports we have had, that last night’s and the 5th December’s Pi Build are no longer reading the battery backed RTC module for its time.

Time is being set to the time of the last shutdown.

You mean the build of 16 December? I don’t get it to work. It doesn’t start at all. The power led goes on and some signal is send to the monitor (it doesn’t go to standby) but nothing happens anymore. The build of 2 December works. Tried the newest firmware (works ok with the 2 Dec build) but that doesn’t solve the problem. Perhaps there is something wrong with CONFIG/TXT. It contains:

fake_vsync_isr=1
gpu_mem=64
init_emmc_clock=100000000
kernel=RISCOS.IMG

The 16th December build works OK for me. I can’t see anything wrong with your config.txt either, and nothing’s changed recently which would require you to make any changes.

I think the RTC module is a casualty of Sprow’s RTC handling changes – I/he should be able to easily fix it by adding an RTC HAL device to the HAL (previously the RTC was being handled by the code in the kernel, but that kernel code is gone now).

Got it somehow booted. I think there is a problem in the monitor detection (is that implemented already?) I tried booting it without anything connected and I noticed that the activity led flashes sometimes before it stops. This is not the case when my monitor Philips 150B4 is connected via a HDMI2DVI cable then only the power goes on and nothing happens anymore. So I added the line hdmi_force_hotplug=1 to the config file and started it up without the HDMI cable connected. Now RISC OS boot without problems. After booting I connected the monitor again and I get the desktop. Only it doesn’t display properly. There are black borders around the screen and when I select my default modes like 640×480, 800×600, 1024×768 the screen is somehow squashed (width is smaller than the height). I rebooted, but then it stalls again. It doesn’t matter if the monitor is or isn’t connected. The only way to get it going is by using a fresh rom (with original CMOS) and disconnecting the monitor before switching it on.

Did some more testing. I really think it has something to do with reading out the monitor details via HDMI and then configuring some setting which locks the system up. As I already mentioned I could only use a fresh ROM (no new CMOS settings has been saved yet) copy to get the system booting without the monitor connected. When adding the line hdmi_ignore_edid=0xa5000080 to the config file it boots (also after the CMOS has been modified) without the monitor attached. The only problem now that connecting the HDMI2DVI cable I only get a black picture on the monitor and then it’s not even possible to bring up the monitor menu. The monitor also doesn’t complain that the input is out of range or doesn’t go to standby (so there is a signal).

Does anybody know what I could do next to find out what’s really going wrong? The ROM-image of 2 Dec hasn’t got them.

Chris: The RTC module should hopefully be working again with today’s ROM. I don’t have an RTC module myself to test with, but it looks like a simple copy and paste of the relevant code from the Iyonix HAL should have been all that’s needed to get it working.

Dick: I’m not sure what could be causing your problems. There have been a few changes to the video driver recently but nothing which I’d expect to have an effect like that. Has your Pi had trouble with your monitor in the past? My Pi has always had trouble with my monitor, so I use the following settings to boost the signal, force it to 1080p (it seems to default to 1080i) and force it to use the headphone socket for sound instead of HDMI:

kernel=riscos.img
hdmi_drive=1
hdmi_group=1
hdmi_mode=16
disable_overscan=1
hdmi_force_hotplug=1
config_hdmi_boost=6
fake_vsync_isr=1

Perhaps try using the config_hdmi_boost setting before playing with anything else, as that made the biggest difference for me (without it I don’t think I get an image at all). There’s a full list of video options and their explanations here

Thanks Jeffrey. I tried last nights build and it didn’t work, though as it wasn’t submitted until after 2a.m. this morning I suspect it missed last nights build. We’ll test again tomorrow. Don’t you ever sleep? I do hope you take a break over Christmas and have some fun:-)
n.b. ROOL do have one of our clock modules or I could send you one if necessary.

The code is in today’s ROM – I downloaded it and could see the device name in the disassembly. Does the “RTC” module show up in the output of *modules? If not then it suggests the code in the HAL which tries to detect the RTC isn’t working properly.

Unfortunately I’m about to go off on holiday over Christmas, so I’m probably not the best person to be looking at this!

A small mistake in your post…

Unfortunately I’m about to go off on holiday over Christmas, so I’m probably not the best person to be looking at this!

You mean fortunately? :)

Yes
Utility module is 19.12.2013
RTC Module is module 53 RTC 0.01 18.11.2013

n.b. The Iyonix software detected it when we connected it to an Iyonix. When we made our prototype the Pi had no support so we removed an Iyonix’s ds1307 and wired in our module via the backplane and it worked.

Hooray! I got the new ROM working on my display. I tried the hdmi_safe=1 option and that worked. So I replaced it with the corresponding commands and remarked them one by one and found out that the overscan causes the problem. When I disable the overscan or set overscan_left/ _right/ _top/ _bottom all to 0 it doesn’t work. A value of 1 or greater works. I tried setting some values to zero while the others are set to 1. When I either set the left or top to 0 the system boots but if I set right or bottom to 0 I get a picture but the system stalls when SoundDMA has been initialised. I hope this info gives an idea what could cause my screen problems with the latest ROMS.

Chris: Maybe try the following bit of BASIC to see if there are any errors being returned by the RTC module:

ON ERROR PRINT REPORT$;" at ";ERL : END
DIM B% 8
SYS "RTC_Read",B%
PRINT ~(B%!4);" ";~(B%!0)
B%!0=&18400000
B%!4=&20131219
SYS "RTC_Write",B%
B%!0=0
B%!4=0
SYS "RTC_Read",B%
PRINT ~(B%!4);" ";~(B%!0)
SYS "OS_ResyncTime"
*time

That will:

• read the time from the RTC and print it out (first number is year, month, day. Second number is hours, minutes, seconds, centiseconds)
• set the time to something sensible (18:40 today)
• read back and print it out again
• issue OS_ResyncTime to get the OS to synchronise its soft copy to the RTC and then use *time to check what time the OS thinks it is

Jeffrey wrote:

Has your Pi had trouble with your monitor in the past?

No never. It always worked fine with the release candidates (RC8-RC11) default settings.

Thanks Jeffrey. I’ll try that in the morning.
If anyone else has their Pi to hand tonight to try the test please do and post results here please.

Using 20131219 build, the Pi was shutdown at 09:28 this morning, and then rebooted at 09:50.

Alarm & reading the time directly from the RTC via I2C shows that the clock has been set to 09:28 again.

Running your code gives the following:

>CH.“SCSI::4.$.selection”
20131220 9302300
20131219 18400000
Thu,19 Dec 2013.18:40:00

So, it would appear that the RTC can be read/written to by the OS, but on start up the OS takes the timestamp of RISCOS.IMG in preference to the time in the RTC, and sets the time to that, overwriting the correct time on the RTC in the process.

I suspect the problem may be outside of the RTC module?

We know that the RTC hardware is working correctly and is keeping the correct time over a shutdown when using earlier versions of the OS.

Enjoy your holiday Jeffrey, you’ve certainly deserve it.

Enjoy your holiday Jeffrey

I’ve no idea whether you’re doing any winter sports… but if so, then advice I can offer thanks to (very painful) first hand experience 11 years ago is to take it easy on the last day, when tiredness sets in!

I have the same issue as Dick, though I’m using an Attrix Lapdock. (Model B Pi. 512MB) I get no picture with a recent ROM.
Adding the line hdmi_safe=1 to the config.txt file results in a small display in the middle of the screen that is barely readable :(

Hi Rob. That’s because hdmi_safe contains the commando’s overscan_left/ _right/ _top/ _bottom=24 which could produce large borders. Try the next commands instead of hdmi_safe=1:

disable_overscan=0
overscan_left=1
overscan_right=1
overscan_top=1
overscan_bottom=1

If that doesn’t work then change the overscan_* settings to 24 and lower them until it goes wrong.

Thanks Dick! Using those options worked first time!

I can confirm that last nights build with Sprow’s changes to SDCMOS has fixed the problem of the RTC module not being read!

I’ve been following this and other RTC-related threads, as I’m trying to see if I can get the RTC on the X100 expansion board for the RPi to work (uses a different chip: NXP PCF2127AT / PCF2129AT, but still connected to I2C).

There doesn’t seem to be an RTC module (i.e., not even dormant / unplugged) on my machine – I’m running 5.21 (25 Feb 2014).

Any clues?

Mike

OK, have just upgraded ROM to latest nightly (3 Jun 2014), and RTC module is there (dormant) – it didn’t exist in my earlier ROM.