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.

MSP430FR5728: ReadMemQuick function issue

Part Number: MSP430FR5728
Other Parts Discussed in Thread: MSP430FR5739, MSP430FR5730

Hello,

We have noticed that some batches of MSP430FR5728IRGER have some issue with command ReadMemQuick_430Xv2 (in JTAG mode). The issue is in altering the content of "MainMemory" when read more than 200h bytes from addresses above c200h (started by command ReadMemQuick). In such a case the data in MainMemory area becomes to be randomly altered after reading ...

We also noticed that devices marked:

430FR

5728

TI 84I

A3J7 J

aren't affected by this issue and devices marked:

430FR

5728

TI 85I

CGTJ J

are!

Could you explain me this behavior? What is wrong. How we can workaround this problem?

Best regards,

Frantisek

  • Hello Frantisek,

    Regarding the device markings, "TI 841 A3J7" and "TI 851 CGTJ" are lot codes and the last letter "J" is the die revision and are described in the errata document.

     I have contacted our development tools team to have one of our experts can help with this.

  • Hello Frantisek,

    Our tools team has confirmed that ReadMem_430Xv2 or ReadMemQuickXv2 will work the same on this device.
    So to better understand your specific issue, they asked a couple of questions regarding your programming setup.

    1. Are you using 4-wire JTAG mode?
    2. What is the TCK frequency?
    3. What is the TCK clock frequency during a CPU read?
    4. Do you have any caps or resistors on any of the JTAG lines?
    5. Are you taking care of the precious IFCLK state when generating TCLKs?
  • Hello Dennis,

    >1. Are you using 4-wire JTAG mode?

    Yes, we use 4-wire JTAG mode.

     >2. What is the TCK frequency?

    TCK frequency is 1Mhz.

     >3. What is the TCK clock frequency during a CPU read?

    TCK frequency during a CPU read is 1Mhz.

    We have got problem only when read whole device memory using ReadMemQiuck_430Xv2 function.

     >4. Do you have any caps or resistors on any of the JTAG lines?

    No.

     >5. Are you taking care of the precious IFCLK state when generating TCLKs?

    I don't understand what shall be "IFCLK state".

    Other devices MSP430FR5730, MSP430FR5739 don't have problem, the reading of whole memory space is without any errors.

    Best regards,

    Frantisek

  • Hello Frantisek,

    Sorry for the delay. I'm still waiting for a response from our tools team based on your answers.
  • Hello Frantisek,

    Our tools team is suggesting the following:

    "For all other FRAM devices the program counter is set into the a JMP$ instruction inside the test memory at address 0x4.

    FR57xx JTAG id is 91.  In this case the PC is not set to the JMP$ instruction.

    This was done because not all JTAG ID91 device have this test memory.  But FR57xx has this test memory.

    I would suggest to change the following line in the code accordingly."

    // Code with specified modification

    void ReadMemQuick_430Xv2(unsigned long StartAddr, unsigned long Length, word *DataArray)

    {

       unsigned long i, lPc = 0;

       // Set PC to 'safe' address

       if (IR_Shift(IR_CNTRL_SIG_CAPTURE) == JTAG_ID99 || IR_Shift(IR_CNTRL_SIG_CAPTURE) == JTAG_ID91)

       {

           lPc = 0x00000004;

       }

       SetPC_430Xv2(StartAddr);

       SetTCLK();

       IR_Shift(IR_CNTRL_SIG_16BIT);

       DR_Shift16(0x0501);

       IR_Shift(IR_ADDR_CAPTURE);

       IR_Shift(IR_DATA_QUICK);

       for (i = 0; i < Length; i++)

       {

           SetTCLK();

           ClrTCLK();

           *DataArray++   = DR_Shift16(0);  // Read data from memory.        

       }

       if(lPc)

       {

           SetPC_430Xv2(lPc);

       }    

       SetTCLK();

    }

    Let me know if this does not fix your problem.

  • Hello Dennis,

    Your recommendation didn't help, because IPC setting is done after reading the memory. In our case after the memory is reprogrammed. If we read the memory step-by -step in 200h bytes, then doesn't matter how IPC is set.

    Let me note that for other FRxxxx device we don't see such issue.

    Frantisek

  • Hello Dennis,

    We have used Replicator430FR from Slau320 documentation. But it doesn't mention nothing about reading memory in 200h bytes blocks.

    Frantisek

  • Hello Frantisek,

    Are you still seeing this issue?
    How do you confirm that the main code memory is altered after the ReadMem_430Xv2Quick()?
    Do you perform a verify after programming first before reading memory?
    In the area in main code that gets altered, are these locations random or repeatable?
  • Hello Dennis,

    Yes, we're still seeing this issue. But we found out work around: we issue command ReadMem_430Xv2Quick() and then read no more than 200h bytes. For reading whole Flash we divided reading to reads of consecutive blocks with lengths 200h bytes or less, reading of these blocks is started by ReadMem_430Xv2Quick() command. 

    How do you confirm that the main code memory is altered after the ReadMem_430Xv2Quick()

    If the memory is read by 200h bytes blocks, we read correct data. Once we read memory en-bloc, then data become to be altered, after this we always read bad data.

    Do you perform a verify after programming first before reading memory?

    Yes, we do.

    In the area in main code that gets altered, are these locations random or repeatable?

    Random.

    Best regards,

    Frantisek

  •  Hello Frantisek,

    Ok, I'm glad you have a workaround for your application and thank you for bringing this issue to our attention.

    I have filed this issue in our bug tracking tool and it will be addressed in the next release of the Replicator software.

    Unfortunately, I don't know when this will happen so what I am going to do is close this issue for now and would recommend checking the Replicator release notes every so often to see if the next release has been posted.

  • Hello Frantisek,

    Our development tools team has something else for you to try:

    ======================================================
    Write 0x3FFF to address 0x4, 0x6 and 0x8 before running read mem quick and setting the PC to 0x4.

    void ReadMemQuick_430Xv2(unsigned long StartAddr, unsigned long Length, word *DataArray)
    {
    unsigned long i, lPc = 0;

    WriteMem_430Xv2(F_WORD, 0x4, 0x3FFF);
    WriteMem_430Xv2(F_WORD, 0x6, 0x3FFF);
    WriteMem_430Xv2(F_WORD, 0x8, 0x3FFF);

    // Set PC to 'safe' address
    ======================================================

    Let me now if this helps.
  • Hello Dennis,

    It didn't help, I'm sorry. Anyway once we have got a workaround, we can close this ticket I think.

    Thank you very much for your effort.

    Best regards,

    Frantisek

  • Ok, thanks for your patience with trying to get this resolved.
    As mentioned, I'll go ahead and close this issue for now.
    When I get notified on the fix and expected update release, I'll re-open and post that information here.