跳转至内容
  • 版块
  • 最新
  • 标签
  • 热门
折叠
品牌标识

YunTu Forum

YTMicro.com
  1. 主页
  2. Discussion & Question
  3. YTM32B1H系列
  4. YTM32B1HA0 FlexCAN Legacy Rx FIFO DMA 开启 D-Cache 时的 Cache 维护时序确认

YTM32B1HA0 FlexCAN Legacy Rx FIFO DMA 开启 D-Cache 时的 Cache 维护时序确认

已定时 已固定 已锁定 已移动 未解决 YTM32B1H系列
4 帖子 2 发布者 91 浏览
  • 从旧到新
  • 从新到旧
  • 最多赞同
登录后回复
此主题已被删除。只有拥有主题管理权限的用户可以查看。
  • gaoShengG 离线
    gaoShengG 离线
    gaoSheng
    编写于 最后由 编辑
    #1

    芯片型号:YTM32B1HA0x
    SDK版本:1.4.0
    应用场景:FlexCAN Legacy Rx FIFO + DMA,Cortex-M7 D-Cache开启

    问题现象:

    FlexCAN Legacy Rx FIFO通过DMA接收报文后,SDK会解析ID、DLC,
    并对Data执行字节序转换。

    如果应用在FLEXCAN_EVENT_DMA_COMPLETE回调中对接收缓冲区执行
    SCB_InvalidateDCache_by_Addr(),偶发出现每4字节反转的现象。

    例如:

    期望数据:
    00 11 04 00 00 00 2D 0C

    e616e56e-8f8d-4014-a948-7a17c520d2fd-e3a073a3e3e155fa32971b12035bc9f9.png
    异常数据:
    00 04 11 00 0C 2D 00 00

    2108b6d9-e6e9-4f85-8892-5d47f836f768-b319bd183c959ad555a882e180d47a30.png
    目前分析认为,DMA直接写SRAM,而CPU通过D-Cache访问缓冲区。
    SDK完成ID/DLC解析和字节序转换后,应用再次Invalidate,
    可能会丢弃CPU在Cache中完成但尚未回写SRAM的修改,
    导致后续重新读到DMA写入的原始格式。

    计划将Cache维护放到SDK的DMA所有权切换位置,时序如下:

    CleanInvalidate接收缓冲区
    -> 配置并启动DMA
    -> DMA完成
    -> 停止DMA通道或确认DMA不再访问缓冲区
    -> Invalidate接收缓冲区
    -> SDK读取CS/ID/Data
    -> 解析ID和DLC
    -> 执行Data字节序转换
    -> 触发用户回调

    SCB_CleanInvalidateDCache_by_Addr(rxBuffer, 16U);
    DMA_DRV_StartChannel(channel);
    
    /* DMA完成回调 */
    DMA_DRV_StopChannel(channel);
    SCB_InvalidateDCache_by_Addr(rxBuffer, 16U);
    
    ParseIdAndDlc(rxBuffer);
    SwapDataByteOrder(rxBuffer);
    UserCallback(rxBuffer);
    

    e8688c98-a303-468e-a987-d6874365d8e1-8608560b0aae8a85b5d7bfd6698fa040.png
    96cd757b-c421-4469-85bb-c90eda851fdc-45c66bfe5a60d7718b94b81504c11d3c.png
    应用回调中不再对rxBuffer执行Cache操作,并且先处理或复制当前报文,
    最后再重新调用FLEXCAN_DRV_RxFifo()挂接下一次DMA接收。

    typedef struct ALIGNED(32)
    {
    uint32_t cs;
    uint32_t msgId;
    uint8_t data[64];
    uint8_t dataLen;
    } flexcan_msgbuff_t;

    想请确认以下问题:

    1. 上述CleanInvalidate -> DMA -> Invalidate -> SDK解析 -> 用户回调
      的Cache维护顺序是否合理?

    2. DMA完成后,Invalidate是否必须放在SDK第一次读取CS、ID和Data之前?

    3. 用户回调中是否不应再次Invalidate当前接收缓冲区?

    4. Legacy Rx FIFO的Cache维护长度使用16字节是否合适?

    1 条回复 最后回复
    0
    • FrankieF 离线
      FrankieF 离线
      Frankie YunTu
      编写于 最后由 编辑
      #2

      通常DMA和CPU交互的RAM建议设置为NO-CACHE区域。


      DMA 传输完成,CPU 访问这片区域前,invald cache 一次就够了

      gaoShengG 1 条回复 最后回复
      0
      • gaoShengG 离线
        gaoShengG 离线
        gaoSheng
        回复了Frankie 最后由 编辑
        #3

        Frankie 感谢大佬的回复,请问当前Invalidate的位置是合理的吗(在DMA_DRV_StopChannel的后面,且Legacy Rx FIFO的Cache维护长度是16字节)

        1 条回复 最后回复
        0
        • FrankieF 离线
          FrankieF 离线
          Frankie YunTu
          编写于 最后由 编辑
          #4
          1. 不确定代码结构,加到CPU第一次访问这个RAM区域前。
          2. 没问题。
          1 条回复 最后回复
          1

        • 云途开发生态介绍

          快速上手云途开发生态

        • 云途论坛规则/Yuntu Forum Rules

          发帖前请查看

        • YT CONFIG TOOL调查问卷

          帮助改进和优化YT CONFIG TOOL,有机会抽取YTM32B1ME0 EVB哦...

        • can
          28
          demo
          26
          uds
          14
          lin stack
          13
          md14
          6
          yt-link
          6
          fbl
          5
          adc模块
          4
          Online Users
          • 登录

          • 登录或注册以进行搜索。
          • 第一个帖子
            最后一个帖子
          0
          • 版块
          • 最新
          • 标签
          • 热门