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.

CCS V4.0.2 & MSP430x5xx: Cannot access upper flash banks

Other Parts Discussed in Thread: MSP430F5438, MSP-TS430PN80USB, MSP430F5529

Hey all,

 

Tell me if you've heard this one before...

 

I'm running CCS v4.0.2 Platinum, using the 'msp430x5xx C Example' project with the MSP430F5438 Experimenter Board (with a '5419 replacing the '5438).  I can compile, load and exec the project output, but cannot access any memory above 0xFFFF.  The memory window returns all X's and the tool tip states:

 

' Address 0x20000

Error code 0x5: Memory access not attempted by the driver (Check memory map) '

 

Any ideas as to why I cannot see the upper banks of flash (banks 1 & 2) under CCS v4.0?

 

regards,

gifford scott

DST

  • Hi,

    I took the chance to verify this with an (preview) F5529 device. If modified the .cmd file as below:
    ...
    INFOD : origin = 0x1800, length = 0x0080
    FLASH : origin = 0x4400, length = 0xBB80, f= 0x0aa0 // fill unused memory with 0x0aa0
    FLASH2 : origin = 0x10000,length = 0x14400, f = 0xabcd // fill unused memory with 0xabcd
    INT00 : origin = 0xFF80, length = 0x0002
    ...

    downloaded the app (demo from TI) to the F5529 and opend a memory window which shows this:

    Can anybody pls explain what this error code (0x5) means and how to get rid of it? I'm using a MSP-FET430UIF and an MSP-TS430PN80USB with an XMS430F5529IPN.

    In addition, when scrolling through the memory window I get error messages like shown below:

    Rgds
    aBUGSworstnightmare

  • BUGS,

     

    Thank you *very* much for taking the time to verify this issue.  I can confirm that you are seeing the same issue that I've been seeing.  I still have to wonder why this issue is not being raised by more developers...

     

    regards,

    gifford scott

    DST

  • The CCS development team is actively looking into this issue and we hope to have a workaround soon. We apologize for the delay in addressing this issue.

    Raj

     

  • Hi Gifford,

    We are currently looking into this issue, and we have a workaround solution in place that I will be describing in this post. Please note that the final solution to this issue will be addressed in the release of CCS4.1; therefore this workaround will not be needed in future CCS releases.

    The workaround involves loading a different .gel file, which I have attached as a zip (mspx_fix.zip) file, which includes the file mspx_file.gel. You can tell CCS to load this GEL file when you launch a debug session by:

    1. going to the Target Configuration (.ccxml) for your device, by default it is under your project, MSP430F5438.ccxml.

    2. Go to the 'Advanced' Tab in the Target Configuration view.

    3. Click on the 'MSP430' node under 'All Connections'

    4. On the right, there is a field for initialization script (defaults to msp430.gel), click browse and choose the mspx_fix.gel file that is available inside the attached zip.

    5. Save the changes.

     

    With this change, every time you launch a debug session using this Target Configuration, the memory map will be set up correctly, allowing you to read 20 bit memory addresses in the Memory View.

     

    Let me know if you have any questions about this fix.

    Thanks.

    mspx_fix.zip
  • Ricky/Raju,

    Thanks for the update.  I placed mspx_fix.gel in my C:\Program Files\Texas Instruments\ccsv4\common\targetdb directory, followed your instructions above and indeed the memory window is fixed - allowing me to see memory right up to the 0x25C00 boundary on the '5419.  It sounds like you are on the right track, however the disassembler window still fails to see code/memory above ~0x25B50.  You should be able to verify this behavior on your '5438 - to repeat, the memory window is fixed, but the disassembler window is not.

    Additionally, this does not fix my fundamental issue.  In this post and my previous post (http://e2e.ti.com/forums/p/11891/47142.aspx%2347142), I was having trouble loading code into the 0x20000 address space (flash bank 2) on the '5419.  This fix does not correct this issue - I still see the same error message.

    Ricky - You requested some additional verification steps, using the '5438, if I continued to have problems.  Unfortunately, I do not have '5438 chips at hand, but, given that the disassembler window is still exhibiting issues w/this fix, I think you might have the example you need to further verify this issue.  The pertinent details/changes of my the linker command file are captured in the initial message on this post: I just created a FLASH2 memory section corresponding to the memory range of flash bank 2 of the '5419 and directed the .text section into this FLASH2 memory section.

    Again, thank you for your efforts and for the update - I hope that you can completely resolve this issue.

    regards,

    gifford scott

    DST

  • Hi Ricky,

    took the fixed gel file to test with my F5529 device. Seams the problem is only partially fixed here too. As you can see in the screenshots below FLASH 2 now gets filled up with 0xABCD (as specified in the .cmd file), but in the second window you'll see that Bank 3 (0x01C400 - 0x0243FF)  is isn't filled up completely; from 0x24338 to 0x0243FF the memory isn't fill or can't be read respectivly. Furthrmore, memory window doen't work reliable (stalls sometimes and shows error reported above).

    Pls commend this issue
    Rgds
    aBUGSworstnightmare

     

  • Hi,

    Thanks for posting the screenshot. It is really helpful for me to better understand the problem.

    I can't directly comment on the reliability of the memory window, as I am not responsible for the component, but I will redirect your feedback to the relevant people.

    But I can comment on the error you are seeing. I believe this is related to the issue with reading memory (for both Disassembly and Memory View) near the end of addressable memory. Additional information is available at:

    http://e2e.ti.com/forums/p/11891/47341.aspx

    Although I haven't seen the error message you are getting (Memory Request Failed ... memoryUpdateInfor.isAborted=true). I will continue to look into these issues and update you if I have any new information on it.

    Let me know if you have any additional questions. Thank you.

    Ricky.

  • Hi,

    Another quick update.

    The Memory View and Disassembly View issues that were reported has been addressed, and will be available starting in the next CCS release. Also note that the gel file fix that was posted in this thread will not be needed in the next release.

    Regards,

    Ricky

  • Hi Ricky,

    since this problem with the MSP430F54xx seems to be fixed (http://e2e.ti.com/forums/p/11891/49244.aspx#49244), what about the problem with MSP430F55xx devices? Any news on this?

    Rgds
    aBUGSworstnightmare 

  • aBUGSworstnightmare,

    If you are referring to the issue with viewing the data at end addresses in the Memory/Disassembly view, the issue was discovered and a fix has been implemented. The fix applies to all 20bit addressable MSP430 devices, including MSP430F55xx devices. This fix will be included in the next CCS release.

    Let me know if this answers your question.

    Thanks.

    Ricky

  • Hi Ricky,

    yes, that's the answer! When is the next release scheduled?

    Rgds
    aBUGSworstnightmare

  • Hi,

    Quoting myself in the other thread about the release date:

    "I don't know the official release date of the next release, since I am not responsible for the scheduling of releases; but I understand it should be release within a couple of months. I will try to find something more official for you if possible."

    Regards,

    Ricky

  • We will be doing a beta release of CCSv4.1 this month and then the final release will be in Jan.  The beta release will be publically available from the CCSv4 mediawiki site.  http://tiexpressdsp.com/index.php/Category:Code_Composer_Studio_v4

    For the beta we will just have a full install but for the final release we will have both full installs and a patch to 4.0.x.

    John

     

  • Hi JohnS,

    thanks for the info! Is the BETA release because of added Stellaris support or are there some other issues why you decided to do another beta test?

    Rgds
    aBUGSworstnightmare

  • aBUGSworstnightmare

    Most changes are of the bug fix and minor enhancement category, 4.1 has a lot of these.  There are a couple things that are more significant like Stellaris and some performance improvements.  The performance improvements mainly impact multi-core devices where there are a LOT of peripheral registers.  We are also formally validating on Windows 7.

    Regards,

    John

  • Hi John,

    was the CCS V4.1 beta test started already? I can't find any info on the wiki.

    I would like to participate in this beta testing to prove CCS 4.1 is working with VMware 3.0 (Mac OS X Snow Leopard is the host) and Windows 7 (Guest OS, 32-bit version). In addition, I would see the problem with the MSP430F5529 memory window fixed.

    Rgds
    aBUGSworstnightmare 

  • We had  a few delays due to the holidays. CCSv4.1 Beta will be out this Friday.

    Raj