RTCC无增量PIC16F19186

从你的描述“但我没有得到秒寄存器增量！”我的结论是什么都不增加，不仅仅是秒？你有一个32千赫晶体安装，你有SOSC启用？你可以看到你的FRM的第26.4章。你也可以用SOSC作为输入来测试定时器0，看看你的问题是否与RTC或时钟源有关。



      以下为原文

    From your description "but i don't get that SECONDS registers increment!" I conclude that NOTHING increments, not only the seconds ?
 
Do you have a 32 kHz crystal mounted and do you have SOSC enabled ?
See chapter 26.4 of your FRM.
You could also test Timer 0 with SOSC as input to see whether your problem is related to the RTC or the clock source.

谢谢你的回答，是的，我已经安装了水晶32千赫，SSOC也启用了，我试着在Time1中断，从SOSC时钟，LED和LED看起来像快速闪烁，但我可以看到它完全闪烁。秒寄存器不递增，任何寄存器工作。



      以下为原文

    Thanks for answer, yes, i have mounted crystal 32 khz, and SOSC's enabled too, i've tried to toogle led on timer1 interrupt, clocked from SOSC, and LED look like fast blink, but i can see it perfectly blink.
SECONDS register doesn't increment, and any register work.

你必须解锁时钟硬件。编写时间数据，并启动。我有一些代码在16位，你可以看到时钟硬件解锁。



      以下为原文

    You have to unlock the clock hardware.
Write the time data and enable to start.
 
I have some code in 16bit where you can see the clock hardware unlocked.
.include "xc.inc"
.include "UtilityLib2.inc"
.global _setinternalclock
.section utilitycode,code
;----------------------------------------------------
.equ DT,    w0    ;DateTime_t *

_setinternalclock:  ;void setinternalclock(DateTime_t *DT);  bcd
    mov     #0x55,w0
    mov     w0,NVMKEY
    mov     #0xAA,w0
    mov     w0,NVMKEY
    bset    RCFGCAL,#RTCWREN        ;Set RTCWREN bit
    bclr    RCFGCAL,#RTCEN
    mov     RCFGCAL,w0
    ior     #0x300,w0            ;all
    mov     w0,RCFGCAL
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ;set date
    mov     [DT+DT_Year],w0        ;get year
    mov     w0,RTCVAL            ;set year
    mov     [DT+DT_DateMonth],w0    ;get date/month
    mov     w0,RTCVAL            ;set month/date
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ;set time
    mov     [DT+DT_HourDay],w0        ;get hour/day
    mov     w0,RTCVAL            ;set hour/day
    mov     [DT+DT_SecondMinute],w0    ;get sec/min
    mov     w0,RTCVAL            ;set min/sec
    bset    RCFGCAL,#RTCEN
    bclr    RCFGCAL,#RTCWREN        ;Set RTCWREN bit
    return
;----------------------------------------------------
.end
Using this structure
typedef struct{
    union{
        struct{
            unsigned char   Second;
            unsigned char   Minute;
        };
        unsigned int    SecondMinute;
    };
    union{
        struct{
            unsigned char   Hour;
            unsigned char   Day;
        };
        unsigned int    HourDay;
    };
    union{
        struct{
            union{
                struct{
                    unsigned char   Date;
                    unsigned char   Month;
                };
                unsigned int    DateMonth;
            };
            unsigned int    Year;
        };
        unsigned long   TotalSeconds;
    };
}DateTime_t;

但是对于PIC16F不是真的…如果我添加：NVMCON2= 0x55；NVMCON2= 0xAA；它仍然不工作。



      以下为原文

    but is not true for PIC16F... if i add:
 
NVMCON2 = 0x55;
NVMCON2 = 0xAA;
 
it doesn't work still.

编译器的哪种版本？哪种模式（免费，性病，PRO？）你检查了序列产生的汇编语言吗？



      以下为原文

    Which version of the compiler?
Which mode (Free, Std, Pro ?)
Did you check the assembly language that sequence produced?
 

谢谢你的回答，我的版本是1.42，免费模式。我在C HiLuGe工作，我在ASM中什么都不做，但是我在汇编中发现了什么？？



      以下为原文

    Thanks for answer, my version is 1.42, free mode.
