• State
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 52 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TMS320F280049C-Q1: programming issue in Uniflash version 8.0.0

Johnny Chen
Expert 4960 points
Part Number: TMS320F280049C-Q1
Other Parts Discussed in Thread: UNIFLASH

Tool/software:

Hi Champ,

I am asking for my customer.

They are using Uniflash version 8.0.0 to program F280049C-Q1.

Recently, they receive factory site feedbacks there are 8 units (total 3000 units) programmed with the same code. Dumping these 8 units memory content, there are few data different from the good programmed unit (the wrong data address seems to be random in these 8 units), then these 8 units MCU couldn't work properly because of the wrong data.

They use Command Line Interface to do the load program and verify, the failed 8 units didn't show any ERROR message after programming in the log. But dumping the failed unit memory, we do see there is some difference compared with good unit.

Left one is Good Sample memory vs right one is Failed sample memory, dumping from Flash Bank0 0x80000-0x8FFFF

(1). If Uniflash has an error during the programming process, will the load image process continue? or it will stop immediately ? 

(2). Would the expert consider those unexpected data on failed unit is because of Uniflash programming issue ? Have the expert ever seen such issue ? Showing load successfully, but with different data memory. 

(3). Customer export the flash Bank0 0x80000-0x8FFFF from Uniflash, the length should be FFFF. However, from hex view, it is calculated with 0x20045. Any misconfiguration ? 

(4). Does the expert see any wrong with the Command Line called by customer?

Thanks for the support.

Regards,

Johnny

  • 0
    TI__Genius 14065 points

    Hi Johnny,

    >If Uniflash has an error during the programming process, will the load image process continue? or it will stop immediately ? 

    The process should stop if a programming error has been encountered. Are we able to capture the CLI statements during the process?

    >Would the expert consider those unexpected data on failed unit is because of Uniflash programming issue? Have the expert ever seen such issue? Showing load successfully, but with different data memory.

    If many other units are unaffected, it is doubtful to be due to UniFlash programming itself. Are these units able to be erased after failure? If not, this might be due to Uncorrectable ECC Error.

    >Customer export the flash Bank0 0x80000-0x8FFFF from Uniflash, the length should be FFFF. However, from hex view, it is calculated with 0x20045. Any misconfiguration?

    This hex length seems incorrect, yet this is a generated .out file length. Is this the same for a generated TI-TXT file?

    >Does the expert see any wrong with the Command Line called by customer?

    Nothing seems unusual with the CLI line given.

    Thanks and regards,

    Charles

  • 0 in reply to Charles Roberson
    TI__Expert 4960 points

    Hi Charles,

    Thanks for your input. 

    Charles Roberson said:
    Are these units able to be erased after failure? If not, this might be due to Uncorrectable ECC Error.

    Able to be erased after failure. Re-flashing the unit, then the code works properly as good sample.

    Is there a specific CLI just for doing verifying ? From the uniflash_quick_start_guide.html, it seems -v must go after with flashing. Is there a command for specifically verifying memory contents without flashing ?

    Thanks and regards,

    Johnny

  • 0 in reply to Johnny Chen
    TI__Expert 4960 points

    Hi Charles,

    Adding more input after today on-site support.

    Have checked the bits of RESC and NMISHDFLG register with JTAG, no abnormal events happening to have the bits raised, eliminate uncorrectable ECC Error possibility here.

    Also, we have found a command line for just verify w/o flashing, and it seems it's workable. Removing -f, just have -e then -v, then it could verify w/o flashing. I would offline send you the console window, confidential not to post here.

    Would you kindly help reconfirm is just verify command line work properly ? If yes, then we should remove the words after flashing in my last reply -v screenshot ?

    Thanks for the support.

    Regards,

    Johnny

  • 0 in reply to Johnny Chen
    TI__Genius 14065 points

    Hi Johnny,

    Yes, removing the "-f" argument should prevent the device from being flashed and the "-v" argument will carry out the verification for the given .out file.

    Thanks and regards,

    Charles