Unable to write to RTC control registers (MCF52259)

[darrellhoblack]

Description: We are developed a PCB Controller board using theMCF52259. We have been successful at configuring the system clock based on an external crystal, controlling LEDs and reading dip swiches using GPIO, using Pit timers and using the UARTs for communication.

We are currently developing using USBDM and the Codesourcery Lite tool chain in conjunction with Eclipse/CDT Kepler. We are coding in C99.

We are attempting to use the RTC in the MCF52259 and econuntering difficulties. When we attempt to read back the RTC registers (and the RTC control register in the clock module) after configuring them, the values read do not reflect the values written into them. The values seem to be the reset values of the registers and not the values written into them.

We have tried checking the PPMR to insure that the RTC module is enabled. When we read PPMRL we get a value of 0x4000 0004, for PPMRH we get a value of 0x0000 8064. According to the reference manual, it should be impossible to obtain these values.

The minimal test code that we are using to try to bring up the RTC is attached. We have also tried many variations of this attempting to follow the reference manual.

We are confused about the dummy RTC reads referred to the in the Reference Manual.

The attached is a ZIPed file named RTC_test.zip.

Original Attachment has been moved to: RTC_test.zip

[darrellhoblack]

In our test, we are not trying to maintain the RTC clock when power is down.  The test is to see if the RTC registers can be initilized. We will use the external crystal to clock the RTC in our final design.  The internal oscillator was used in our test because the Tower used the internal oscillator.

Ref. https://community.freescale.com/message/51895#51895

From the above thread, Vstby must be between 3 and 3.5 volts at start up in order to initialize the RTC registers.  Vstby can go as low as 1.8 volts to backup the RTC and the first 16k of the SRAM.

This means that you must power up the MCF52229 with Vstby  between 3.0 and 3.5 volts but can let it drop to 1.8 volts to backup the RTC and the first 16K of the SRAM.  If the battery is maintained above 1.8 volts, the RTC registers will be maintained and when power is restored, the RTC will operate normaly.  A problem will be encountered if the battery is not replaced or charged to greater than 3.0 volts, the RTC registers can not be initialize!

We will verify the above conclusion.

The manual is not clear why the RTC registers can not be initialize when power is turned on if  Vstby is less than 3.0 volts.  The manual implies that if Vstby is between 1.8 and 3.5 volts that the RTC system will maintain the time.

If the manual is incorrect, unclear or misleading, it is Freescales responsibility to inform it's users of this fact!

[TomE]

That previous thread you found gives the best details anywhere on how the RTC seems to work.

> If the manual is incorrect, unclear or misleading, it is Freescales responsibility to inform it's users of this fact!

It has been over 6 years (March 2009) since that was shown to be the case in that thread. That thread also documented out that the battery only backed up the first 16k of the SRAM, and in Rev 3 of the manual (May 2010) that was corrected. There were no other RTC-related fixes in Rev 3 or Rev 4 (March 2011), and nothing since then.

I suggest you contact your Rep with a list of detailed questions on this. I've had success doing that with other problems. If you do get clarification, please post it back here.

> We used the circuit from the Badge Board.

Is that this one with the rechargeable 3.7V LIR2430 battery? How are you generating VSTBY from that? If you're using a 3V button cell, are you using the FET to disconnect it when 3V3 is present? What voltage were you supplying on VSTBY, and have you found a voltage or connection that lets you program it now?

http://cache.freescale.com/files/32bit/doc/user_guide/JMBADGEUM.pdf

The Data Sheet says that ISTBY is 5uA in "Normal operation: VDD > VSTBY - 0.3 V", which means that VSTBY has to be less than 3V for the CPU to stop drawing current from it. But it seems it has to be more than 3V in order to work. Also, Mark Butcher's tests in the previous thread indicate that VSTBY is used to power the SRAM and RTC even when VDD is being supplied, and it only seems to switch over when VSTBY drops to 2V or less.

I don't think you've got enough information to design from yet.

