Frankie

0e44d4968ed210be8ded7bebd1bae9e1.png

image.pngdubug发现是进了这个接收溢出错误，这种情况是怎么回事，咋操作@swust YTCQ_shejiwang

https://account.ytmicro.com/#/role/index 在这个申请下权限

Hi, Minh,
Our SDK currently does not support parsing DBC files and generating any code.

1.对于FEE初始化，理论上不存在失败这个场景，除非用来模拟的Fls完全坏了，不能读也不能写。
2.如果确实需要在调试环境中制造FEE,最直接的方式就是用debug的memory窗口观察正在写入数据的FLS位置，制造写入失败。
3.如果写入失败，对于当前的状态并不会产生什么后果，但是APP需要自行处理本次失败，例如重写一次等。FEE本身不会在写入失败后自动重新写入该Block。对于读取失败也是相同的道理，用户需要自行决定重读还是采用数据默认值，但是需要注意，Fee Read失败的时候，用户用于读取数据的缓存中数据可能已经被部分修改（例如读取一个512字节的block,在最后8byte产生ECC错误而导致读取失败），所以用户需要对缓存中的数据自行进行处理。

LIN STACK Demo暂时还没有集成在YTC配置工具中，可以联系对接的FAE或销售申请获取。

Jacky_tan lin stack目前还未完全集成在配置工具里，需要手动释放，可以找负责的FAE申请一下，申请完需要手动安装一下插件包才能使用；

包括下面的这些static 变量

image.png

目前TP层是固定了的，一个通道占用两个邮箱，一个用于发送，一个用于接收。不管这个TP Channel是否是功能寻址。

TP Channel在接收长消息的时候，还需要回复流控帧，所以不管是只接收还是只发送，都用到了两个邮箱。

如果只是接收或者发送短消息，就当作一个正常 Can 报文转发就行了，不需要使用TP

gaoSheng 是这样的，YTM32B1HA0 如果产生了Unrecovery ECC错误，是先进入的Bus Fault（如果没有使能，则会force为 Hard Fault）。
但是Recovery ECC错误，是直接进入的EFM_Ecc_IRQn中断里面。

Demo是为了演示，因此中断都给开了。实际使用中，因为Recovery ECC错误可以自纠，所以可以不做处理，只需要处理HardFault 即可。

Xuan 使用ME05 demo板跑Macl，实测上电时间需要100ms左右，这边可以确认一下Macl的上电时间吗050a7eca-741d-47fa-9b5d-03a43046fae6-37ff3763d005621a9d36aa06b42b3eb.jpg

我们用了can的sdk驱动，上层cantp是自己用的，但是我用了uds_can_fbl的cantp修改成30 00 00回的话，到会36发数据后，也是没有响应的现象，所以我们觉得是SDK性能在30 00 00条件下，性能需要调整，修改配置是不是就可以优化，如果又控制block size，又规定stmin，可能不满足要求，发的太慢了。

DerKey_convert.zip 参考这个文件

来个会议链接远程聊一下？