RTC Counter value could not be set

klaus239955_st · ‎2011-08-15

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

target state: halted

target halted due to debug-request, current mode: Thread

xPSR: 0x01000000 pc: 0x00019db4 msp: 0x2000ff0c

klaus239955_st · ‎2011-08-19

Posted on August 19, 2011 at 15:47

Even with no load capacitors and the 6pF crystal the problem is solved.

No I try to check the code.

But if it is a software problem why do only a few parts have this problem ?

klaus239955_st · ‎2011-08-19

Posted on August 19, 2011 at 15:49

Even with no load capacitors and the 6pF crystal the problem is

N O T

solved.

No I try to check the code.

But if it is a software problem why do only a few parts have this problem ?

John F. · ‎2011-08-22

Posted on August 22, 2011 at 15:36

Check with an oscilloscope if the crystal is oscillating. Check the STM32 registers to see if the RTC is enabled and the reset status. Connect a real backup battery in place of the supercap (and remove the diode from VCC) and see if the chip behaves normally. If it works with a backup battery but not with the supercap, suspect you have a glitch at startup. Either way does resetting the part after startup help? Either manually or with the IWDG?

ColdWeather · ‎2011-08-23

Posted on August 23, 2011 at 13:22

BTW, John F.'s posting hit me to an idea. Some time ago I implemented a real time clock using MK41T56 and a supercap. I recall, I got similar problems with the chip: it lost time upon switch on. I added a ceramic capacitor of about 1uF parallel to the supercap, and the problem had gone.

The supercaps have a relatively high internal impedance especially for spikes.