Tom

[TomE]

Not surprising. You should SEARCH this forum for all the other people having trouble all the way back to 2008. Search for "MCF_RTC_HOURMIN" to get hits on programming problems.

Here's one I prepared earlier (participated in two years ago):

https://community.freescale.com/message/315477#315477

The register definitions in some header files are wrong. You need to fix them (wrongly set as 16 bit accesses, but only 32-bit ones work).

There's working sample code in the above link, but this Forum software has destroyed the formatting and put all the code into one line. You'll have to cut/paste it out and put the line breaks back.

The three lines of sample code in the Manual (copied into multiple version of all the MCF52210, 52211, 52223, 52235 and 52259 manuals) has way more bugs than lines of code. It is so bad it "isn't even wrong". It will continue to cause problems as it doesn't seem it will ever be fixed with new manuals or even errata.

Tom

[darrellhoblack]

Tom, thank you for responding.

We should have mentioned having searched the forum for "RTC" and "MCF52259" and have read threads here including the one you linked. So we have checked the header file and it does contain the macro definition as referencing a 32 bit value. We've also checked the disassembly in the debugger for a movel instruction to confirm 32 bit accesses to those registers. 

I'm not on site today to triple check that now, or I would, as I am frustrated enough with this to be making mistakes and doubting myself.

I've also included in my test code reads of the registers to local variables to enable checking their value in the debugger (to force the right access size).

In trying to figure out where else we might have gone astray, we noticed that the RTC can be disabled using peripheral power management, which is why I was looking at those non-RTC registers. Everything, including the RTC, should be enabled out of reset (all bits 0 per the reference manual). Somehow, I'm reading bits set in them which, as far as I can tell from the manual, should always read as 0.

[TomE]

> I'm reading bits set in them which, as far as I can tell from the manual, should always read as 0.

The first thing you have to do is to try and work out which parts of the manual to believe. Lots of bits are wrong, and stay wrong for years (like that "sample code").

Lots of "reserved bits" and "default state of register" were true in a different CPU but sometimes they change in the silicon without getting changed in the manual.

Chapters aren't written from scratch, but are "documentation modules" that travel around (and get re-used) as the silicon they document is re-used. It often helps to do a few days of "archaeology" to see the history of the chips the module has been used in. I've managed to go back a decade or more and find the original manual that explained things better and allowed me to see where problems crept in. Search this forum for "Bear PIT" for an example of this.

https://community.freescale.com/message/79538#79538

That's why you don't find the "power down" and "clock enable" bits mentioned in the chapter for a module as the hardware that does that function isn't in that module.

Are you sure the RTC is getting clocked? Can you run it on a different clock source and see if it works better?

Tom

[darrellhoblack]

Latest Iteration,

We have implemented all your recommendation,still not able to write to RTC registers.

We have taken RTC test code which ran on the Tower and moved it over to our test board. Still not able to write to RTC register.!

Our test board is using the 8Meg internal oscillator. We used the PIT to verify the system clock.

We are using the 8meg system clock to clock the RTC clock.

Our system requires that the RTC keep running when system power is removed, so we have connected Vstb to a 3.3 volt battery.  We used the circuit from the Badge Board.

We suspect that the RTC system is disabled!

We suspect that the relative voltage levels of Vstb and Vdd are somehow putting the RTC into a standby mode.

Our Vdd is 3.3 volts and Vstby 2.97 volts.  From the mcf52259 specs, Vstb needs to be between 1.8 to 3.5 volts. Vdd is greater that Vstb -0.3 volts for normal operation.  The tower has Vstb connected to Vdd. We connected Vstb to 3.3 volts, and are still not able to write to the RTC registers.

There was a thread that we read which may have had a similar problem with Battery vs Powered operation, but there was no resolution to the thread.

Any other suggestion to try?

[darrellhoblack]

We have addressed and eliminated all of your points except for HW differences between the Tower and Test Board.

