[调试笔记] STM32 FileX库BUG Cache与DMA内存一致性问题

        最近在研究ThreadX和FileX,发现官方STM32H7 x-cube-azrtos包(目前最新版本1.1.0)有一个BUG,本文记录一下,供大家参考。



问题描述:

        移植官方例程Fx_uSD_File_Edit后程序正常运行,但使能FX_ENABLE_EXFAT宏启用exfat文件系统支持和D-Cache数据缓存后,无法挂载exfat文件系统,返回FX_IO_ERROR,关闭D-Cache可以挂载使用exfat文件系统。



原因分析:

        最开始调试的时候思路错了,在FileX协议库里面找了很久没有头绪,但后来一想FileX库具备各种安全认证应该不会出错,于是就从STM32官方包的移植接口中寻找BUG 。

        首先介绍一下Cache,如果CPU要读取的SRAM内的数据在Cache 中已经加载好,这就叫读命中(Cache hit),如果Cache 里面没有怎么办,这就是读Cache Miss。如果CPU要写的SRAM区数据在Cache 中已经开辟了对应的区域,这就叫写命中,如果Cache 里面没有开辟对应的区域,这就是所谓的写Cache Miss。

        STM32H7的Cache可以通过MPU配置成四种策略,

本文没有使用MPU所以Cache默认的策略是01即write-back,write and read allocate。

        介绍一下什么是write-back和write allocate。如果CPU要写的SRAM区数据在Cache 中已经开辟了对应的区域,那么会写到Cache 里面,而不会立即更新SRAM;如果没有,就用到配置write allocate,CPU写到往SRAM里面的数据,会同步在Cache 里面开辟一个空间将SRAM中写入的数据加载进来,如果此时立即读此SRAM区,那么就会有很大的速度优势。

        但如果Cache命中的情况下,此时仅Cache更新了,而SRAM没有更新,那么DMA直接从 SRAM里面读出来的就是错误的。因此如果同时使用Cache的write-back和DMA功能,需要额外的措施保持内存一致性。

        FileX对SD卡读写接口全部位于fx_stm32_sd_driver.c中,由CubeMX自动生成,查看该文件可以发现在读写函数中已经考虑到使用Cache与DMA的情况,如下代码所示。

SCB_InvalidateDCache_by_Addr((uint32_t*)scratch, DEFAULT_SECTOR_SIZE);
SCB_InvalidateDCache_by_Addr((uint32_t*)media_ptr->fx_media_driver_buffer, num_sectors * DEFAULT_SECTOR_SIZE);

        SCB_InvalidateDCache_by_Addr()函数用于将该地址D-Cache无效化,无效化的意思是将Cache Line 标记为无效,等同于删除操作。这样下次读写该地址数据时,D-Cache中无此数据,CPU直接对SRAM读写数据,保证CPU读取到的数据是真实的。


源码分析:

以读取函数为例:

case FX_DRIVER_READ:
        {
            media_ptr->fx_media_driver_status = FX_IO_ERROR;
            unaligned_buffer = (UINT)(media_ptr->fx_media_driver_buffer) & 0x3;

            if (sd_read_data(media_ptr, media_ptr->fx_media_driver_logical_sector + media_ptr->fx_media_hidden_sectors,
                             media_ptr->fx_media_driver_sectors, unaligned_buffer) == FX_SUCCESS)
            {
                media_ptr->fx_media_driver_status = FX_SUCCESS;
            }

            break;
        }

        第4行判断读取地址是否四字节对齐,因为使用MDMA读写SD卡需要地址四字节对齐,并作为参数传入sd_read_data()函数中。

