Hi,
I'm using a i.MX25 in a custom board and facing problems with internal RTC, the DryIce Timer Counter. When processor is only supplied by BAT_VDD (1.2V), DTCMR (DryIce Time-Counter MSB Register) is not updated, I mean, time is not counted.
I'm printing DSR (DryIce Status Register) value during the beginning of rtc-imxdi module probe and having both SVF (Security-Violation Flag) and NVF (Non Valid Flag) disabled.
Disconnecting my board main power supply, I can verify that NVCC_DRYICE is 1.2V and the oscillator connected on EXTAL32K and XTAL32K is ok.
How can I have RTC working properly? Is there something missing?
Many thanks.
Best regards,
Balconi
Solved! Go to Solution.
Note, the Freescale PDK does not meet all requirements for correct RTC operation.
As known, for i.MX25 RTC reliable operations it is needed :
- to increase NVCC_DRYICE decoupling capacitance (~10uF, 4.7 uF as minimum).
- special power up sequence should be provided.
For new power up sequence NVCC_CRM should provided first, therefore it is needed
to add separate scheme for it.
Old approach assumes that NVCC_CRM may be fed via 3.3V common for NVCC_CRM,
NVCC_CSI, NVCC_SDIO, NVCC_NFC, NVCC_JTAG, NVCC_MISC, VDD_I2C, VDD_EMI_DATA,
VDD_EMI_ADDR, NVCC_ADC OSC24M_VDD, USBPHY1_VDD, USBPHY2_VDD.
Hello karinavalencia, could you please mark this question as not answered? The person who opened it is on vacations, but the team (leonardoalmeida) is still working on the topic.
Tks,
Bruno
Done
Thanks, Bruno and Karina.
I'm updating with some data.
This is hardware from imx.25 BSP:
This is our customized hardware:
Mateus has done everything Yuri has suggested. The Freescale KIT and our board have the same problem, the RTC is lost after some time the board is powered off.
We've made some tests in our board. Into u-boot, it was added init_sequence for printing dryice registers, just after display_banner function. The data collected is:
Test number | waiting time (s) | DTCMR | DTCMR | time wasted based in register (s) |
1 | 60 | 0x517804ca | 0x517804ce | 4 |
2 | 120 | 0x51780530 | 0x51780533 | 3 |
3 | 240 | 0x5178057b | 0x517805ac | 49 |
4 | 480 | 0x51780612 | 0x51780614 | 2 |
5 | 120 | 0x51780660 | 0x51780665 | 5 |
6 | 30 | 0x517807b9 | 0x517807d9 | 32 |
7 | 45 | 0x5178082c | 0x51780850 | 36 |
8 | 120 | 0x51780882 | 0x51780885 | 3 |
9 | 30 | 0x517808c7 | 0x517808ca | 3 |
10 | 30 | 0x517808ef | 0x517808f2 | 3 |
11 | 30 | 0x5178090c | 0x51780926 | 26 |
12 | 30 | 0x5178096c | 0x51780989 | 29 |
I'm available for any further question. I also appreciate your help.
Thansk and Regards.
Leonardo
Note, the Freescale PDK does not meet all requirements for correct RTC operation.
As known, for i.MX25 RTC reliable operations it is needed :
- to increase NVCC_DRYICE decoupling capacitance (~10uF, 4.7 uF as minimum).
- special power up sequence should be provided.
For new power up sequence NVCC_CRM should provided first, therefore it is needed
to add separate scheme for it.
Old approach assumes that NVCC_CRM may be fed via 3.3V common for NVCC_CRM,
NVCC_CSI, NVCC_SDIO, NVCC_NFC, NVCC_JTAG, NVCC_MISC, VDD_I2C, VDD_EMI_DATA,
VDD_EMI_ADDR, NVCC_ADC OSC24M_VDD, USBPHY1_VDD, USBPHY2_VDD.
Just to clarify the problem : is the erratum (ENGcm11122 DryIce: Unexpected Reset) fixed in the case ?
I mean :
A) Special power up sequence should be provided additionally.
Please look at section 3.2.3 (SRTC DryIce Power-Up/Down Sequence) of the recent
datasheet IMX25CEC.
< http://cache.freescale.com/files/dsp/doc/data_sheet/IMX25CEC.pdf >
B) NVCC_DRYICE decoupling capacitance (~10uF) is provided.
Hi, Yuri.
SRTC DryIce Power-Up/Down Sequence is ok, board was designed following this orientation. And NVCC_DRYICE decoupling capacitance (~10uF) is also provided.
Is there another thing that I must look for?
Thanks,
Balconi.
App note AN3874 (i.MX25 Real Time Clock (RTC)) provides general information and an example
regarding the RTC.
http://cache.freescale.com/files/dsp/doc/app_note/AN3874.pdf?fsrch=1&sr=1
Also, from the i.MX25 Security Reference Manual :
"The DryIce time-counter increments only if all the following conditions hold:
• DryIce is in the valid state
• Time-counter enable bit is set
• Time-counter overflow is clear"
The following is moderated link for i.MX25 Security Reference Manual (RM) :
http://www.freescale.com/webapp/sps/download/mod_download.jsp?colCode=IMX258SRM
Note, You should refer to local FFAE, when using this link.
Also please pay attention on app note AN4547 (Secure Boot on i.MX25, i.MX35, and
i.MX51 using HABv3) :
"For the i.MX25, there is a specific CSF command that can be used to unlock
the DryIce module, allowing image software to configure DryIce."
http://cache.freescale.com/files/32bit/doc/app_note/AN4547.pdf
Hi, Yuri.
Thank you for your support.
I'm printing DCR (DryIce Control Register) and DSR (DryIce Status Register) during my kernel boot, inside dryice_rtc_probe function, before "Initialize dryice hardware", and having these values:
DSR: 0x00000100
WTD off: Wire-mesh tampering not detected.
ETBD off: External tampering on pin B not detected.
ETAD off: External tampering on pin A not detected.
WCF on: Register updated with write data.
TCO off: Time counter has not overflowed.
NVF off: DryIce is in the valid or failure state.
SVF off: DryIce is in the valid or non-valid state.
DCR: 0x00000008
TCE on: DryIce time counter is enabled.
All reading and write (bits are off) access are allowed.
DTCR: 0x00000000
All security alarm (bits are off) are disabled.
Could be DryIce entering on failure or non-valid state during my board power off (only supplied by BAT_VDD) and returning to valid state during power on? DryIce needs to have DSR fail bits cleared in order to return to valid state, isn't it?
I'm not using any CSF, is it the problem?
Many thanks.
Best regards,
Balconi