To eliminate everything but the hardware, we have added the 26 pin BDM header to the tower so that we can use the same tool chain on both. Same test code runs on the Tower but not on our board.

This brings us down to our HW relative to Vstby. The tower connects Vstby to Vdd and our board has a circuit like the Battery back up circuit in the "Badge Board" Freescale sample design.  Vstby is 2.9 volts. 

In conclusion, If Vstby is connected to Vdd, and Power is turned off then on, the clock will initialize.  We have a reset button connected to RSTIN_b and we can press the button and the RTC will initialize and function normally.

If Vstby is connected to our battery backup source (2.9 volts), and Power is turned off then on, the clock will not initialize.

Your advice?

[TomE]

> Your advice?

Use an external RTC. I2C or SPI. Something like a Maxim DS1308 or any of the other 82 available parts from them.

That was my advice to this user, which you may have already read:

Re: MCF52259 RTC problems

> The tower connects Vstby to Vdd

It is always risky to use a chip in a different way to the Development Board. See if you can find any Development Boards for this chip series that do have a battery on RTC.

Otherwise, lets check the Manuals before I make a guess as to what your problem might be. I've never used these chips so all my advice is from the manuals. Anyone else who does use these chips is always welcome to contribute...

MCF52259 Data Sheet Rev 3:

"RTC module with 32 kHz crystal".
"Vstby keeps the RTC running..."

"RAM standby supply current"

"SRAM ... with standby power supply support for the first 16 Kbytes"

No mention of the RTC standby current. You'd think that would be really important. The RTC crystal oscillator has to have a power consumption if it is enabled, but that's not listed either. It looks like VSTBY is only meant (or tested and documented) to keep 16k or RAM alive.

The documented SRAM consumption is 20uA. The RTC and XTAL current are undocumented, but may double that or more. If we assume 50uA then that would flatten a 90mAH CR2016 in 75 DAYS and a 250mAH CR2032 in 29 WEEKS. At 20uA it is only 74 weeks for a CR2032.

MCF52259DE Errata: Nothing interesting.

MCF52259RM Reference Manual 4 and Addendum:

7.3 Modes of Operation

7.3.2 RTC Mode

A dedicated RTC oscillator can be selected to run the RTC circuitry.

In normal operation, this oscillator is powered by the VDDPLL and VSSPLL

pins. When the part is shut down, this oscillator is powered by the

VSTBY pin.

> Our test board is using the 8Meg internal oscillator.

> We are using the 8meg system clock to clock the RTC clock

"There's your Problem".

The internal oscillator won't be powered by VSTBY. So the RTC is running "unclocked" with the power off, so it is impossible for it to keep time. If you just want to store the time when the power went off, then just save that to SRAM.

That may explain why it won't come out of reset either. It is possible that the RTC registers can't even be written if it isn't clocked, and once you shut its clock off (by powering it off) there may be no way back. You may not even be able to write the bit in RTTCR to switch it to a working clock.

You probably need an external crystal on the RTC_EXTAL pins. If you can't afford that (and don't seem to need the accuracy) you might be able to use a resonator or an R/C oscillator.

Why are you using the internal oscillator to run the RTC? That can't keep "real time". It has to be trimmed against an external reference to get it close to 8MHz, and will probably then drift with temperature and voltage. The Data Sheet gives the frequency as being between 7.84 and 8.16 MHz, or 2%. That's 28 minutes PER DAY. It doesn't give any details about how to trim this clock apart from "7.7.1.3 Relaxation Oscillator Control Register (ROCR)". It has 10 bits trimming the frequency between 0.8% and 40%, but I can't see how 0.8% is 1/1024 of 40%. If the best you can trim it is 0.8%, then that's still 12 MINUTES per day!

Good luck finding what "flash information row (bits [9:0])" are as well (where the trim is stored). There have been a few forum posts on this subject - search for "ROCR".

There are no details on temperature or voltage sensitivity of the oscillator. There  don't seem to be any App Notes on using the internal oscillator either.

