• State TI Thinks Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 8 answers
  • Subscribers 20 subscribers
  • Views 376 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

CDCI6214: crc总是错误，导致无法锁定

CDCE6214-Q1: cdce6214-q1

yang fengxiao
Prodigy 20 points
Part Number: CDCE6214-Q1
Other Parts Discussed in Thread: CDCE6214

I tried manually program by C and use I2C to program CDCE6214, following the standard program sequence from datasheet, but I saw CRC is not successfully updated to 'R10'：nvmscrc。

I tried to use TICS Pro v1.7.5.7 to program by 2 method: 'Direct EEPROM ACCESS' and 'Register Content Transfer', but I saw CRC is not successfully updated to 'R10' as well.

Here is the Register Map I want to burn

HexRegisterValues_dp_good.txt 
R85	0x00550000
R84	0x00540000
R83	0x0053FF00
R82	0x005201C0
R81	0x00510004
R80	0x00500000
R79	0x004F0008
R78	0x004E0000
R77	0x004D0000
R76	0x004C0008
R75	0x004B0008
R74	0x004AA181
R73	0x00493000
R72	0x00480005
R71	0x00470000
R70	0x00460008
R69	0x0045A181
R68	0x00443000
R67	0x00430005
R66	0x00420000
R65	0x00410008
R64	0x0040A181
R63	0x003F3000
R62	0x003E0005
R61	0x003D0000
R60	0x003C0008
R59	0x003B0008
R58	0x003A502C
R57	0x00395000
R56	0x00380005
R55	0x0037001E
R54	0x00363400
R53	0x00350069
R52	0x00345000
R51	0x003340C0
R50	0x003207C0
R49	0x00310013
R48	0x003023C7
R47	0x002F03A8
R46	0x002E0000
R45	0x002D4F80
R44	0x002C0318
R43	0x002B0051
R42	0x002A0002
R41	0x00290000
R40	0x00280000
R39	0x00270000
R38	0x00260000
R37	0x00250000
R36	0x00240000
R35	0x0023005C
R34	0x00220000
R33	0x00212710
R32	0x00200000
R31	0x001F0000
R30	0x001E0064
R29	0x001D0000
R28	0x001C0000
R27	0x001B0004
R26	0x001A0000
R25	0x00190401
R24	0x00180524
R23	0x00172406
R22	0x001600A2
R21	0x00150583
R20	0x00140000
R19	0x00130000
R18	0x00120000
R17	0x001126C4
R16	0x0010921F
R15	0x000FA037
R14	0x000E0000
R13	0x000D0000
R12	0x000C0000
R11	0x000B0000
R10	0x000AC0F9
R9	0x0009C0F9
R8	0x00080001
R7	0x00070C0D
R6	0x00060BEC
R5	0x00050008
R4	0x00040000
R3	0x00030200
R2	0x00020002
R1	0x00012310
R0	0x00001000

Here is the burn procedure:

  1. In 'Raw registers' tool page:
    1. click 'Import Register Map' to load above file, confirmed all registers are the same with above file.
    2. click 'Write all registers'
  2. In 'EEPROM' tool page:
    1. select 'page1'(I confirmed HW_SW_SEL pin=1, REF_SEL pin=1)
    2. tick 'update_crc'
    3. click 'Register to EEPROM' button

Finally, I checked 'Raw registers' tool page: R14 = R9 = 0xA95B，but R10=0xE20F. I expected R10 should be the same as R9. So I checked R7=0xC2D, bit5(CRC Error)=1, meaning CRC error occured!

I tried above sequence from 2.a to 2.c again, then check R10=0xA95B, it updated!

