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.

How do I view device memory using CCS v5.1?

Other Parts Discussed in Thread: MSP430WARE, MSP430F5528

I canont correclty read memory using CCS v5.1  How can I do this?  Here is my setup:

Microsoft Windows XP Professional Version 2002 Service Pack 3
Dell Latitude E6410
Code Composer Studio Version 5.1.0.09000 (as seen from add/remove programs menu, "Click here for support information.")
MSP-TS430RGC64USB development kit
MSP-FET430UIF programming tool (with firmware upgraded by concent using CCS version above)
MSP430F55XX_1 code example (toggle LED)
C:\TI\msp430\MSP430ware_1_00_00_00\examples\devices\5xx_6xx\MSP430F55xx Code Examples\C\MSP430F55xx_1.c
MSP430F5528 Rev. E device used in kit

I want to read the data in this range of memory (the descriptor tag-length-value (TLV) structure):

0x1A00 start address
0x1AFF end address

 I successfully read the memory using this setup:

Microsoft Windows XP Professional Version 2002 Service Pack 3
Dell Latitude E6410
Code Composer Studio Version 4.2.4.00033
MSP-TS430RGC64USB development kit
MSP-FET430UIF programming tool (with firmware not upgraded by CCS 5.1)
MSP430F55XX_1 code example (toggle LED)
MSP430F5528 Rev. E device used in kit

I have attached the results from both CCS 5.1 and CCS 4.2.4 from the same device running the same program.  Why are the results different?  The results from CCS 4.2.4 look correct.  The results from CCS 5.1 do not.

Additinally, in CCS v5.1, I'd like to save the memory in a format of one byte per line.  I can do this in CCS 4.2.4.  See the attached memory dump.  I dont know how to do this using CCS v5.1  Please advise.

Until I can do this, I cannot migrate from CCS 4.2.4 and I will not recommend customers to fully migrate ether.

6886.F5528withKit.zip

  • Hi Jason,

    I am wondering whether you are seeing one of our known bugs.

    When long variables are stored in registers they are stored in a register pairs, but the debug information generated is incorrect, so only one register's contents (lower bits) is written to expressions view. The bug # for this is SDSCM00042242. Once again the bug is in incorrect debug information being generated, so the CCS displays will be affected. However the code produced by the compiler itself should be correct and should execute properly.

    Do you think this could explain things? Is the code itself working as expected?

    I will look into the one byte per line and get back to you as soon as I can on how/if it is supported in the latest release.

    Best Regards,
    Lisa

  • HI Jason,

    I have managed to track down the following way to do what you wish in v5. 

    This still works in v5 by selecting the Addressable Unit format on the second page of the wizard  . However, the file extension has to be .dat. Otherwise, .txt will be treated as the RAW format.

    Please try this and keep us informed.  Also, do you think you are affected by the bug I directed you to?

    Best Regards,
    Lisa

  • Hi Jason,

    I thought I would check whether the tip was helpful regarding the "Addressable Unit".

    Best Regards,
    Lisa

  • Hi Jason,

    also check whether this bug might be affecting you

    SDSCM00042608

    It seems there might be a bug with 55xx devices.


    CHeers,

    Lisa

  • Lisa TI said:
    This still works in v5 by selecting the Addressable Unit format on the second page of the wizard  . However, the file extension has to be .dat. Otherwise, .txt will be treated as the RAW format.

    Yes, I have confirmed that using the, "Addressable Unit," format allows me to save memory on a one byte per line format using CCSv5, but the memory contents are still incorrect.  I will review the reported bugs you mentinoned.  Reading the correct memory is the primary concern.  The format is trivial.

    3247.ccsv51-memory.zip

  • Hi Jason,

    ok, glad to hear and thanks for the feedback.

    Best Regards,
    Lisa

  • Lisa TI said:

    also check whether this bug might be affecting you

    SDSCM00042608

    Yes, this bug description matches what I observed.  This is the answer I needed.  I'll be able to read the memory correctly when this bug is fixed. 

    Next time I look at the device descriptor of an unrelated MSP430 part, I'll see if this problem is unique to F552x parts and variants or to other parts too.