static UINT sd_read_data(FX_MEDIA *media_ptr, ULONG start_sector, UINT num_sectors, UINT use_scratch_buffer)
{
    ...

    if (use_scratch_buffer)
    {
    	read_addr = media_ptr->fx_media_driver_buffer;

        for (i = 0; i < num_sectors; i++)
        {
            /* Start DMA read into the scratch buffer */
            status = BSP_SD_ReadBlocks_DMA(SD_INSTANCE, (uint32_t*)scratch, start_sector++, 1);

            if (status != BSP_ERROR_NONE)
            {
                /* DMA transfer failed, release semaphore and return immediately */
                tx_semaphore_put(&transfer_semaphore);
                return FX_IO_ERROR;
            }

            /* Block while trying to get the semaphore until DMA transfer is complete */
            if(tx_semaphore_get(&transfer_semaphore, DEFAULT_TIMEOUT) != TX_SUCCESS)
            {
                return FX_ACCESS_ERROR;
            }

#if (ENABLE_CACHE_MAINTENANCE == 1)
            SCB_InvalidateDCache_by_Addr((uint32_t*)scratch, DEFAULT_SECTOR_SIZE);
#endif

            _fx_utility_memory_copy(scratch, read_addr, DEFAULT_SECTOR_SIZE);
            read_addr += DEFAULT_SECTOR_SIZE;
        }

        /* Check if all sectors were read */
        if (i == num_sectors)
        {
            status = FX_SUCCESS;
        }
        else
        {
            status = FX_BUFFER_ERROR;
        }
    }
    else
    {

        status = BSP_SD_ReadBlocks_DMA(SD_INSTANCE, (uint32_t*)media_ptr->fx_media_driver_buffer, start_sector, num_sectors);

        if (status != BSP_ERROR_NONE)
        {
            /* DMA transfer failed, release semaphore and return immediately */
            tx_semaphore_put(&transfer_semaphore);
            return FX_IO_ERROR;
        }

        /* Block while trying to get the semaphore until DMA transfer is complete */
        if(tx_semaphore_get(&transfer_semaphore, DEFAULT_TIMEOUT) != TX_SUCCESS)
        {
            return FX_ACCESS_ERROR;
        }

#if (ENABLE_CACHE_MAINTENANCE == 1)
        SCB_InvalidateDCache_by_Addr((uint32_t*)media_ptr->fx_media_driver_buffer, num_sectors * DEFAULT_SECTOR_SIZE);
#endif

        status = FX_SUCCESS;
    }

    /* Operation finished, release semaphore */
    tx_semaphore_put(&transfer_semaphore);

    return status;
}

        第4行,若传输地址不是四字节对齐,则使用内部定义的一块32字节对齐的地址作为中转站,先用MDMA读取到数据,再将数据拷贝到用户提供地址。else分支若地址已经是四字节对齐,则直接使用用户提供的地址进行MDMA传输。

        代码中tx_semaphore_get(&transfer_semaphore, DEFAULT_TIMEOUT) 这个信号量操作用于在MDMA传输过程中使该线程进入休眠,节省CPU资源,在传输完成中断中释放信号量,使该线程恢复运行。

        然而else分支的代码存在一个bug,当用户传入的地址为四字节对齐时,进入else分支,在MDMA传输完成后,进行SCB_InvalidateDCache_by_Addr()操作,但是该函数要求传入的地址为32字节对齐,因为Cortex-M7内核的Cache line大小为八个字。

        所以当传入的地址为4字节对齐但非32字节对齐时,SCB_InvalidateDCache_by_Addr()调用传入的参数不符合要求,D-Cache缓存清除错误,使CPU读取到缓存中错误的值。这就是BUG产生的原因。



解决方案:

        问题找到了,修改起来就很容易了,在判断地址是否4字节对齐的地方改成判断地址是否32字节对齐,BUG圆满解决。