Tom

[TomE]

I think I've found a reason why the manual doesn't have all the expected details (RTC standby current). I've been looking at "related" chips, specifically the MCF52223.

This one has SRAM powered by VSTBY, and the same RTC, but there's a notable difference. Instead of an RTCCR (Real-Time Clock Control Register) there's an RTCDR (Real Time Clock Divide Register) and no capability to select the second crystal. The second crystal pins (RTC_EXTAL and RTC_XTAL) are clearly shown in "Figure 5-1. Clock Module Block Diagram", but if they do exist, aren't connected to any package pins, either in the Reference Manual or Data Sheet. So we can assume "Figure 5-1" was pasted in from the manual for a chip that did have the external pins, like the MCF52259, and has survived four revisions of the manual without being spotted.

It isn't backed up by the battery either, although the SRAM is:

https://community.freescale.com/message/14908#14908

Here's an interesting comment on this chip, and by possible implication the other members of the family:

https://community.freescale.com/message/17654#17654

The explanation at the freescale seminar was that Ethernet based

applications are not target at lower power and this feature is therefore not a goal.

The Reference Manual does say:

Featuring ...the family has been designed for general-purpose

industrial control applications.

Tom

[TomE]

> Any other suggestion to try?

What is different between the working Tower and your non-working Test Board?

Are you running the same (or very similar) Initialisation Code? Is there any "bootstrap" running on the Tower that may be setting up hardware that your code isn't doing on your board?

I suspect the Tower is running on a Crystal where it seems your board is using the internal 8MHz oscillator. Is that correct?

Are you testing your code "standalone" or are you trying to use the debugger? There are various posts on these forums listing problems running the debugger on slow or internal clocks. The only obvious restriction with this chip is:

DSCLK: Maximum frequency is PSTCLK/5.

Which in your case is 8MHz/5.

Can you control the Debugger SDCLK frequency? Is it low enough?

Are you driving all the required Power Pins, or have you floated or grounded any "unused" ones? The RTC Power Pins are documented in "Table 2-19. Mini-FlexBus Signals".

> We are using the 8meg system clock to clock the RTC clock.

"Figure 7-1. Clock Module Block Diagram" implies the ONLY clock source for the RTC is the 32kHz crystal on the RTC_EXTAL pins. Not illustrated anywhere it then says that RTCCR[RTCSEL] allows the system clock to be used. You are setting this, but:

crValue = MCF_CLOCK_RTCCR;

    if ( crValue == 0x57  )

return;    // already configured

So if it is configured to use the EXTERNAL RTC CRYSTAL it will return?

    //MCF_RTC_RTCCTL = 0x80;

    //cr32Value = MCF_RTC_RTCCTL;

I'd try configuring it when DISABLED, and then ENABLE it, and in case that stops the registers from being written, try enabling it first (like you're doing).

    MCF_CLOCK_RTCCR = 0x56; // enable rtc crystal

That line enables the crystal, but selects the system clock. I'd try disabling the external crystal in case there's some weird "is the crystal running" hardware in there. Can you add an external crystal and see if it makes a difference? Can you try running with the external crystal (or oscillator) and see if it works that way?

    crValue = MCF_CLOCK_RTCCR;

    MCF_RTC_RTCGOCU = 0x1e; //set frequency

    MCF_RTC_RTCGOCL = 0x8480; //set frequency

All the registers have diagrams showing that they're 32-bit, but they only have 16 valid bits, so this is a "16 bit peripheral" probably lifted from an earlier 16-bit CPU design. The "RTCGOC" register is 32 bits, but is split into two 16-bit separate registers, indicating its 16-bit parentage. HOWEVER, all the registers are on 32-bit boundaries except for the RTCGOC registers which are illustrated as 16-bits, but are on 32-bit boundary addresses. If you wrote to them with 16-bit cycles it would write to the "upper" 16 bits, which may or may not be where the bits are (or may not work at all).

Tom