进入RTC初始化模式之前一定要使能了RTC的时钟，并且RTC时钟稳定下来了，否则可能出现问题。 使用LL库写代码，往往需要我们对硬件操作时序把握得更清晰。
这个调试起来很麻烦，因为是65535，所以可以很精确知道第几次会无法唤醒 先确定是完全无法唤醒，还是唤醒后执行出问题卡死了，可以在唤醒后啥都没干的时候先输出个简单的标志性字符作为标记， 看看是不是可以人为增加秒计时，通过这个手段触发每秒唤醒一次，这样18分钟后就能看到现场，就能用调试器看这个寄存器情况 我觉得大概率是自己写的代码出问题，计数溢出什么的，应该不太可能cubemx的代码出问题(不过也要验证一下这一点),如果这个确认，可以17个小时时候输出一下完整内存出来，看看哪个变量开始要溢出了。 所以，1，搞一个机器，只是唤醒，唤醒后啥都不做(自己代码全部屏蔽)，看看18小时后是不是还能正常唤醒 2，搞一个机器，代码修改人为触发rtc快走，现实一秒rtc以为是一分钟，这样18分钟后就要到出问题时间点，方便调试检查 其他的，，18分钟后仔细看寄存器和各变量吧，
做ADC重点注意电源，尤其参考电压的稳定，再就是采用时间参数。 具体到你现在的应用，输入阻抗太大了。 ADC模块对输入阻抗是有最大值限制的，不同系列可能不一样，手册上有明确出来, 对于L4 系列，一般不要超过50K欧。 换成K级吧。有低功耗需求也不至于让一个电池使用万年吧。何况功耗是个整个概念， 或许即使这个地方再怎么省，别的地方不省也白搭。 要不，改成运放做跟随后再接到ADC。这样的话，电路就得调整。
对于这个函数的使用,我是这样理解的： 调用的目的就是为了获得注入通道转换值，并可以得知相应转换结果来自哪个通道， 具体通道号存放在我们调用该函数时提供的地址里。 函数返回后我们可以通过该地址获取注入转换的通道号。 换言之，第二个参数就是个指向uint32_t数据的变量地址。
STM32F407 支持标准的BxCAN 2.0 A and B。是工业级的产品，并非是汽车级别产品。 这些与ECU 通讯标注参数的协议看起来是应用层方面的。 目前还没过这样的应用~~~
确认下文件是否都添加进来了 或者说 路径方面是否有问题。
不排除你说的消耗63KB RAM是有误会。里面可能包含了堆、栈空间大小，不一定是真实用到的。 换言之，你所说情况是可能发生的。 你可以适当调整优化等级，对于没有动态内存分配的应用，把堆空间设置为0无妨。栈空间设置合适即可。
从你截图来看，感觉是FSMC的总线的管脚跟UART3的复用脚有冲突。你可以尝试将UART3的复用脚切换到别的地方试试，我看UART3也可以使用PB10和PB11管脚。
调整了均没用（） 我看到了一篇文章，里面的这个情况和我的情况较为相似： Camera电路、图像传感器问题汇总_图像传感器引起的图像质量问题-CSDN博客 两根数线和其他设备复用导致的偏绿问题 8根数据线中有两根被其它设备复用了，所以这两根没出数据。 但是我依旧不知道如何处理（） 因为官方自带的例程是好的，所以线应该是没接错？ 请问有什么解决办法吗
谢谢您的回复，换台电脑是可以正常显示的，就是这台不行，不知道系统哪里不对了，java环境也重装过了，换成6.8和6.10也都不行，只能装6.3，不知道是哪里设置不对
你看看是否跟MPU配置有关。你不妨先关闭cache验证下，如果跟Cache有关，就针对性做MPU配置，将相应访问区域的cache能力关闭。
微信公众号
手机版