unaligned_buffer = (UINT)(media_ptr->fx_media_driver_buffer) & 0x1f;

  • 1
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: STM32 FileX是一款嵌入式文件系统,专为STM32微控制器系列而设计和优化。它提供了一个强大而灵活的文件管理系统,适用于存储和管理嵌入式系统中的各种文件类型。 STM32 FileX具有以下特点和优势: 1. 系统资源占用低:FileX对内存资源的要求非常低,可以在有限的嵌入式系统中运行,而不会造成系统资源的浪费,从而使得STM32微控制器可以更加高效地执行其他任务。 2. 多种文件类型支持:FileX可以处理各种类型的文件,包括文本文件、二进制文件、图像文件等。它支持常见的文件操作,如打开、读取、写入、重命名、删除等,使得嵌入式系统可以灵活地处理不同类型的文件。 3. 文件系统安全性:FileX提供了数据完整性和文件系统安全性的保护机制。通过使用校验和、CRC校验、写入保护等技术,可以保证文件在读写过程中不会被破坏或损坏,确保数据的可靠性和完整性。 4. 支持多线程:FileX支持多线程操作,可以同时处理多个文件的读写操作。这在复杂的嵌入式系统中非常有用,可以提高系统的整体性能和效率。 5. 高度可配置:FileX可以根据具体的应用需求进行灵活的配置。用户可以根据需要选择适合的文件系统大小、块大小、簇大小等参数,以满足自己的存储容量和性能要求。 总的来说,STM32 FileX是一款功能强大、高效可靠的嵌入式文件系统。它在不占用过多系统资源的同时,提供了丰富的文件操作功能,可以满足各种嵌入式系统对文件管理的需求。无论是嵌入式设备的开发者还是应用工程师,都能够通过使用STM32 FileX轻松实现文件的存储、管理和操作。 ### 回答2: STM32 FileX是STMicroelectronics开发的一款嵌入式文件系统。它是专门为STM32微控制器设计的,提供了可靠的文件系统功能,能够在嵌入式系统中进行文件的读写和管理。 STM32 FileX具有以下特点和功能: 1. 高性能和低资源占用:STM32 FileX采用了高效的算法和数据结构,使其能够在嵌入式系统中快速且高效地进行文件的读写操作,并且占用的系统资源较少,有利于节省处理器的计算能力和内存空间。 2. 可靠的数据保护:STM32 FileX提供了可靠的数据保护机制,包括存储介质上的文件一致性检查、写操作的缓存管理、数据的完整性和可靠性验证等,能够有效地防止数据损坏和丢失,保证了数据的可靠性和一致性。 3. 多种文件系统支持:STM32 FileX支持多种文件系统,包括FAT12、FAT16、FAT32等,能够适应不同的应用需求和存储介质类型。 4. 灵活的文件管理功能:STM32 FileX提供了丰富的文件管理功能,包括文件的创建、打开、读写、删除等操作,能够方便地进行文件的管理和维护。 5. 完善的API接口和开发工具:STM32 FileX提供了完善的API接口和开发工具,使开发者能够快速地集成和使用该文件系统,提高开发效率。 6. 应用广泛:STM32 FileX适用于多种嵌入式应用场景,包括工业自动化、智能家居、车载娱乐系统、医疗设备等,能够满足不同领域的文件管理需求。 总的来说,STM32 FileX是一款高性能、可靠的嵌入式文件系统,能够方便地进行文件的读写和管理,适用于各种嵌入式系统的开发。 ### 回答3: STM32 FileX是一个嵌入式文件系统,专为STM32系列微控制器开发的。它是一个可靠、高效、安全的文件系统,能够管理和操作嵌入式系统中的文件和文件夹。 STM32 FileX提供了许多功能,包括文件的创建、读取、写入、删除等。用户可以通过简单的API来访问这些功能,并可以根据自己的需求进行定制。 STM32 FileX能够有效地管理嵌入式系统中的存储器资源。它支持不同类型的存储介质,如RAM、Flash、SD卡等。通过使用FileX,开发人员可以轻松地在嵌入式系统中添加文件系统,从而使得数据的存储和管理更加方便。 STM32 FileX具有很高的性能和可靠性。它采用了先进的文件索引技术,能够快速地定位文件和文件夹。同时,它还具备数据保护机制,能够确保文件的完整性和安全性。 STM32 FileX是易于使用和集成的。它提供了一个直观的编程接口,使开发人员能够快速地熟悉和使用。此外,它还提供了丰富的示例代码和文档,帮助开发人员更好地理解和使用该文件系统。 总之,STM32 FileX是一个专为STM32系列微控制器开发的嵌入式文件系统。它具有高效、可靠、安全的特性,能够方便地管理和操作嵌入式系统中的文件和文件夹。无论是存储数据,还是进行软件更新和配置,STM32 FileX都能够提供可靠的支持。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值