I'm working C lenguage and i don't make anything in asm, but what I find in the
assembly??
 
 

我通过配置Time1和WorksSoC检查SoSC的工作，所以问题可能是SOSC不与RTCC连接。但我的错误是什么？？？？谢谢



      以下为原文

    I check the works of SOSC by configuring the TIMER1 and works, so the problem can are the SOSC not connecting with the RTCC.. but what is my mistake ??? thanks 
 

XC8将C代码编译成汇编语言。您可以看到它在.LST文件中所做的输出，这将是您的HEX文件所在的地方。



      以下为原文

   
XC8 compiles your C code into assembly language.
You can see what it did in the .lst file it outputs, which will be where your hex file is.
 

正如我所怀疑的，这是免费模式中的一个已知问题，它是在XC8版本1.44中固定的。当前版本是1.45，所以你应该更新。这是来自V1.45的“Read MexC8.HTM”文件。



      以下为原文

   
As I suspected, that is a known problem in Free mode, that was fixed in XC8 version 1.44
The current version is 1.45, so you should update.
This is from the "Readme_XC8.htm" file that comes with v1.45

 

我读数据表，但在RTCC部分，没有任何关于“必须编写TaHAT序列”使用RTCC寄存器。



      以下为原文

    I read datasheet, but in the RTCC Section, there is not anything about "must write tahat sequence" for use RTCC Registers.

必须首先设置RTCNRTCRWRIEN。（写使能）RTCCONBITS.RTCWREEN＝1；然后您可以设置/CLR RTCEN和所有其他寄存器。不需要任何解锁序列。您几乎有：RTCWREN（＝1；RTCCONBITS.RTCWREEN＝1；//unClinux）。RTCEN＝0；/ /禁用TimeTCCONTITS。RTCEN＝1；//启用或写T。O秒将启用TrrTCCONTITS。RTCWREEN＝0；/ /锁读在10秒期间返回时间，以查看它是否正在更新。



      以下为原文

    RTCCON
RTCWREN must be set first.  (write enable)
RTCCONbits.RTCWREN = 1;
Then you can set/clr RTCEN and all the other registers.
 
Looking at the datasheet, no unlock sequence is required.
 