My questions are:

  1. Why R10 didn't update to 0xA95B at my first burn?
  2. Why R10 updated correctly at my 2nd burn, especially I should repeate form 2.a to 2.c, not 1.a to 2.c(I tried repeate from 1.a to 2.c but it failed again! It happened to be successful when I try from 2.a)?
  3. If I write my own program sequence by C language, should I use below sequence?
    1. load file and write registers
    2. unlock
    3. trigger update CRC
    4. trigger commit to EEPROM
    5. write 0x3F to wr_addr, write CRC from R9 to wr_data 
    6. comfirm R9=R10
      1. if not : repeate from c. to f. until R9=10
  • 0
    TI__Genius 14760 points

    Yang,

    After performing these steps, perform a power cycle. Once doing so, read back all registers. Are the registers still the same as prior to programming, or are the values updated? Is the CRC result updated?
    Thanks,

    Kadeem

  • 0 in reply to Kadeem Samuel
    Prodigy 20 points

    Hi Kadeem:

    I tried to power cycle CDCE6214 after my 1st burn trial. Then I saw R10 is successfully updated! This is a good trial but it may not solve my problem.

    Actually we do not want to do a power cycle when burning CDCE6214 if there's possible to have another solution.

    I wanted to check R10 is successfully updated with R9 CRC value by checking R10=R9 after my burn flow. But now I know R10=R9 after a power cycle. So my question is if I already check all RW bits are equal with what I burn, can I skip check R10=R9 after I wrote CRC into EEPROM? Though CRC Error status could be raised when CDCE6214 is working on condition that my CRC write flow happens to be failed, but it won't affect CDCE6214 function right?

    I mean CRC should be updated after a power cycle. There's a low possiblity that my CRC write flow fail(like I2C link corrupt), causing CRC update fail after a power cycle, which causes CRC err always be raised when our product is normally working. But actually CRC status is not used in our product and CDCE6214 can normally work though there's a CRC error bit, right?

  • 0 in reply to yang fengxiao
    TI__Genius 14760 points

    Yang,

    The CRC is calculated at device startup, necessitating a power cycle: see below:

    You can trigger the live CRC recalculation by writing a '1' to the update_crc bit, R3[12]. 

    Thanks,

    Kadeem

  • 0 in reply to Kadeem Samuel
    Prodigy 20 points

    Hi Kadeem：

    Does the sentence you highlighted means R10 value is calculated during startup? I thought it refers to nvmlcrc, not nvmscrc.

  • 0 in reply to yang fengxiao
    TI__Genius 14760 points

    Yang,

    The stored CRC (nvmscrc) is saved at the end of EEPROM programming by the device. On startup, the live CRC (nvmlcrc) is calculated and compared to the stored CRC.

    If there is an issue on startup with these two CRCs not matching, then NVMCRCERR (R7[5]) will be a '1'.

    Thanks,

    Kadeem

  • 0 in reply to Kadeem Samuel
    Prodigy 20 points

    Hi Kadeem：

    But why we need a powercycle to check R10 successfully updated? It shall be equal to  R14 and R9 after we perform a CRC burn flow and we want to directly check R10 before we perform a powercycle. But the test result shows R10 can not be updated before the powercycle even if we use TICS Pro tool.

  • 0 in reply to yang fengxiao
    TI__Genius 14760 points

    Before EEPROM burn, R9 (Live CRC) is 0x3303:

    After EEPROM burn, R9 is 0xD848:

    No power cycle is required, issuing a '1' to the update_crc bit will update the value:

    Thanks,

    Kadeem

  • 0 in reply to Kadeem Samuel
    Prodigy 20 points

    Hi Kadeem:

    Let review the CRC check flow:

    1. On startup, CDCE6214 R7 bit5 CRC error is raised if R9(Live CRC) not equal to CRC store in EEPROM.
      1. My understanding is that R10 reflects to CRC stored in EEPROM which in other words, NVMSCRC

    So, if we want to burn CDCE6214, we should check if R9:Live CRC is successfully updated to EEPROM or not. That means we need to check R10 is equal to R9. If R10 not equal to R9 right after we burn, that means we are not sure NVMSCRC is successfully updated or not. 

    So my question is if we need a powercycle to confirm if R10 equal to R9, that causes us much trouble. If we don't perform a powercycle, we can not be sure R10 successfully updated. How do we do then?

  • 0 in reply to yang fengxiao
    TI__Genius 14760 points

    Yang,

    On startup, the value of R9 (live CRC) is generated by calculating the CRC of Bytes 0 through 62 of the EEPROM. The value of R10 (stored CRC) is loaded from Byte 63 of the EEPROM. If these do not match, then the NVMCRCERR bit (R7[5]) is set to a '1'.

    After burning the EEPROM, you can set the UPDATE_CRC bit (R3[12]) to trigger a recalculation of the live CRC without requiring a power cycle.

    Thanks,

    Kadeem

  • 0 in reply to Kadeem Samuel
    Prodigy 20 points

    Hi Kadeem：

    Do you mean if we perform a UPDATE_CRC by set this bit to trigger a recalculation on of the live CRC, TI confirms the live CRC will be successfully updated to EEPROM? By our test, we didn't see R10 updated right after we perform recalculation.

  • 0 in reply to yang fengxiao
    TI__Genius 14760 points

    Yang,

    On the part that I have on the bench right now, if I read nvmlcrc after update_crc is set to a '1'., I get the value of 41350. If I reprogram the EEPROM, with NO power cycle, only updating the CRC again, I see 7677. If I power cycle and set update_crc to a '1', I still get 7677.

    As demonstrated above, power cycle is NOT required for updating the CRC.

    Thanks,

    Kadeem

  • 0 in reply to Kadeem Samuel
    Prodigy 20 points

    Hi Kakeem：

    Is 41350 the new CRC to be programed to EEPROM or 7677? I didn't get your point. Can you try this sequence:

    1. Prepare the EEPROM an INITIAL statue: perform a update CRC, do not flush EEPROM, read R10 and confirm R10 is the same with R9.(To confirm all data calculated CRC is successfully store in EEPROM and R10 represents it)
    2. Change some register, update CRC, perform a program EEPROM.
    3. read R9 and R10, you will see R9 is a new CRC value unequal to R10(old value)
    4. perform 1 or 2 powercycle, read R10 after each powercycle, you will see R10 updated at 1st or 2nd powercycle

    Can you  try this sequence? I have always explained for step 3. that R10 need a power cycle to update by this experiment.

  • 0 in reply to yang fengxiao
    TI__Genius 14760 points

    Yang,

    I will have the rest results for this tomorrow.

    Thanks,

    Kadeem

  • 0 in reply to Kadeem Samuel
    TI__Genius 14760 points

    Yang,

    On initial power-up, nvmscrc and nvmlcrc both read as 0.

    After setting update_crc to '1', nvmscrc and nvmlcrc both read as 7677.

    I change R43 from 81 to 80. After setting update_crc to '1', nvmscrc and nvmlcrc both read as 7677. This makes sense, as the EEPROM is not yet changed. I program the EEPROM through the TICS Pro button, and nvlscrc is 14660, but nvmscrc is 7677, and nvmcrcerr is '1'.

    I power cycle, and read all registers - nvmscrc and nvmlcrc both read as 0. I set update_crc to '1', and nvmscrc and nvmlcrc both read as 14660.


    Now, for the second test, where I add the step of updating the CRC after I read R9 and R10 before doing a power cycle.

    After setting update_crc to '1', nvmscrc and nvmlcrc both read as 14660.

    I change R43 to 40. After setting update_crc to '1', nvmscrc and nvmlcrc both read as 14660. This makes sense, as the EEPROM is not yet changed. I program the EEPROM through the TICS Pro button, and nvmlcrc is 50293, but nvmscrc is 14660, and nvmcrcerr is '1'.

    After setting update_crc to '1', nvmscrc and nvmlcrc both read as 50293, and nvmcrcerr is '0'.

    I power cycle, and read all registers - nvmscrc and nvmlcrc both read as 0. I set update_crc to '1', and nvmscrc and nvmlcrc both read as 50293.

    As demonstrated in the second test, if you recalculate the CRC by setting update_crc to a '1', you can see the updated CRC value in both the nvmlcrc and nvmscrc fields matching, without any need for a power cycle.

    Thanks,

    Kadeem

  • 0 in reply to Kadeem Samuel
    Prodigy 20 points

    Hi Kadeem：

    In your 1st experiment, this is what we encountered that perform a update_crcr will cause NVMLSCRC be updated but NVMSCRC still keep the old value, even if we and you both performed a program EEPROM action, you still get NVMLCRC=14660 but NVMSCRC=7677. This is the key problem. We can't be sure if NVMSCRC successfully updated without any powercycle.

    In your 2nd test, do you mean that we need a 2nd CRC update step instead of a power cycle to make NVMSCRC be updated?

  • 0 in reply to yang fengxiao
    TI__Genius 14760 points

    Yang,

    This is correct. With the second CRC update, you see that the values are updated properly.

    Thanks,

    Kadeem