• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 52 subscribers
  • Views 144 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.

CC2745R10-Q1: CC2745 Script Programming – Readback Data Mismatch

Harry Wu
Prodigy 60 points

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

Hi TI Engineer,

After programming the CC2745 using the official TI script(uniscript.py)with the XDS110 , the device functions normally.
However, when I read back the IC contents, I noticed that some data in the CCFG region differ from the programmed file.

  • At address 0x4E02002C, the read value is 0x00, while the file value is 0x01.

  • The range 0x4E020750 – 0x4E0207CF appears to have been skipped during programming.

I would like to confirm whether these behaviors are expected when using the official script, or if there are any special handling requirements for these regions.

Another question — I noticed that the official programming script first programs the HSM, and then the .hex and .bin files.
In my setup using Uniflash, I first program the .hex and .bin files and then update the HSM.
I’d like to confirm whether these two sequences are functionally equivalent, or if the order affects the result.

Best regards,
Harry

  • 0
    TI__Expert 8825 points

    Hello Harry, 

    I am assigning the thread to my colleague who worked on uniscript.py. 

    To clear up the last question, you are correct that in uniflash, you flash the .hex or .bin project file before flashing the HSM firmware. The uniscript.py script flashes an intermediary .hex/.bin image before flashing the HSM. Then the customer provided .hex/bin image will be flashed to the device. The sequences are functionally equivalent. 

    Thanks,

    Isaac

  • 0 in reply to Isaac Larson
    TI__Genius 15995 points

    Hi Harry,

    0x4E02002C corresponds to the writeEraseProt bit of the CCFG. This value depends on whether you want writeEraseProtection on the CCFG and it should correspond to the value in the .hex file that you are flashing.

    0x4E020750 -> 0x4E0207CF corresponds to the userRecord section of the CCFG and is defined by you. It has no effect on validity of the CCFG.

    Best,

    Nima Behmanesh

  • 0 in reply to Nima
    Prodigy 60 points

    Hi Nima,

    Thank you for your reply. I now understand the userRecord section.
    However, I noticed that the writeEraseProt bit value I read back is different from the value in the programming file.
    Is it possible that the script modifies this bit during programming?

    Also, could you please explain the actual function of the writeEraseProt bit?
    I’m concerned that it might affect the device’s behavior.

    Thanks again for your help.

    Best regards,
    Harry