MSP430FR5962: programming consultation

Hi Tsai,

Could you elaborate on how you are using these functions, such as what interface you use to read data from the device, and where these functions are running?

Currently, I am not clear on what these functions are doing, or where you found them, so I could not tell you what they execute or why the data changes after multiple reads.

Hi Dylan,

Thanks for your reply

I used the JTAG interface to program this chip with my own tool, following the programming steps referenced from the source code (slau320aj.zip). During testing, I noticed that when using ReadMem, the readback data always matches the programmed data, but with ReadMemQuick, it only matches at the beginning, and after multiple reads, the data changes unexpectedly. Could this behavior indicate that ReadMem is more reliable for verification? Do you recommend using ReadMem over ReadMemQuick?

So you are using a custom JTAG tool for this? Have you tried the same on a different JTAG tool, such as one of the ones mentioned in the SLAU320 document?

I can see that the description of the function that you mention is just to initiate a read, and then return the values that it reads out, in the function flow I do not see any write occurring.

I'd recommend that you try probing the signal to make sure that the communication between your tool and the device are what you expect, and then if so I would also recommend that you try double checking the data returned by the readMemQuick function to see if it is actually changing in memory. 

Let me know what you are able to find here.

Hi Dylan,

Thanks again for your reply! 

I wrote to the flash before reading, and all functions were implemented by following the SLAU320 source code, and I have confirmed that JTAG communication is functioning normally. I also have the MSP430-FET Flash Emulation Tool, which I am using to assist in verification.

The data returned by the readMemQuick function actually changes in memory, but this issue does not occur when using the readMem function.

Could this behavior indicate that readMem is more reliable for verification? Would you recommend using readMem instead of readMemQuick?

Thanks for your assistance!

Hi Tsai,

I have not been able to review the source code for it, but yes it sounds like using readMemQuick has some bug that is changing the memory. Nothing in the description indicates that it should be changing your memory. 

As we do not plan to offer updates to this tool, my recommendation would be to avoid using readMemQuick, or if you are editing the source code you could attempt to fix it yourself, but considering that you have a working function for this, that activity may not be worth your time.

Let me know if you do have further questions on this topic.

Hi Dylan,

Thanks again for your reply! 

After performing the erase and blank check operations, I wrote to the main flash and read it back using the ReadMemQuick function.

All operations were performed using functions from the SLAU320 source code (not just the read function).

I printed the returned data in the output window, and you can see that the data changes after several read attempts.

The first image shows the correct data read from the chip using the ReadMemQuick function immediately after programming. However, after reading multiple times with ReadMemQuick, the data is altered, as shown in the second image. Once the data is changed, it is no longer possible to read the correct values.

Hi Tsai,

I would recommend that you just use the ReadMem function here instead of the ReadMemQuick function that appears to be broken. Considering that you are using a custom tool, you may need to re evaluate the exact operations performing the function if you'd prefer to fix it.

Hi Dylan,

Is there Any updates on my question ?

Thanks a lot