你检查下你的PHY地址是否正确了。硬件线路方面是OK？ 我看你的截图，你的IP地址跟你的网关明显不匹配，不知你具体代码是否调整了，还是说配置时手误操作了。 按照你图示的网关和掩码配置，你的IP地址应该是192.168.1.2 到192.168.1.254 的范围内。
这个问题大概率可能是因为D-Cache导致的数据一致性问题。 你先把D-Cache关闭后验证下。 你可以将目前DMA访问的内存区域通过MPU配置为Device属性。
这里的callback函数可以理解为事件响应函数，即发生特定事件后才会被调用执行的函数。 具体到你现在提到的两个回调函数，一般来讲，是在发生TIMER事件或UART事件及中断时需要进一步调用的用户处理函数。 你现在说能否在同一程序中调用那两个回调函数。从逻辑上讲是没有问题的，你想什么时候调用都可以 。但从回调 函数来讲，似乎失去了它的意义，它两个本应是针对定时器事件和UART事件才被调用的。 当然，也不排除你就是希望某个时刻将那两个函数都调用一下。最终看你的具体应用来定。
进入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根数据线中有两根被其它设备复用了，所以这两根没出数据。 但是我依旧不知道如何处理（） 因为官方自带的例程是好的，所以线应该是没接错？ 请问有什么解决办法吗
微信公众号
手机版
.png)
