如图，scanner.value=27，但直接读SMC offset 4370的值为32，请问这是什么原因导致的？
scanner的结果是周期更新的，不是实时的，会不会是查询的时候有温升，过了几秒后温度升高了
最好贴一下对应的CSR，单从截图看，更新周期是3秒，而且似乎开了防抖，建议看看CSR中debounce相关内容
CSR配置如下：
更新周期是3秒，在不加压的情况下，板卡的温度变化应该不会特别频繁，我反复读SMC命令字，读出来的值都在32-34度之间，且变化频率很小。
但是scanner的值却从来没有和smc读值相同过：BMC刚启动时，scanner读值为27度；运行大概十分钟左右，scanner读值勉强和smc读值贴合；再过一段时间，scanner的读值变成39度左右。而整个期间smc的读值都是32-34之间。
那确实不好解释了，建议弄一个chip读值固定的Scanner对比一下
我另找了同一个smc的scanner：
于web页面上看该传感器读值正常：
scanner读值正常：
但是查询smc命令读值，发现和之前那个命令字的返回一样：
这样看问题似乎是出在bmc.kepler.Chip.BlockIO Read接口了
看一下你的CSR里面有没有SmcDfx，Scanner的值可能是从Dfx同步的
这个也检查过，这个CSR里没有配置SmcDfx
通过tracechip smc芯片，发现每个scanner读写都是先写一次再读两次，而且读写使用的offset和data并非scanner里配置的offset，请问scanner的底层读写逻辑是什么？ 写一次和读两次各是再做什么？读写使用的offset和data来源何处？ 请问能否帮忙解答一下@changxingOpenUBMC
1 个赞
SMC命令字4370、4371、4372读取的同一个位置吧，M/S位为0时，Param似乎是无效的。
见 关于SMC命令字的理解和疑问 - Hardware SIG - openUBMC 论坛
1 个赞
两次读的原因是这样的：BMC并不清楚硬件实际返回的数据是多少，所以会先读8个字节获取到len字段，再通过len字段读取实际要返回的数据长度的数据