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.

TMS320F2800157-Q1: Uniflash issue

Part Number: TMS320F2800157-Q1
Other Parts Discussed in Thread: UNIFLASH

Hi Champ,

Customer met verification failed   issue when use command line to program the code which with JTAG lock.     you can refer to  below picture and command :

Uniflash_Windows_64_157\ccs_base\DebugServer\bin\DSLite.exe flash -c "user_files\configs\f2800157.ccxml" -l "user_files\settings\generated.ufsettings" -s VerifyAfterProgramLoad=2 -e -f -v "user_files\images\H0P00A_NIORLEO_00d0A_B1d0D.out"

but with the same  .out file , if program in UniFlash GUI like below, will no this issue,

Could you  help check the reason?

  • Hi ,

    The verify settings between the two might be different.

    Is Verify after program enabled in Uniflash settings?

    I believe a verify (read) of the JTAGLOCK location after configuring it will lock the JTAG.  I can check with our DCSM expert after you clarify the Uniflash settings.

    Thanks and regards,

    Vamsi

  • Hi Vamsi,

    Yes, Verify after program enabled  in  Uniflash settings.

  • Hi Huihuang Chen,

    Both should behave the same way.  I can check on Wednesday when I am back in office.

    Thanks and regards,

    Vamsi

  • Both should behave the same way.

    Vamsi - one difference came to mind. Note that in UniFlash GUI, it is possible to configure UniFlash to remain connected after operation while with UniFlash CLI, this is not possible. So this has caused issues in cases where the device is locked after flash and disconnect in the CLI environment while in GUI environment since the device remains connected you can do some other action. Do you think this is the situation here?

  • Hi Vamsi, KI,

    Can BU side  try it and find the root cause?

  • Vamsi - can you confirm my hypothesis? I'm not certain this is the case.

  • Ki,

    I don't think the "remain connected" option can cause this issue.

    We need to check if there is any other verification (like the verification by debugger) is involved apart from the flash DLL initiated verify. 

    A read (verify) of the programmed JTAGLOCK location will cause the JTAG to lock permanently.  Flash DLL based verify does not read JTAG LOCK location.

    We can discuss on Thursday when I am back to office.  

    Thanks and regards,
    Vamsi

  • Hi Huihuang Chen,

    Can you ask customer to not include -v in their dslite command? 

    The -v flag invokes debugger based verification (which does not know that JTAGLOCK location should not be read).  

    Also, -v flag is not needed since the flash plugin will verify the programmed content in the flash (apart from flash state machine verify) anyways.

    Thanks and regards,

    Vamsi

  • Vamsi,

    Sorry, i don't understand you point. if -v should not used, why there are no issue with Uniflash GUI which enabled  Verify after program ?

    what command with the same function as "enabled  Verify after program" could be used to replace -v?

    Add more info. based on customer info. 

    For F28003x case , with -v flag, also didn't met this issue!

  • Hi Huihuang Chen,

    -v flag is different from "Verify after Program".

    -v flag is debugger based which has no intelligence on what fields in memory it is reading to compare against the user provided image.  It reads every location in the image.

    As you might have noticed in the GUI, "Verify after program" option would be enabled by default.  If you still want to include the flag enable for it, you can add "-s FlashVerifySetting=true" to the command.

    Thanks and regards,

    Vamsi