标签归档:流程

Microchip公司16位单片机dsPIC33E/PIC24E系列bootloader的开发(2)

上一篇“Microchip公司16位单片机dsPIC33/PIC24E系列bootloader的开发(1)”文章中提到了bootloader一些基本知识以及不同设计架构之间的比较,最终选择了把bootloader置于闪存空间尾部的方案。这篇文章我们要讨论一下bootloader的工作流程,让你了解一下整套bootloader所涉及的方方面面。

一般来说,设计完你的单片机程序以后,编译器会将你的C/C++或者汇编代码编译成二进制代码,通常保存在“.hex”结尾的文件里。这个hex文 件遵循Intel Hex32格式,我会在稍后细谈。然后你需要打开编程器的PC端软件,读入hex文件,确保编程器(Microchip的话是ICD2或者ICD3)已正 确连好,然后二进制代码就通过芯片上的PGC/PGD口写入单片机的闪存里。在这个流程里,Microchip已经帮我们做好了其中所有的工具链,分别 是:编译器(MPLAB IDE X)- 编程器PC端软件(MPLAB IPE X)- 编程器(ICD2或者ICD3) – 单片机接收端(PGC/PGD口)。在bootloader的流程了,你就得自己来开发其中的一些组件了,比如你可以继续使用MPLAB IDE X做为编译器,但是你得有自己开发的INTEL HEX32解析器,接下来就是你自己开发的硬件/软件负责将固件传到单片机上,有很多途径,可以是USB、UART、SPI、I2C甚至是SD卡,然后你 还要开发单片机上的接收/烧制代码,也就是真正的bootloader了。可见,所谓开发bootloader,其实是差不多整一个生态系统。

      1. 理解INTEL Hex32标准
        编译完单片机程序以后,编译器会生成一个hex后缀名的单片机固件。如果你用16进制文本编辑器打开这个文件,你会看到一行一行的16进制码。所有的这些16进制码都服从下面的格式:

         :BBAAAATTHHHH... ...HHHHCC
        

        一个字母表示一个16进制数字(即一个字节byte),其中:

        • [:] 每一行开始比有一个分号,没有列外
        • [BB] HHHH… …HHHH中字节的长度
        • [AAAA] 该行数据在芯片闪存中的起始地址
        • [TT] 该行数据类型,其中
          • 00:数据
          • 01:结尾标志
          • 02:Extended Segment Address Record,片地址偏移
          • 03:片地址偏移起始标志
          • 04:Extended Linear Address Record,块地址偏移
          • 05:块地址偏移起始标志
        • [HHHH… …HHHH] 数据部分
        • [CC] CRC循环冗余校验码

        详细的INTEL HEX32标准细节就不在这里解释了,网上很容易找到。Mirochip的DS70619B文档:dsPIC33E/PIC24E闪存编程规范就是一个很 好的参考。接下来我会详细讲述一下INTEL HEX32在dsPIC33/PIC24E上的具体实现,总结一下散落在多个文档中的一些零星要点。让我们从一个具体的例子开始来加深你的理解:

        :020000040108EA
        :0200000212FFBD
        :0401000090FFAA5502
        :00000001FF
        
          • 块地址偏移0108
          • 片地址偏移12FF
          • 原起始地址0100
          • 计算真实地址:0108左移16位变成0108 0000,12FF左移4位变成0001 2FF0,原起始地址0000 0100,加上偏移量后得到真实地址为:0109 30F0
          • 最终可以将这段hex解释为
            地址 数据
            010930F0 90
            010930F1 FF
            010930F2 AA
            010930F3 55
            

            值得注意的是,一旦含有“02”或者“04”数据类型的16进制代码行出现,则之后的所有行的数据地址都需要偏移,直至出现新一个“02”或者“04”,那么就需要重新计算新的偏移量。

  1. INTEL HEX32在dsPIC33E/PIC24E上的具体实现
    Microchip在INTEL HEX32的基础上增加了一些自己的规则。要想正确地解析dsPIC33E/PIC24E的hex十六进制文件,就必须深入Microchip为数众多的文档才能窥探到庐山真面目,下面就是一些汇总:

        1. dsPIC33E/PIC24E的每个指令(instruction)占用3个字节(byte)或者24位(bit),与此相对应的,用户闪存程 序存储区也是同样的3个字节宽度。这里问题就来了,标准INTEL HEX32格式中,每个数据总是4字节宽度。Microchip为了遵循此标准,编译生成的hex文件中每个指令数据也是4个字节,只不过最右边的一个字 节总是0×00,被称为“phantom byte(虚拟字节)”,顾名思义,就是没有实际作用纯粹用来充数字节。所以上面提到的BB部分除以4就是该行十六进制码中所含指令的数量。
        2. 用户闪存程序存储区的地址是以2为递增单位,这是为了照顾上面所述的3个字节宽度的指令。可以这样理解,闪存构造是以两个字节为一最小单位,3个 字节的指令将占去两个闪存地址空间,尽管有一个字节是“phantom byte”。有这个“phantom byte”也不意味着浪费了一个字节,因为这个字节在闪存里没有实现,只是为了照顾INTEL HEX32标准而凑数的。可以从Microchip的DS70609C_CN文档中得到验证“24位闪存程序存储器可被视为并排放置的两个16位空间,每 个空间都有相同的地址范围……由于闪存程序存储器只有24位宽,因此TBLRDH和TBLWTH指令能寻址闪存程序存储器中并不存在的最高字节。该字节被 称为“虚拟字节”。同时这也解释了dsPIC33EP512MU810的用户闪存存储区的地址上限为0x557EE(即十进制350,206)却只能存储 175,104(即350,206的一半)个指令了。
        3. INTEL HEX32文件中的“AAAA”部分表示的是该行数据的起始地址,但是需要除以2才是真正相对应芯片闪存的实际地址。
        4. 理解GOTO和RESET指令 Microchip编译好的Intel Hex32文件中,第二行一定是GOTO和RESET指令。该指令在芯片重置或者启动的时候被访问,告知应该从哪里开始读取用户程序。这样的其实地址为 “0”,只含有两个指令即8个字节(实际有用字节为6,2各位虚拟字节)。第一个指令总是以0×04结尾(不包括虚拟字节),表示所指向地址的低16位, 前两个字节就是改16位的地址。第二个指令总是以0×00结尾,表示所指向地址的高16位,同样的第一第二个字节就是该16位的地址。下面是一个例子:
          :0800000000a80400020000004a
          :08 0000 00 00a80400 02000000 4a
          (1)(2)  (3)(4)      (5)      (6)
          

          (1)这一行有8个字节数据
          (2)起始地位为0
          (3)类型为数据
          (4)第一个指令:00 a8 04 00(虚拟字节),可以解释为:指向低16位为0xa800的地址
          (5)第二个指令:02 00 00 00(虚拟字节),可以解释为:指向高16位为0×0002的地址
          (6)CRC循环冗余校正码
          这一行综合起来可以解释为,跳转到0x02a800地址。再来一个例子:

           :080000000002040000000000f2
          

          这一行的意思是,跳转到0×200地址。(这是一个dsPIC33FJ256GP710A芯片正常编译后的实际hex文件,是指在启动后跳向用户程 序的第一行。dsPIC33F的一个储存页为512个指令大小,0×200即跳过第一个含有GOTO/RESET以及中断向量表的储存页。不同于 dsPIC33F,我们讨论的dsPIC33E系列的储存页大小升级到了1024个指令,这个我会在后面一篇文章里提到。)