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.

problem for saving Memory by CCS V6.0.0

Other Parts Discussed in Thread: MSP430F249, MSP430F5529, MSP430F169

I need your help.

 

When launching Debug mode manually by using target configuration and connecting MSP430F249,

I can’t save memory at the following setting.(I use Windows8)

・format: TI DATA

・start address:0x1000

・length:0xF000

And the message like the attached picture shows up.

(Of course, the flash is filled with from 0x000 to 0xFFFF.)

 

In addition to this, by changing “ length” of the saving memory sometimes, I find I can save memory at the length:0x7800 (which is just half of 0xF000!) , and I can’t save memory at over 0x7801( the same message shows up)

 

What should I do to save memory from 0x1000 to 0xFFFF?

Is this a bug of CCS V6.00?

Or Do I need to set any parameters for saving memory?

 

Please, advise me.

 

ryo

  • Hello,

    user4294834 said:
    (Of course, the flash is filled with from 0x000 to 0xFFFF.)

    I don't have much experience with the F249 but looking at the datasheet, it appears flash (for code memory) is from 0x1100 to 0x0FFC). Is that correct?

    ki

  • Hi,

    Which exact CCS version are you using? Is it 6.0.0.00190? Perhaps this was a bug in this older release.  

    The reason is that I was able to save the memory on my MSP430F5529 (I don't have a F249) using the parameters below:

    If that is your case, you can try to download and install a newer release of CCS in a separate directory with a different workspace and try to see if the Memory save works for you.

    Regards,

    Rafael

  • Thank you for your reply.

    Hmm, I'll check the data sheet .

    But , even if flash is from 0x1100 to 0x0FFC, I can't make sense that I can't  save flash from 0x1000 to 0x1000+0x7801(length) more.

  • In addtion, For CCS V4, I can save flash from 0x1000 to 0xFFFF(0x1000+0xF000).
    Hmm, It seems my version of CCS has a bug...
  • Thank you for your reply.

    As you say, my CCS version is 6.0.0.00190.

    and today, I tried same thing in CCS version 6.0.1 (this is newer version).

    however, I got same result.

    In CCS v4 , I can save flash from 0x1000 to 0xFFFF(0x1000+0xF000).

    Hmm, It seems that it doesn't work when using both MSPF249 and CCS V6,

     

  • Hi,

    Just to check, how are you saving memory? I am using the memory Browser view as shown in section 3.3 of the page below:
    processors.wiki.ti.com/.../GSG:Debugging_projects_v5

    I forgot to say that I was using CCSv6.1.3 - in any case, I went back to CCSv6.0.1 with MSP430 emulators component version 6.0.1.8 and I was able to save using the same parameters as above. I then went back to CCSv5.5.0 with MSP430 emulators component version 5.5.0.17 and was still able to save the memory.

    I then dug an older board based on the MSP430F169 and I then hit the problem: specifying the amount to be transferred in bytes overruns the memory and changing to words (in practice dividing by two) saves the desired memory range. With that in mind I just noticed the message box actually says that: "Specify the number of memory words to read".

    I then looked at the saved file of my F5529: it had 94kiB and not the expected 47kiB. The reason CCS did not complain is because the F5529 is the newer MSPX core which has an address range of 20 bits. Both the F249 and the F169 are MSP cores that have an address range of 16-bits.

    With all that in mind, I strongly suspect the smallest addressable unit of the instruction bus is 16 bits - in other words, the instruction memory is word-addressable. I also found out that the parameter "Type-size" only influences the saved data if "swap" is also enabled.

    I have submitted a few enhancements in the past to better clarify these aspects in the memory save dialog box but I can't recall what are their status. I will report back to this thread if anything changes in this regard.

    Hope this helps,
    Rafael