Electronic – Using the ST-LINK Utility to configure the RTC to current time

rtcstm32

What I was doing

I am using a STM32 microcontroller and for my project I need to be able to send data at specific times of the day (say, at 11am and 2pm). The microcontroller needs to know what time it is before I can achieve this. Unfortunately, I only have an one-way communication, and I therefore cannot request the current time from the network.

Therefore I want to set the current time, directly after I am done programming. I knew I am able to write data to the flash using the ST-LINK Utility Command Line Interface (ST-LINK_CLI) using the following command:

ST-LINK_CLI.exe -w32 <Address> <data> -Rst

I wrote a simple test script that writes the Unix time stamp to some address not currently in use by the code.

I was about to write a function to read the time-stamp and use it to set the RTC time. Until I read the following in the ST-LINK Utility User Manual:

-w32 supports writing to Flash memory, OTP, SRAM and R/W registers.

When the manual says it supports writing to the R/W registers, does this mean I can directly access the RTC registers and set them? I have tried, but I can't seem to write to these registers.

I would prefer to use this method if it does, as I would not need to write a specific function to handle it on the microcontroller anymore. This means that I can set the RTC time of any microcontroller we currently have in use, instead of needing to update their code.

What I intended to do

To set the RTC registers, I tried to do the following steps, as described in the STM Reference Manual:

set DPB bit in PWR_CR register
write 0xCA to RTC_WPR register
write 0x53 to RTC_WPR register
stop the RTC by setting the INIT bit in RTC_ISR register
select the 1Hz clock by writing to the RTC_PRER register
load the current time by writing to the RTC_TR register
load the current date by writing to the RTC_DR register
start the RTC by resetting the INIT bit in RTC_ISR register

To access the registers, I have used the following addresses:

PWR_CR: 0x4000 7000
RTC_WPR: 0x4000 2824
RTC_ISR: 0x4000 280C
RTC_PRER: 0x4000 2810
RTC_TR: 0x4000 2800
RTC_DR: 0x4000 2804

What went wrong

I am not able to write to either of these registers. With the ST-LINK Utility, I get the following message:

Error occured during memory writing!

Using the ST-LINK_CLI:

Writing 0x00000100 at 0x40007000…Error!

Reading these registers is no problem, but I cannot write to them using either the ST-LINK Utility or its Command Line Interface.

The question

How can I write to the R/W registers using the ST-LINK Utility?

Is there some kind of write protect to allow writing to the RTC registers which I overlooked?

Best Answer

Some registers are only legal for a specific access width (ie, -w32 may not be correct), or may not read back the written values which could cause a problem with verification.

There might also be sequence or state restrictions on accessing things.

An option that should work around most conceivable issues would be to craft a tiny program to do the job which would linked to run in RAM. You could substitute the data into its binary after figuring out the offset, upload the modified version, and run it. Or you could have the program get values from a region of RAM outside of the file's extents, which you would set before running. With finer grained control of the stlink you could also pass values in CPU registers, though you might(?) need the alternate open source command line program rather than ST's to do that (this small routine in RAM method is incidentally how that program accomplishes writing to flash)

Related Solutions

Electronic – DS3232M Skips seconds when writing to SRAM

Received this response from Maxim technical support:

After further investigation, we concur that there is a chip problem.

If you begin a write to SRAM at an even address boundary (18h, 20h, 28h, etc.) the internal RTC counter chain is improperly being reset. This reset action is visible if SQW happens to be high when you wrote to the memory.

SRAM locations 14h-17h do not appear to have this anamoly.

Short-term work-arounds:
1) Avoid writing to SRAM locations 18h-FFh
2) Write to SRAM prior to setting the RTC

We will fix the chip. Thank you for bring this to our attention.

Maxim has published this errata covering the issue.

Electronic – arduino – Problem using DS1337 – RTC

Your connections seem fine. Also, from the RS1337 datasheet, you can power the IC with both 5V and 3.3V. Both are within the IC's described recommended DC operating conditions.

If you have an oscilloscope handy, put the probe on X1 then on X2 (I never know which is the correct one, so I try them both, one at a time) and check if the crystal is oscillating. If you get a clean 32,768Hz square wave, then it's oscillating properly.

Also, you need to double-check whether you've followed the board layout restrictions regarding ground and signals going near the crystal pins, as per datasheet. I'm copying the relevant part below:

Restrictions for board layout for DS1337

If there's a signal going near the crystal pins, the internal IC registers will get corrupted. Then you'll get all sort of weird symptoms. That may be the cause of your problem.

I got sloppy in one of my layouts with the DS1307 RTC and got similar problems. In my case, I could set the time, but the minutes register would decrease unit by unit, randomly.

If you're board doesn't follow the recommendations, one way of fixing it is to ground crystal case (like so: Is case grounding compulsory in typical 32.768kHz crystal for Real Time Clock?). That did the trick for me.

Edit: Looking again at your serial monitor printout, it looks like your code was not able to set the clock time. The time it's printing on serial is likely the time you tried to set, but failed. To me, that means that the I2C communication is not working properly. Maybe it's the device address that's wrong, or a problem with the wiring. I see that you have both pull-up resistors properly wired to SCL and SDA, so that's good. But I would double-check all that wiring.

To properly debug the I2C communication, you'll need an oscilloscope (like I did in this question of mine: What happens if I omit the pullup resistors on I2C lines?).

Edit 2: I still thinking you're not setting the time as you imagine. That's because the code below sets the values you defined into the C++ object called RTC (which sits in the Arduino's RAM), but it fails to set them to the RTC IC:

void setup() {
    RTC.start();
    RTC.setSeconds(00);
    RTC.setMinutes(00);
    RTC.setHours(05);
    RTC.setDays(06);
    RTC.setMonths(3);
    RTC.setYears(2014);
    RTC.writeTime();      // I think this line is failing

    // But the lines above succeed in setting the time into RAM (but not on the RTC)
}

Then, you print the time inside loop(), but using the values in RAM:

void printTime(byte type) {
    Serial.print(int(RTC.getMonths())); // these values come from RAM, not the RTC
    Serial.print(int(RTC.getDays()));
    Serial.print(RTC.getYears());
    Serial.print(int(RTC.getDays()));
    Serial.print(int(RTC.getHours()));
    Serial.print(int(RTC.getMinutes()));
    Serial.print(int(RTC.getSeconds()));  
}

To confirm that, try running the code below:

...
void setup() {
    RTC.start();
} 
void loop() {
    RTC.readTime(); 
    printTime(0);
    delay(1000);
}

If time isn't set, it will print a bunch of zeroes like 0/0/0 0:0:0. If time is set, then it will print 3/6/2014 5:0:0