CC2541在OAD时，crc和crc的值

1、CC2541在OAD时，crc[0]和crc[1]的值是由谁来确定的？是IAR编译过程产生的吗？是怎么确定的？

2、我看了下IAR编译生成的.bin文件和.hex文件，在地址0x0800（image_a）及0x4000（image_b）处生成的crc[0]不等于0xFFFF，但是crc[1]=0xFFFF，这样在将下载文件写入2541后会不会不运行image_A或image_B？

实际上第一次将image_a下载进2541后，在通过flash programmer将flash读出来生成的.hex文件中发现0x8000处的crc[1]变成了与crc[0]相等，这个的原因我知道是在BIM程序中（下面红色的代码）导致发生了这个变化。

if ((crc[0] != 0xFFFF) && (crc[0] != 0x0000))
{
if (crc[0] == crc[1])
{
JumpToImageAorB = 0;
// Simulate a reset for the Application code by an absolute jump to the expected INTVEC addr.
asm("LJMP 0x0830");
HAL_SYSTEM_RESET(); // Should not get here.
}
else if (crc[1] == 0xFFFF) // If first run of an image that was physically downloaded.
{
crcCheck(BIM_IMG_A_PAGE, crc);
}
}

但是我再通过sensertag将image_B空中升级到2541后，却发现image_b根本不能运行，还是跑的image_a。再将2541的flash读出来发现0x4000处的crc[1]仍然为0xFFFF，与crc[0]不相等，这与.bin文件中的数据是一致的。那这样的话，根本没法通过OAD更新，因为程序根本进不了image_b，这是为什么？为什么0x4000的crc仍然与.bin文件中的一致？OAD空中升级过程中，sensortag对下发给2541的.bin文件不做任何处理吗？

3、我如果直接将.bin文件中的crc[1]改成与crc[0]相等，这样通过OAD后，程序可以进入image_b，这样是不是就表明程序OAD成功了？我这样直接改动.bin文件会有什么问题吗？这个时候再将flash从2541里读出来，发现0x4000的crc[1]=crc[0]。

4、接着第3往下走，如果这个时候我再更新image_a，如果不将a的.bin文件中的crc[1]改成等于crc[0]，那OAD后程序不会进入image_a而是还在b中，这个时候读出flash，0x0800处的crc[1]与.bin文件一致，确实不等于crc[0]，而0x4000处的crc[0]=crc[1]；如果我将a的.bin文件中的crc[1]改成等于crc[0]，那OAD后2541程序则会进入image_a，这个时候读出flash却发现0x4000处的crc[0]=0x0000，与crc[1]不再相等了，这是怎么回事？是谁修改的这里的crc[0]？是sensortag还是BIM程序呢？

以上4个问题快把我弄疯了，现在的情况是一直无法通过正常的办法OAD成功，只有修改.bin文件才可以。望不吝赐教，非常感谢。

 请问，你这个问题解决了吗