• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 18 subscribers
  • Views 755 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

SmartRF corrupting code on targed device when "Verify against hex-file"

Earl Van Wagoner
Prodigy 220 points
Other Parts Discussed in Thread: CC2540

When using SmartRF flash programmer, I attempted to "Verify against hex-file” and the code on the target device was corrupted. Anytime I try to verify after the initial programming gives the same results which includes the statement that the verify fails as well... I searched your forums and saw this, http://e2e.ti.com/support/low_power_rf/f/155/t/132428.aspx which explains why there is no verify after programming (really???, you cannot read the flash rom - or whatever - and report back to the console without going through non-volatile memory that gets corrupted??? - Hard to believe... if true, what is the point of having the "verify against hex-file" then???).

All that being said, there was no mention that the code on the target device is being altered during the verify process...

I know your question to me will be "am I using the latest stuff", etc., so "Yes", I have tried various SmartRF versions including your latest one, with multiple CC Debugger modules, again with the existing firmware as well as the latest firmware, tested with multiple hex files on multiple target devices and on every one of them, I can " erase program and verify", test the code to see if it works (which it does), then "verify against hex-file" (which fails) and then test the device immediately following the verify, and each time the device wont work until I re-program it with the exact same code as initially flashed.

Unfortunately for me, I had some prototypes that were operating a certain way and I was trying to identify which of many versions of code was installed by attempting the verify, and now that info is lost so I'll just have to start testing again, but it is more than a little disconcerting that performing a verify would obliterate the code on the target device, and again, I can reproduce this and you should be able to also...

Any thoughts?

 

 

  • 0
    TI__Genius 13620 points

    Hei Earl,

    First of all, the NVRAM region is NOT corrupted by the flash programmer. The software will update/write data to the NVRAM when the application starts running. As a consequence, if (and only if) the NVRAM region is included in the HEX file you're programming, the verification will fail if the device have had a chance to run first.

    In the case where you do the combined operation "Erase, program and verify", the programmer will NOT allow the device to run after being programmed, thus the verification will be OK. Dy doing the verification afterwards, the device have run and may have written to the NVRAM.

    The verification process DOES NOT alter the content of the flash.

    You can fix this by removing the page in the hex file covering the NVRAM area, unless, of course, there is initialized data there. Otherwise, it does not make any sense to include the NVRAM area in the HEX file in the first place(*).

    Another solution is to do the verification manually: Read out the contents of the flash and compare with the image you want to program. Should be straightforward. 

    (*) As a side not, this really depends. If you always do a complete flash erase, you don't need this. However, if you have e.g. a bootloader programmed first in flash and you don't want to lose that stuff in flash, and at the same time want to make sure the NVRAM area is completely wiped out (and you perform the "append and verify" operation with the flash programmer), it might make sense to include the NVRAM page in the HEX file. So this is actually application dependent.

  • 0 in reply to M
    Prodigy 220 points

    M,

    Thanks for giving more detail on why the "verify against hex-file" operation fails... (as I mentioned in my post, I saw the post from a TI employee that describes that...) but my real question was why (and how) is the code on the target device being altered during the separate verify process, and if the flash rom is not what is being affected, then what is happening to the soc (CC2540) that keeps it from running until it is "re-flashed"???

    Please re-read my post to see what I have already done in the way of testing, etc.

    I initially called TI tech support on this and spent some time with them until they were not able to give me any answers (Service Request # 1-936958931), and they subsequently suggested I post the question here as the TI engineers that monitor this site are more likely to have the answers needed.

    Thanks for your help...

  • 0 in reply to Earl Van Wagoner
    TI__Genius 13620 points

    So you're saying that you can perform the "erase, program, verify" operation successfully, and your application is running OK. But if you just try to do another "verify against hex file" sometime afterwards, your app stops working as it should and you need to reprogram the whole thing to get it up and running again.

    This sounds very strange. The "Verify against hex file" should not change the content of flash (where the application and NVRAM is stored), it will only read from it.

    In what way does the app fail? Any clues? How can we reproduce this here?

    Have you tried the "Read flash into hex-file" option? Does the read-back operation lead to the same problem? 

    Are you using the GUI version of the programming tool? Have you tried turning off the option "Retain IEEE address when reprogramming the chip"?