TI中文支持网Part Number:CC2530Other Parts Discussed in Thread: Z-STACK
诸位大佬好，
先说需求：通过串口更新CC2530的固件，当前协议栈版本2.5.1a，计划是实现上位机对Z STACK 3.0.2与2.5.1a的自由切换
进度：参照文档“Serial Boot Loader for CC2530”，使用SerialBootTool成功实现了用串口写入固件的功能。且通过flash programmer二次确认数据写入没有问题。
问题点：原本能正常工作的程序，通过上述方案写入芯片之后，发现芯片无法正常工作（以ROUTER为例，发现其上电之后无法正常入网。）
我现在能确定程序是跳转成功的，已经从BOOT跳转至APP,但APP运行不正常。
我自认为是严格参照文档去修改的，有没有相似案例一起探讨下？是不是除了程序偏移，还有其他需要设置偏移量的？
此外，
想问下通过上述文档生成的hex，在没有拼接前段BOOT的情况下，直接用flash programmer烧入到芯片里，能正常工作吗？
shen fei：
修正下问题描述：通过在线仿真发现程序卡在"HAL_BOARD_INIT"
既trun off interrupts之后，就不运行了
,
Nick Sun：
您好，
感谢您的对TI产品的关注！为更加有效地解决您的问题，我需要多一些时间查看这个问题，稍后会为您解答。
,
Nick Sun：
您好，
根据描述，串行引导加载程序设计似乎按预期运行。您是否评估了没有引导加载程序的默认 Z-Stack 3.0.2 示例？您是尝试重新加入 Zigbee 3.0 网络还是尝试重新加入 2.5.1a 网络？
由于安全不兼容，后者将无法实现。使用相同的 Zigbee 协议版本时，升级后重新加入是最有可能的。从我们的角度来看，HAL_Board_init 不会关闭中断，因此我们也不确定程序在哪里被卡住。您能否提供代码片段并指出您认为代码冻结的确切行？我建议在两个版本上都保留闪存串行引导加载程序，因为引导加载程序无法擦除自身并支持更多的串行固件更改选项。
原文如下：Based on the description it appears that the Serial Boot Loader design is operating as intended. Has the customer evaluated a default Z-Stack 3.0.2 example without the Boot Loader? Are they attempting a fresh join to a Zigbee 3.0 network or trying to rejoin a 2.5.1a network? The latter will not be possible because of security incompatibility. Rejoins after upgrades are most possible when using the same Zigbee protocol version. From my perspective, HAL_BOARD_INIT does not turn off interrupts so I am not certain where their program is stuck. Can they provide code snippets and point to the exact line where they believe the code freezes? I recommend retaining the flash Serial Boot Loader on both versions, as the Boot Loader cannot erase itself and to support further serial firmware change options.
,
shen fei：
抱歉，前段时间个人原因项目停了一段时间，
今天又试了下，疑似是新协议栈（Z-stack3.0.2）里面附带的Bootload工程不适配对Z stack2.5.1a的更新？
我使用3.0.2的Bootlaod通过SBL升级了3.0.2下生成的GenericApp.bin，初步看来是正常的
我又使用3.0.2的Bootlaod通过SBL升级了2.5.1a下生成的GenericApp.bin，能更新成功，且能跳转至应用程序，但应用程序无法正常运行
3.0.2下的bootload是否如上述测试结果，不适用对2.5.1a进行SBL？
,
shen fei：
是我本地应用配置的问题，，SBL与app需要配置成一样的，感谢关注！
