楼主写得很详细，但当中可能存在着一些误解。相信TI的RD不会那么差。
对于你的其中一个问题。RTC由第一次设置指定的时间后，以后断电后需要后备电池来提供给RTC工作。也就是说第一次上电后由计数模式改定时模式，这样一直工作在RTC模式。所以要靠电池为提供MCU的工作，需要做掉电检测。检测掉电后使MCU处理低功耗模式，此时RTC在运作中。这样就不存在着再次上电被复位。
其他的问题我未一一证实，相信有不少用户也用过RTC的时钟。希望他们能给你意见。

楼主说的RTC情况有向TI FAE反映吗?他们怎么表示,有没有给出一个好的解决办法.如果有,请告诉大家一下.
确实,复位的情况确实不可能完全没有.如果MCU复位了使RTC从计时模式变为计数模式的话确实令人无法接受.这样还不如用外部的RTC芯片算了.也不贵.
另外,请教楼主说的“把它的IO口和复位连在一起了，开机进入非屏蔽状态，关机进入复位状态，才解决这个问题。”具体是怎样做？能否详尽一点的做法和原理。
关于ADC12模块的问题，TI的FAE又是怎样回应的？
楼主的真枪实干和问题的反映情况有助于我们了解得更多真相，谢谢楼主！

想起这个问题，我想给些提示给大家参与。
比如万一系统真的产生出错而导致内部芯片复位时，系统是产生PUC信号还是产生POR信号。这两者对系统各模块寄存器影响是不一样的。若只是产生PUC而没有产生POR，那么PUC会不会影响到RTC模块的工作模式？如果PUC不影响到RTC的定时模式，那么这个应该好办点。这样我们可以让单片机不易产生POR，这个可以在电源设计解决。
否则，如果PUC也将影响到RTC模块的工作模式(使其复位在计数模式)。那么此时真的有点头痛了。
大家看看我的想法对不对....我意思是指PUC和POR是否对RTC的寄存器影响情况。

看来这个贴子都有共同的问题，主要来自RTC新模块的出现。大家对此模块都不太了解其性能，这点咱们应该可以理解的。另外，如果TI官方能够证实这个BUG的存在。应该给予正确的应用指引说明，如果连楼主这种大客碰见这种问题都未能得到TI最终的解决办法。我们作为论坛第三方，应该没有多大的能力去解决这类问题。
坦白说，对于我个人而言。我使用此型号并没有做太多的实例，所以楼主所说的RTC情况并没有碰过。
对于这个问题，我建议是用电池来维护MCU不产生POR动作。另一个楼主提到的不写入数据问题。我认为，作为RTC应用。时间只要设置好一次的话。以后基本上很少要再次设置的，就算有也是过一个时间较长时才人为设置一下(可能人为需要调整时间做修正)。所以，我觉得没太多不必经常写入数据什么的。我不知道这想法是否正确，但最起码作为RTC--实时时钟功能一般调整是比较少的。