• 状态 Resolved
  • 已锁定 已锁定
  • 个回复 13 个回复
  • 名订阅用户 27 名订阅用户
  • 次查看 6700 次查看
  • 用户 0 名在线用户
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

28377D boot

user4256844
Intellectual 893 points
Other Parts Discussed in Thread: CONTROLSUITE

您好！

    当前产品中使用单个6748+多个28377D的方案，6748作为主控。平时正常时，28377D从Flash启动，升级方案为在28377的APP加入一段写flash的代码，直接通过通信接口接收APP固件数据，自行写入Flash进行升级；在有特殊情况出现（升级过程中突然断电等）导致28377D的Flash固件无法启动时，6748将28377D的启动变为从机启动，通过SCI等接口，下载一个boot程序到28377D，boot程序可进行基本的错误检查，并接收6748发过来的App固件，重新烧写到内部Flash.

     请问，此方案是否可行，硬件上如何实现？是否有其他更好的升级方案，既能更新固件，又能避免特殊情况下28377D不能启动？

  • 0
    Intellectual 893 points

    刚想了下，在电路上直接设置成slave boot，用SCI接口来引导28377D启动，主机发送一个boot程序给28377D，boot中检查固件是否需要更新，如果需要，从主机接收固件数据，写入flash，问题是在启动app时，由于28377D可以直接在flash上执行代码，能否直接由boot跳转到app的地始地址开始执行，而跳过引导app的过程？

  • 0 回复 user4256844
    TI__Mastermind 21365 points

    不需要那么复杂，你只要保留一个区(sector A)来实现程序升级就可以，不使用TI通过GPIO引导来实现的BOOT。

    这个区的代码除了通信代码和用于Flash操作相关的FlashAPI代码(需要copy到RAM上运行)，还需要在此之前加入一个判断即可 - 根据之前是否在烧录且失败和是否烧录完成决定程序在自己编写的BOOT区继续运行，还是跳转到APP。

    将程序的入口地址设定到这个区，这样每次上电以后，程序都从这里开始执行，既解决了升级过程中掉电的问题，也解决了需要自动从Flash启动的问题。

    在APP正常运行过程中需要升级时，自定义一个通信命令，接收到该命令就跳转到这个区，一样去执行BOOT代码即可。

  • 0 回复 10#
    Intellectual 893 points

    这个模式可以认为是second boot + app的方式吧

    如果考虑到产品出厂时不需要烧写出厂固件，是不是就得选WAIT BOOT方式

    不一定要自动从Flash启动，其实我一开始的意思是能不能把boot省略，也能实现固件的100%安全升级

    如果用我后来说的那种 用WAIT BOOT方式，下载一个boot到RAM，执行更新或跳转的操作，其实跟你说的启动方式是一样的，只不过是一个当主机，自行启动，一个当从机，被引导启动

  • 0 回复 user4256844
    TI__Mastermind 21365 points

    通过上位机传输BOOT到F28377D当然也可以，而且更方便，不需要出厂时烧写该BOOT，可以节省FLASH空间。

    实现原理上，还是跟上面描述的差不多。

  • 0 回复 10#
    Intellectual 893 points

    您好！

    我看到官方是给了串口上位机烧写28377D的方案的，是不是采用的就是这个先下载boot到28377，再用boot烧写程序的方法？如果有，boot工程源代码和上位机源代码是否有提供？ 我现在需要用6748来充当这个主机的功能，需要改写。

  • 0 回复 user4256844
    TI__Mastermind 21365 points

    是的，这些源代码本来就是公开的，你可以下载controsuite后在下面路径查找：

    上位机：C:\ti\controlSUITE\device_support\~Utilities\serial_flash_programmer\serial_flash_programmer

    BOOT：C:\ti\controlSUITE\device_support\F2837xD\v190\F2837xD_examples_Dual文件夹下的F2837xD_sci_flash_kernels工程

  • 0 回复 10#
    Intellectual 893 points

    还有个问题，现在是有多个28377D的数字板作为从机，而SCI只能一对一，如果主机需要依次启动这些28377D的板子，用CAN接口能否实现？如果用CAN发送boot，是不是需要修改28377的OTP区？

  • 0 回复 user4256844
    TI__Mastermind 21365 points

    是的，可以实现，确实需要更改OTP以使它从CAN BOOT，同时要注意，以后每次它都是从CAN进行BOOT，因为它必须通过Get Mode引导进来，而Get Mode默认引导到Flash，通过修改OTP后，这个行为就被改变且固定为CAN BOOT了。

  • 0 回复 10#
    Intellectual 893 points

    把多个从机的SCIA接收线都连接到主机的TXD线上，就是不管从机的响应，这样是否可行？

  • 0 回复 user4256844
    TI__Mastermind 21365 points

    我不确定，可能不行。

  • 0 回复 10#
    Intellectual 893 points

    OTP区是怎么划分的？只能编程一次是指每个地址编程一次，还是整个区要一次性编程好？

  • 0 回复 user4256844
    TI__Mastermind 21365 points

    是寄存器，不是OTP区，直接在DCSM对应的文件里写入需要的值，编译后烧录就可以了。每个地址的每个位可以编程一次。

    参考controlsuite下(路径：C:\ti\controlSUITE\device_support\F2837xD\v190\F2837xD_examples_Cpu1)的例程blinky_with_DCSM，添加DCSM_Z1_ZoneSelectBlock.asm文件，然后配置BOOTCTRL寄存器，其它部分是配置密码相关的。

  • 0 回复 10#
    Intellectual 293 points
    主板上的SCI使用的引脚是GPIO28和GPIO29，资料上显示需要设置OTP_KEY设置为0x5A；BMODE Value设置为0x81。我在工程中的DCSM_Z1_ZoneSelectBlock.asm中将Z1-BOOTCTRL改为0x0000815A；（其他的寄存器未设置都是0xFFFFFFF）。另外在工程属性里的Debug->Flash Settings里面的OTPBOOTCTRL里面的Z1-BOOTCTRL也改为0x0000815A。然后通过仿真器下载程序。下载完后再短接BOOT1，通过串口下载程序，始终失败。请问一下，我的设置哪里出问题了吗？正确的做法是什么样的？