You nearly had it:
RTCWREN(= 1;
 
RTCCONbits.RTCWREN = 1;   //unlock
RTCCONbits.RTCEN = 0;       //disable
Set the time
RTCCONbits.RTCEN = 1;       //enable or a write to seconds will enable this
RTCCONbits.RTCWREN = 0;  //lock
Read back the time over a 10 second period to see if it is updating.
 
 

我检查了一个PIC18F66 K22的旧RTC代码，它需要解锁序列来设置RTCWREN，但是PIC16F19XXX数据表没有提到这样的要求是正确的。您已经启用了RTC中断，但没有显示ISR。你处理潜在的中断吗？半秒＝0；浪费精力。半秒是只读的，你如何确定秒不改变？因为你的液晶显示器没有变？我想看看调试器中的实际秒寄存器。也许LCD代码中有bug，或者在TimeGET函数中。或者是如何使用MCC函数的bug。



      以下为原文

    I checked some old RTC code for a pic18f66k22 and it required the unlock sequence to set RTCWREN, but you are correct that the pic16f19xxx datasheet does not mention such a requirement.
 
You've enabled RTC interrupt, but don't show an ISR. Are you handling potential interrupts?
 
RTCCONbits.HALFSEC = 0; is wasted effort. HALFSEC is read only.
 
How are you determining that SECONDS isn't changing? Because your LCD doesn't change? I would want to look at the actual SECONDS register in the debugger. Perhaps there's a bug in the LCD code, or in the timeget function. or a bug in how you are using those MCC functions.
 
 

我相信有一个硬件错误阻止它工作。当我在这里耽搁（比时钟的滴答多一点）时，它就起作用了。否则：不去。请注意，对于这个测试，我使用内部时钟（RTCCONBITS.RTCLKSELL＝0B01），因为我想绝对地确定这个问题与SOSC或XTAL或其他无关。从PIC16F19156（同样的RTCC模块作为您的芯片）的结果，使用XC8版本1.44（在自由模式下）：1：RTCCONN＝0x212：RTCCONN＝0x81，这表明设置了RTCEN（MSB），并且它开始计数。（TAA DAA）在我的测试中，我只检查了循环中的秒寄存器，当它从先前的读取中改变时，打印出了值。（当然，因为我的测试是使用内部时钟而不是晶体，它不准确，但它确实计数。）另一方面……当我评论延迟，我得到1:RTCCONN＝0x212:RTCCONN＝0x01，这表明RTCN位还没有被设置。（这不算数）注意到我已经测试过这足以相信它不是印刷品，RTCEN真的没有设置，除非我在RTCRWEN清除之前延迟。这种延迟似乎只有在设置或清除RTCEN后立即清除RTCWRN才是必要的。在RTCC中，我还没有看到其他位或其他寄存器的问题。注意，在RTCJTimeTeSe（）函数的末尾，几乎肯定有一个类似的序列，因此，如果调用该函数，它可能最终会被设置为RTCEN。对于初学者，为什么不在初始化代码中注释对RTCJTimeSeTe（）的调用并查看它是否可以启动？一个快速测试（而不是改变初始化代码和代码在RTCccTimeSeTee（）中可能会在你的初始化代码之后放置类似的东西：我也建议如果有更多的困难，从内部振荡器开始，这样我们就不必再打扰你了。再说一遍，SOSC，水晶等等。如果它能工作，那么你可以挖得更深一点。哦，顺便说一下，我也会推迟尝试使用中断，直到你有基本的功能正在进行中。我们不知道你打算用中断做什么，我们看不到你的ISR，所以，我顺便提一下，我看了MCC第3版，检查了它的一些功能，它使用了来自lt，t.h & gt的TM结构，而不是你的TAMPSY-RTCC定义。你有没有什么理由决定自己滚动，或者你的MCC真的生成它们吗？我的意思是，我的MCC的RTCccStTimeTimes（）和RTCPCGETTIMEN（）函数对StuttTMbTeLink的指针进行操作：很难帮助别人通过遥控器调试（特别是当他们的代码的一部分来自MCC），因为我看不到所有的代码，但是在设置或清除之后延迟了。清除RTCWRN之前的GRTCEN似乎是必要的第一步。至少这是我的经历，戴夫



      以下为原文

   

I believe there is a hardware bug that prevents this from working.  When I put in a delay here (a little more than the tick of the clock), it works.  Otherwise: no go.  Note that, for this test I am using the internal clock (RTCCONbits.RTCCLKSEL = 0b01) since I wanted to make absolutely sure the problem was not related to SOSC or XTAL or anything else.


    printf("1: RTCCON = 0x%02Xn", RTCCON);
    RTCCONbits.RTCEN = 1;
    __delay_us(50);
    RTCWREN = 0;
    printf("2: RTCCON = 0x%02Xn", RTCCON);


Results from my PIC16F19156 (same RTCC module as your chip), using XC8 version 1.44 (in Free mode):
1: RTCCON = 0x21
2: RTCCON = 0x81
This shows that RTCEN (the m***) is set, and it starts counting.  (Taa-daa)
For my test I just checked the seconds register in a loop and printed out the value when it changed from the previous reading.  (Of course, since my test is using the internal clock rather than a crystal, it's not accurate, but it does count.)
 
On the other hand...
When I comment out the delay, I get
1: RTCCON = 0x21
2: RTCCON = 0x01
This shows that the RTCEN bit has not been set. (And it does not count.)

Note that I have tested this enough to believe that it's not an artifact of printing; RTCEN really doesn't get set unless I put in a delay before clearing RTCWREN! 
 
This delay seems to be necessary only after setting or clearing RTCEN immediately before clearing RTCWREN. I haven't seen any problems with other bits or other registers in the RTCC.

Note that there is almost surely a similar sequence at the end of the RTCC_TimeSet() function, so, if you call that function it will probably end up with RTCEN not set.  For starters, why not comment out the call to RTCC_TimeSet() in your initialization code and see if it can get started?
 
A quick test (instead of changing your initialization code and the code in RTCC_TimeSet() might to put something like the following after your initialization code:
 

    // Make dang sure it's enabled
    RTCCONbits.RTCWREN = 1;
    RTCCONbits.RTCEN = 1;
    // For now, leave RTCWREN set so that you can begin testing.



I also suggest that if there are further difficulties, start with the internal oscillator so that we won't have to bother you again and again about SOSC, crystals, etc.

If it works then you can dig a little deeper.

Oh, and, by the way, I would also put off trying to use interrupts until you have the basic functionality underway.  We don't know what the heck you intend to do with the interrupt, and we can't see your ISR, so:

    //PIR8bits.RTCCIF = 0; // Clear the RTCC interrupt flag
    //PIE8bits.RTCCIE = 1; //Enable RTCC interrupt


I will mention in passing that I looked at MCC version 3 to examine some of its functions, and it uses the tm structure from instead of your temps_RTCC definitions.  Is there any reason you decided to roll your own, or did your MCC actually generate them?  I mean, my MCC's RTCC_SetTIme() and RTCC_GetTime() functions operate on pointers to struct tm
 
Bottom line: It's hard to help someone debug by remote control (especially when part of their code "comes from MCC") since I can't see all of your code, but the thing about delaying after setting or clearing RTCEN before clearing RTCWREN seems to be a necessary first step.  At least that's my experience.
 

Regards,

Dave

我喜欢一个外部的RTC，如马克西姆集成DS323 1随着时间的准确性。内置的EEPROM和RAM.MCP79410 1K EEPROM和64 BSRAM。



      以下为原文

    I prefer an external rtc such as the Maxim Integrated DS3231 for accuracy over time.  Tuned xtal built in.
 
Microchip make a nice rtc including built in eeprom and ram.
MCP79410      1K eeprom and 64B sram.

谢谢，问题已经解决了！作为SayDaveKW7X，在硬件中存在一个错误，RTCC需要一个延迟预期的时钟增量时间指令，否则RTC不能启用。



      以下为原文

    Thanks, problem has been fix! as say davekw7x, there is a bug in to hardware, RTCC require a delay intended increment time instruction of clock, otherwise, RTC doesn't enable.

似乎这个HW bug应该被记录在所有实现这一RTCC模块的PICS的勘误表中。看起来好像RTCEN变得有效（然后可读）被合成到某个RTCC内部状态。



      以下为原文

    Seems this HW bug should be documented in the Errata Sheets of ALL PICs implementing this RTCC module.
Looks a bit as if RTCEN becoming effective (then readable) is synchonized to some RTCC-internal state.

我很高兴你能成功！我已经提交了一张Microchip的机票以及一个完整的项目来展示这个问题和它的软件修复。过去的经验表明，他们并没有很快地更新文档/勘误表。我还把可能影响某些用户的票据放在另一个项目上：RTCCON寄存器（数据表中的寄存器24-1）的描述非常小心地指出必须设置RTCWENA以改变RT的值。岑它并不表示RTCLKSEL位是相同的，但是实际上，除非设置了RTCWENA，否则它们也不能改变。RTCLKSEL的更改是即时的，并且不需要RTCEN生效所需的同步延迟。



      以下为原文

   
I am glad you were able to get it going!

I had submitted a ticket to Microchip along with a complete project that shows the problem and its software fix.  Past experience shows they don't update documentation/errata very quickly.
 
I also put another item on the ticket that could affect some users:
The description of the RTCCON Register (Register 24-1 in the Data Sheet) very carefully points out that RTCWENA must be set in order to change the value of RTCEN.  It does not indicate the same is true for the RTCCLKSEL bits, but, in fact they also can't be changed unless RTCWENA is set.  The changes to RTCCLKSEL are immediate, and do not require the synchronization delay necessary for RTCEN to take effect.
 
Regards,
 
Dave
 
 
 

嗨，戴夫，对于RTCC的所有“设置”都期望设置RTCWEN。对于设置/清除RTCEN位，不需要这种必要性（因为许多其他E/DIS没有这种机制工作）。这是他们强调RTCEN的必要性的原因。



      以下为原文

    Hi Dave,
for all "settings" of the RTCC one would expect having to set the RTCWEN.
For setting/clearing the RTCEN bit, this necessity is not expected (as many other EN/DIS work without such a mechanism). I guest this is the reason why they emphasize the necessity for RTCEN.