TI中文支持网大家好，我们的程序分为两个工程，一个是自己写的应用程序，另一部分是bootloader程序（这部分应该是TI的代码，示例见附件），在串口烧录hex文件时，需要将bootloader的hex复制到应用程序hex的末尾，合成以后再烧录，后续才可以用CAN通讯进行烧录程序（mot16文件）。我的疑问是：
1.bootloader的main函数的调用流程是怎么样的？即什么时候执行，如何触发？
2.bootloader的main函数最后会通过LB 0x300002跳转到应用程序，那么从bootloader函数的末尾到应用函数的main函数之间，是怎么跳转的，有哪些步骤？
3.我提到的bootloader与Boot Rom中的boot启动（即通过IO口选择启动方式后通过串口或CAN或直接flash启动）有什么关系？因为我的应用程序中会周期性执行一个函数，当接收到上位机发送的CAN烧录命令后，直接进入死循环等待看门狗复位，复位后应该会经过Boot Rom的boot启动，那么这个boot启动（即IO口选择为CAN启动）和我提到的bootloader函数有什么关系呢？
麻烦大家帮我看看，谢谢大家了！图片.docx
user4612577：
我感觉bootloader程序就是个二次引导，boot从flash启动后会先执行bootloader程序，然后再跳转到应用程序。而我在boot rom手册中看到，当boot的模式选择为flash启动时，程序会直接跳到0x33FFF6，而这个地址是code_start代码的起始地址，但问题是：
bootloader和我的应用程序中，code_start代码在CMD文件中均放在了0x33FFF6起始的两个字里，所以我的问题时，当boot从flash启动并跳转到0x33FFF6时，为什么执行的是bootloader的code_start呢？
,
user4612577：
bootloader程序执行完后会跳转到应用程序的函数flash_start（在其他地址声明，与code_start作用一样），最后跳转到应用程序的main函数中。也就是说，如果是合成后的程序，则应用程序中的code_start代码是不执行的，那么我就尝试将应用程序中的code_start代码以及0x33FFF6这段空间的声明屏蔽。等于说boot从flash启动后，只能跳转到bootloader的code_start中。
按照我的想法，将合成后的hex烧录进DSP后，上电发现不能正常执行main。。。但是继续通过CAN通讯将应用程序的mot16文件（跟hex同一批次编译出的）烧录后，就可以正常运行了。。。感觉很费解
,
user4612577：
没人回答吗
,
Green Deng：
你好，问题1、2可以参考这个文档：www.ti.com/…/sprabv4d.pdf
问题3，CAN boot运行CAN bootloader引导程序，该程序接受HEX应用程序并将其加载到RAM。 Flash boot不是bootloader引导程序，它只会引导设备并跳转到Flash中的特定内存地址。
,
user4612577：
你好，我现在大概明白了我这个bootloader程序（以下称为底层程序）是基于boot rom中的bootloader的二次boot。
（1）一次boot从flash启动后，程序会跳转到0x33FFF6这个地址执行底层程序的code_start函数，然后执行底层程序的main函数。
（2）底层程序的main函数执行完后会跳转到0x300002，这个地址是一段汇编代码flash_start（作用于code_start一样，只是名字不一样），最终执行应用程序的main函数。
我还有个问题想请教：
（1）应用函数本身有个code_start，然后我又定义了个flash_start，这两个函数的作用一样，都是调用c_int00，最终执行main函数。但我通过二次引导时，应用函数的code_start是不执行的，只执行flash_start，那么我是否可以将应用程序的code_start删除？
（2）我现在将code_start删除后，将底层hex放在应用程序hex后面，合成一个hex。通过串口烧录进dsp后，发现不能正常运行到main函数。接着我又通过二次引导的方式通过CAN将应用程序的mot16文件（与这个hex是同一批次编译出的，即没有code_start函数）烧录进dsp，发现可以正常运行了，为什么会这样呢？
,
Green Deng：
1、是的，只要你调用c_int00，就可以了。
2、确保你的flash_start或code_start在链接器中正确设置到入口地址，或者你得提供更多的细节。
,
user4612577：
你好，针对你说的第二点我不是很理解，另外我需要提供哪些细节呢？
