AC7106校验码读取

AC7106校验码读取

1. 核心函数调用

项目中通过sdfile_get_burn_code函数获取校验码：

1
u8 *p = sdfile_get_bn_code(&crc_temp_len);

该函数返回指向校验码数据的指针，并通过参数返回数据长度。

2. 数据结构解析

校验码数据具有特定结构，由填充区域、有效校验码和结束符组成：

1
2
3
4
┌──────────────────────────────────────────────────────┐
│ 填充区域(8字节)   │ 有效校验码(6字节)    │ 结束符(2字节)   │
│ 0xFF 0xFF ...   │ CD 5D 0F 0F 87 C2  │ 0x00 0x00     │
└──────────────────────────────────────────────────────┘

实际代码中，需要跳过前面的8字节填充区域获取有效校验码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// 添加打印校验码的代码
{   
    u8 temp_len;
    u8 *p = sdfile_get_burn_code(&temp_len);
    if (p && temp_len > 0) {
        log_info("Original burn code length: %d", temp_len);
        log_debug_hexdump(p, temp_len);

        // 额外打印通常使用的部分（从偏移量8开始的6个字节）
        if (temp_len >= 14) {
            log_info("Burn code valid part(offset 8, 6 bytes):");
            log_debug_hexdump(p + 8, 6);
        }
    } else {
        log_info("Burn code not obtained");
    }
}

3.字节序问题分析

测试过程中发现测试盒读取的校验码数据与实际存储的数据顺序相反：

  • 实际存储：CD 5D 0F 0F 87 C2
  • 测试盒显示：C2 87 0F 0F

在new_cfg_tool.c文件中找到一段代码：

1
2
3
4
void hex2text(u8 *buf, u8 *out)
{
    //sprintf(out, "%02x%02x-%02x%02x%02x%02x", buf[5], buf[4], buf[3], buf[2], buf[1], buf[0]);
}

该代码显示，系统设计中存在将6字节数据按反向顺序格式化输出的逻辑，测试盒反向显示问题原因可能就是这个。

4.测试盒读取到校验码的来源

在earphone.c里面为TESTBOX_INFO_BURN_CODE注册了一个回调函数，默认就是u8 *p = sdfile_get_bn_code(&crc_temp_len);
将他改为用户自定义函数，就可以实现读取出88888888校验码了（手动狗头）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 添加自定义校验码回调函数
static u8 *custom_burn_code_callback(u8 *len)
{
    // 定义自定义校验码
    static const u8 custom_code[] = {0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x81, 0x88, 0x88, 0x88, 0x88, 0xdd, 0xee, 0xff, 0x12};
    
    // 设置长度
    if (len) {
        *len = sizeof(custom_code);
    }
    // 返回自定义校验码
    return (u8 *)custom_code;
}

bt_testbox_ex_info_get_handle_register(TESTBOX_INFO_BURN_CODE, custom_burn_code_callback);

日志打印与调试

1
log_debug_hexdump("Burn Code: ", p + 8, 6);