Dears,
I have update .csv file to chip via GUI and it's showing successfully.
But when I want to record this version checksum seems like something wrong because the number was 0xFFFFFFFF.
Why and how to created the correct checksum?
BR
Eric
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.
Dears,
I have update .csv file to chip via GUI and it's showing successfully.
But when I want to record this version checksum seems like something wrong because the number was 0xFFFFFFFF.
Why and how to created the correct checksum?
BR
Eric
Hi
Please ignore the checksum shown in the snapshot, it is not useful.
If you want to confirm the programming is successful or not, please refer section 3.2 of www.ti.com/.../slua815b.pdf.
if you want to compare the data flash hex file, please refer section 3.3 of www.ti.com/.../slua815b.pdf.
Regards
yihe
Hi Yihe,
Not understand.
First, if Hardcoded Parms didn't red light, that means successful programming?
Second, section 3.3 not write how to compare data flash hex file.
BR
Eric
Hello
If HARDCODE_PARMS is not set, it means that device has a valid configuration in place. if you have set the different MFR_REVISION for each configuration, your can read the back the MFR_REVISION to confirm whether this is a new or older configuration.
Data flash hex is a text file, you can export the file from GUI and compare the files using any edit tool which support compare function.
Please refer below video to learn how to export file;
Regards
Yihe
Hello
Do you want to compare the data flash data from the chip with the csv file? you can read the MFR_REVSION as mentioned in the early post, it is the quickest way to confirm whether the data matches or not?
for the csv file, it can do the compare but since it also contain the fault/peak log which will be different cross the devices. it is not a good way to do.
You can refer section 3.3 of
Regards
Yihe
Hi Yihe,
So Ti recommend to use data flash file to export and import to device? not .csv file?
BR
Eric
Hello
The read value 0x30 0x31 0x6b is correct for "01". 0x30 is a ASCII code for value 0, 0x31 is the ASCII code for value 1, 0x6b is the PEC data.
When you write the 0x01, they are converted to the text via ASCII code, so is 0x001.
Regards
Yihe
Hi Yihe,
I find PEC data means Packet Error Checking?
If yes, the PEC data will change according to value by my setting?
If I want to make sure version when manufacture, can I ignore PEC data? or should I check including PEC data?
BR
Eric
Hello
Yes, PEC is package error checking which behaves like a checksum to ensure that the data is good during the transaction. It changes up to the value.
It is up to your system. if the i2c signal is good and there is no any integrity issue on the i2c bus, you can ignore PEC.
Regards
Yihe
Hi Yihe,
If I want to make sure I2C signal is good, that means I must check PEC data to prevent any issue?
BR
Eric
Hi
PEC is a CRC8 checksum. It is to ensure that the received data matches transmitted data .
Your software team has to implement the PEC check to verify the data.
It is good to have it to ensure a reliable communication. but it is application's call to adopt it or not.
Regards
Yihe
Hi Yihe,
OK, I understood.
One more question, if I programming via socket from development board, chip still create PEC data?
BR
Eric