CC2540: The hex file generated using tool of "SmartRF Flash Programmer" doesn't work as before

Hi,

Are you able to take a .hex from before 2020, and flash that onto both PCB1 and PCB2?

Are the PCB new designs, compared to your hardware from 2020 and before?

Thanks,
Toby

Hi, Toby,

Thank you for your prompt feedback.

1. The 2020 hex file still works perfectly for both PCB1 and PCB2.  And, it is the one we are using in mass production in factory.  That means, it works for huge number of PCBs.
2. The hardware design is exactly same since Feb 2018.

Based on above 2 facts, that is why we are so confused in the problem.

Thanks.

Hi Joan,

I wonder if it could be an issue specifically with PCB2.

Is this tested on only two PCBs? Have you tested this on more than 10 PCBs?

I also recommend to simply load the test.bin onto the PCBs. Can you load test.bin onto PCB2 directly?

Thanks,
Toby

Hi, Toby,

Thank you for your feedback.

We tried more than 10 PCBs to locate the problem.  I named PCB2 to let the description easy to be understood.  The facts is, currently the hex file generated from PCB1 can only work in PCB1 but not for other all PCBs  We feel confused now because we generated a "good" hex file in and before 2020 smoothly.

The bin file can work in PCB2 perfectly.  However, we need hex file in mass production.  The efficiency of bin file in mass production is very low compared to hex file.   

Hi Joan,

So the main goal here is to use format of .hex file rather than .bin file in mass production, for efficiency.
Then I recommend to use the .hex file in the first place, when the FW is being built.
This is more efficient to do than loading a .bin, reading out the device flash into a .hex, then flashing that .hex.

The BLE projects for the CC2540 should generate .hex file in IAR.

Please refer to section "8.3.4 Linker Map File" here: https://www.ti.com/lit/pdf/swru271

There is a screenshot there which shows "SimpleBLEPeripheral.hex".

Thanks,
Toby

Hi, Toby,

Thank you for your suggestion. We will try it.  It is convenient for us if the generated hex file can be used.  

We were told that the generated hex file is not for mass production at the very beginning of the project before 2015. The only hex file could be used in mass production is the one generated from bin file and we did so for years.  It seems there must be some misunderstanding.  We used IAR8051 for the project. 

I will update the results here. 

Thank you very much. 

Hi, Toby,

The engineer check the project output file, There are only xxx.d51, xxx.map, xxx.sim files.  I paste the picture for your information. Do you use a different IDE to compile the project? Thank you very much. 

Try the suggestion here to enable building .hex file in IAR:

e2e.ti.com/.../hex-or-d51-or-more

Thank you for your suggestion. We will try.

Hi, Toby,

We tried the setting and generated the hex file successfully. However, the hex file can't work at all at the pcbs at which the bin file generated from the same project worked well.  We tested in 2 PCBs and the same case.

From the documents kept by us, it is said that the hex file generated from the IAR can be only used for debugging and the hex file for mass production should be generated from bin file.  It is a very old document and the one who wrote it has left , so we don't know why. 

I guess there is some reason that the IAR generated hex file can't be used in mass production and that why we use the method to generate the hex file from bin file. I believe this method was told by TI technical support also, maybe on-site FAE engineers. 

It is very strange for us also because we never encountered such case. 

Can you try flashing the hex file generated from an example in the SDK?
Such as Projects/ble/SimpleBLEPeripheral.

Since the hex file from 2020 still works, it could be an issue with your new FW specifically.

Can you try your steps again with some changes:

1. Download 2020_FW.bin (or 2020_FW.hex) to PCB1.
2. Use TI's software tool to read and save the data from the flash of PCB1 as a .hex file, named as test.hex
3. Erased the program on PCB2 using TI's software tool. Use the newly generated test.hex file. checked the option box of "Erase, program and verify". After programming and verification, check if PCB2 works.
4. Repeated the same procedure for PCB1 (flash test.hex), check if PCB1 works.

Hi, Toby,

Thank you for your support.  We did the procedure several times in the past months to locate the problem.

1. the 2020_fw.hex was generated from 2020_fw.bin and it works well in mass production. But the engineer who generated it has left.

2. We generated the test.hex from 2020_fw.bin ,saved as test.hex, but it doesn't work in any Pcbs other than the one on which it was generated.  Here, we are not sure of the 2020_fw.bin is the exact one but it was released with the 2020_fw.hex together to mass production engineer in 2020 .  

3. The test.hex can't work in pcb2 and other pcbs. we tested in more than 10 pcbs, 

4. The test.hex can work in pcb1.  It seems it can only work in the one on which it generated from.

We repeat above procedure in other pcbs, the results are the same. That is, the hex generated only works on the pcb on which the hex file generated. Just as my first post explained. 

Thank you very much. 

Ok, I think we can say that their is an issue in step 2, generating the test.hex from 2020_fw.bin. This generating process worked in 2020, but today it does not work.

Can you compare the hex files? Specifically, compare 1 and 2:

1. Original 2020_FW.hex
2. New test.hex generated by reading flash from device after flashing 2020_FW.hex

Let us know any differences you see.

Also, is it ok if you send me 1 and 2? This way I can try a analyze as well.
You can send me direct message on E2E for privacy.
(Currently I am trying to access a CC2540 EVM).

Hi, Toby,

Yesterday I post a clue here but it is strangely lost, that is, we found a notice in the old document. It is said it required that the bin file dosen't run before generating a "good" hex files. otherwise, the hex file can't run on other pcbs. It seems that the bin file will change the content of flash after running. However, it is very difficult to guarantee the point that the bin file doesn't run after download via U disk. 

I will send you the files to you via direct message. Thank you for your help and I am very curious about what happened and how to solve it definitely..  

Hi Joan,

Thanks for the update.

Joan Zhou said:

It is said it required that the bin file dosen't run before generating a "good" hex files. otherwise, the hex file can't run on other pcbs.

Yes, this is a helpful clue. I think we are close to solving the issue.

I did receive your direct message, and will continue the support there.
I will update on this E2E thread if there is general/helpful info.

Thanks,
Toby