• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 981 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Using the flash memory on MSP430G2231 with Launchpad and CCS for datalogging

Andreas Schramel
Prodigy 20 points

Hi!

I'd like to use 1K of the  2K flash memory for datalogging purposes. So I edited the flash entry in the linker file to another origin and length:

original entry:

 FLASH                   : origin = 0xF800, length = 0x07E0

edited entry:

FLASH                   : origin = 0xFC00, length = 0x03E0

So only the last two segments are used fpr program memory, the interrupt vectors and the reset vector. The first two segments can be used for logging.

I can fill the first two segments with data in my code.

The question is: what is the best way to get the data out? The problem I have is, that all segments are erased every time I start the debug session.

Is there any way to read and save the memory without entering the debug session? Or is it possible the protect that area bevore the build gets downloaded?

Thank you for your help!

 

Andreas

 

 

 

  • 0
    Guru 227245 points

    When starting a debug session, the debnugging software loads up the firmware. It doe sso by performing a main memory mass erase and then sending the new firmware. Which will delete your data.

    You may be able to configure the debugger to start a session without firmware download. then the data but also the old firmware will remain unchanged.

    However, every MSP has a separate INFO memory which is not erased when uploading a new firmware. Its size is smaller (256 to 1024 bytes, depending on the MSP), bu tspecifically meant for storign data taht shall survive firmware updates.

  • 0 in reply to Jens-Michael Gross
    Prodigy 20 points

    Thank you for your reply!

    I did't use the information memory because there are only 4 segments with 64bytes each. Moreover I didn't want to use segment A because of the DCO calibration data. So there are only 3x64bytes.

    As you suggested I edited the debug settings in ccs to not download code automatically. Now I can start the debug session without erasing the flash. Then I can save the memory to a file. To erase the flash I simply change the settings back to erase all flash areas and restart the debug session.

    In addition I wrote some code to find unused space in the flash (contents not 0xFF) that gets executed after reset. Through that way the logging is resumed after a reset  until the flash is full.

  • 0 in reply to Andreas Schramel
    Guru 227245 points

    Andreas Schramel said:
    there are only 3x64bytes.

    Yes, for data logging this really isn't much. It's rather meant for storing config data.

    Andreas Schramel said:
    In addition I wrote some code to find unused space in the flash (contents not 0xFF) that gets executed after reset. Through that way the logging is resumed after a reset  until the flash is full.

    Great. You should include some sort of CRC into the data, so you can check if the last written data was properly written (in case the power supply fails during a write). I do so with my config data too (two sets, including CRC, and after writing one, I make the other invalid, so there's always a valid config, possibly two for a short time, but never none)
    Whether a CRC or parity or such is necessary depends on the importance of validly stored data and the likelyhood of a write during power fail (if you can detect a power fail soon enough, it is no treat, but if you write often and do not detect a power fail before starting to write...)

**Attention** This is a public forum