1. Bootloader架构设计

任务目标

设计一个基于AUTOSAR的Bootloader架构，明确其内存映射、启动流程与通信接口。本案例聚焦于架构层面的关键设计决策，不涉及具体MCU外设寄存器配置。

内存映射设计

基于AUTOSAR标准，Bootloader将Flash划分为三个独立区域，各区域功能与保护策略如下表所示：

配置区独立于应用区，确保应用升级失败时Bootloader仍可访问Flash驱动与通信参数，从而支持恢复性编程。

启动流程

Bootloader启动流程分为三个阶段，核心逻辑如下：

// 启动流程状态机
typedef enum {
    BOOT_STATE_INIT = 0,
    BOOT_STATE_CHECK,
    BOOT_STATE_JUMP_APP,
    BOOT_STATE_PROGRAM
} BootStateType;

BootStateType Boot_StartupSequence(void)
{
    // 阶段1: 硬件初始化（时钟、RAM、看门狗）
    Boot_InitHardware();

    // 阶段2: 检查是否需要进入编程模式
    // 条件: 应用区无效 或 收到编程请求标志
    if (Boot_IsAppValid() == FALSE || Boot_IsProgrammingRequested() == TRUE)
    {
        return BOOT_STATE_PROGRAM;
    }

    // 阶段3: 跳转至应用区
    return BOOT_STATE_JUMP_APP;
}

void Boot_MainLoop(void)
{
    BootStateType state = Boot_StartupSequence();

    if (state == BOOT_STATE_JUMP_APP)
    {
        Boot_JumpToApplication();
    }
    else if (state == BOOT_STATE_PROGRAM)
    {
        // 进入UDS诊断会话，等待编程请求
        Uds_Init();
        Uds_MainFunction();  // 循环处理诊断请求
    }
}

应用区有效性检查通过校验应用区起始位置的校验和完成。编程请求标志由UDS诊断服务（0x10会话控制）或外部引脚触发。

通信接口设计

Bootloader基于UDS（ISO 14229）协议，通过CAN总线与上位机通信。关键诊断服务映射如下：

• 0x10：会话控制（编程会话切换）
• 0x27：安全访问（解锁Flash编程权限）
• 0x34/0x36/0x37：请求下载/传输数据/退出传输（固件写入）
• 0x31：例程控制（擦除Flash、校验应用）

通信接口采用AUTOSAR COM模块进行CAN报文收发，诊断报文ID固定为：物理请求0x7E0，物理响应0x7E8。Bootloader启动后默认进入默认会话，收到0x10 02子功能后切换至编程会话。

验证方法

本案例为架构设计，验证路径如下：

1. 静态验证：检查内存映射表是否覆盖全部Flash空间且无重叠；确认启动流程状态机覆盖所有分支（应用有效/无效、编程请求有无）。
2. 编译验证：将上述启动流程代码与AUTOSAR MCAL驱动（MCU、PORT、FLS）链接，确认链接脚本中三个区域的地址分配与映射表一致。
3. 运行验证：在开发板上首次烧录Bootloader后，观察LED指示是否进入编程模式（应用区为空时）；通过CAN发送0x10 02，确认返回0x50 02响应，即通信接口工作正常。

通过条件：编译无链接错误；CAN诊断请求能正确响应；应用区写入后重启能跳转至应用。