RTC Counter value could not be set

[klaus239955_st]

Posted on August 15, 2011 at 19:04

We have problems with the STM32F102VDT6 We use the RTC with an external Supercap. If the Supercap is empty it takes several minutes until the RTC-Counter values could be written (in order to set actual date and time). If the supercap is charged there seems to be no problem to write to the RTC-Counter. We have several parts with this issue. I'm not able to debug this situatuion. When the Supercap was discharged the debugger crashes before reaching the breakpoint. Afterwards it works because the Supercap is charged enough. Below I attach the output of the debugger when it doesn't work. :

Open On-Chip Debugger 0.3.1-snapshot (2009-12-08-16:09)

$URL$ For bug reports, read  

http://openocd.berlios.de/doc/doxygen/bugs.html

500 kHz jtag_nsrst_delay: 100 jtag_ntrst_delay: 100 trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain Warn : stm32.bs: nonstandard IR mask Warn : use 'stm32.cpu' as target identifier, not '0' Info : device: 4 ''2232C'' Info : deviceID: 364511235 Info : SerialNumber: FTSY7AW3A Info : Description: Olimex OpenOCD JTAG A Info : clock speed 500 kHz Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG tap: stm32.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0) Info : accepting 'gdb' connection from 0 Warn : acknowledgment received, but no packet pending undefined debug reason 6 - target needs reset Error: Target not halted Error: auto_probe failed -304

Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)

Info : JTAG tap: stm32.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0) Info : Halt timed out, wake up GDB. Error: timed out while waiting for target halted expected return code but got 'TARGET: stm32.cpu - Not halted' Runtime error, file ''command.c'', line 473:     Warn : target not halted Error: error executing cortex_m3 crc algorithm Warn : target not halted Error: error executing cortex_m3 crc algorithm Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (10094). Workaround: increase ''set remotetimeout'' in GDB Warn : negative acknowledgment, but no packet pending Warn : negative acknowledgment, but no packet pending Warn : negative acknowledgment, but no packet pending Warn : negative acknowledgment, but no packet pending target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00019db4 msp: 0x2000ff0c

[Tesla DeLorean]

Posted on August 15, 2011 at 21:20

Use a serial console, and implement a monitor program, diagnostics, or output telemetry with it instead of using JTAG. Remember that JTAG is quite invasive as it tries to wrestle control of the system at reset. Use telemetry to provide system data, status and flow information, not breakpoints.

Make sure your are enabling the BKP/PWR clock domains, and enabling access. Check the voltage in the uncharged state, the *minimum* voltage for VBAT is 1.8V. It should switch the supply to VDD when present. I don't see any spec saying what happens when there is no power on VBAT at all. I've seen plenty of similar circuits that need the backup domain powered, for the primary to work properly or switch.

[klaus239955_st]

Posted on August 16, 2011 at 10:42

Thank you fore your fast response.

Good idea to use serial diagnostic instead of the jtag. Just a few pieces have this problem. Most of them work. And after a while the electronic with the problem works too. Even if I switch off the power supply for several minutes. Therefore I think the RTC is correct configured, but I check it again. When I say I discharge the Supercap then afterwards VBAT is below 1.8 V. But this is the case with every new produced electronic until it is connected to the power supply the first time. I hope the STM32 has no problem with this initial situation.

[klaus239955_st]

Posted on August 17, 2011 at 14:55

I think I found it. It seems like we use a crystal oszillator with the wrong load capacity (12,5pF). Without this crystal I'm not able to write to the RTC counter.

No I have to wait for another crystal (6pF). Hope this solves the problem.

[Tesla DeLorean]

Posted on August 17, 2011 at 15:53

Or use the internal ~40KHz (8%) LSI to do some testing.

[klaus239955_st]

Posted on August 19, 2011 at 11:17

Even with a crystal with 6pF load capacitance it does not work.

So this is not the solution. It is now the third day without any response from the st technical support.

[John F.]

Posted on August 19, 2011 at 11:46

I could not find a valid part with the number 

STM32F102VDT6.

 The reference manual for the STM32F102 gives some warnings about current injection into VBatt when first applying VDD (+3.3V). I wonder if the supercap is interfering with the VDD rise? It might be (have been?) a good idea to use diodes to isolate the backup and normal power supplies to VBatt so that the pin sees the +3.3V when available and the supercap when +3.3V is down. What is your VBatt schematic? 

[ColdWeather]

Posted on August 19, 2011 at 12:26

STM32F10x's have an internal switch over for battery and Vcc; no external circuitry is needed. The problem can be, though, when the supercap is being loaded, the VBAT trips up very slow, at some moment the switch over occures but the voltage at VBAT is not high enough yet. It can lead to some instability in the back up domain, I think.

1). Try completely to remove the load capacitors at the crystal - I had the similar issue with it. 2). Watch in your code if you really switch the LSE on. 3). Don't forget to enable appropriate BCK and PWR domain bits to be able to make any changes to the backup registers.

[John F.]

Posted on August 19, 2011 at 13:49

''STM32F10x's have an internal switch over for battery and Vcc; no external circuitry is needed'' ... if you are using a real backup cell that can present +3V straight away then maybe you're right but a discharged supercap will look like a very low impedance flat battery.

[klaus239955_st]

Posted on August 19, 2011 at 15:40 Sorry but I mistyped the part number. The correct part number is STM32F103VDT6 ! The Supercap is connected to 3,3V via a shottky-diode. VBat is only connected to the Supercap. But the problem occurs also when the Supercap is charged (about 3V). Only a few parts have this problem. Most of the parts work !