• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 83 subscribers
  • Views 2751 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.

Executing code while erasing flash

Andrew Harwood
Intellectual 355 points
Other Parts Discussed in Thread: MSP430F5529

I see that the new MSP430x5xx Family Users guide indicates on page 258 (slau208d.pdf) that

"Each bank (device specific) can be erased individually while program execution can proceed in a
different flash bank.

Note: Bank operations are not supported on all devices. See the device-specific data sheet for
banks supported and their respective sizes."

And in MSP430F5529.pdf there are 4 banks listed on page 20.

My question is - Can you erase info memory while continuing with program execution?  Is INFO memory a separate bank?

If program execution is possible during an INFO memory erase then why would it say that Bank operations are no supported on all devices (It would seem that all devices have INFO memory).

The data sheet indicates that bank operations are not supported on all devices.  I can't find for any device where the datasheet says that it can support bank operations.  I assume that there are some devices that have multiple banks but do not support program execution during an erase (or is the document stating the obvious, that you can't continue program execution if there is only one bank)

 

  • 0
    TI__Mastermind 26380 points

    Andrew,

    Good question!

    (1) Read/Fetch while erase is supported only on multiple bank devices. On devices with a single bank the CPU will be held when flash memory is being erased regardless of whether the code is being executed out of info memory or main.

    (2) Though this is not very clear from the Datasheet - a bank consists of a portion of the main, info and BSL memory. For example in the 54xx device bank0 includes main memory segments 0x5C00 - 0xFFFF, 0x40000 - 0x45BFF and InfoA, BSL segment0. So a user can only execute from info memory that is not associated with the bank being erased.

    This needs to be clarified in the D/s as well.

    Regards,

    Priya

  • 0
    Prodigy 200 points

    INFO A/B/C/D are "special" memory banks: each one has 128 bytes (MSP430x5xxx) and are erased individually (SLAU208D - pg.259).

    You can erase/write any time you want.

    INFO A has an exception: LOCKA bit, which is an extra protection for erasing and writing.

    You can erase/write others segments *but* you must be sure you are not using them during the erase/write process.

    In the case of CrossWorks compiler, you can configure the flash memory and then use #pragma  to define the locations.

  • 0 in reply to Priya Thanigai
    Intellectual 355 points

    Regarding FLASH34 bug in the Errata sheet for the MSP430F543xA, Does this mean that you can not execute code in any Flash segment while erasing another segment?

    i.e. on page 256 of SLAU208F "Each bank (device specific) can be erased individually while program execution can proceed in a
    different flash bank."

    Is this not a feature that can work with the MSP430?  If this bug does not allow code execution, if it scheduled to be fixed?

    Regards,

    Andrew.

     

  • 0 in reply to Andrew Harwood
    Guru 227245 points

    The description of this erratum is a bit misleadign and I misunderstood it too at first.

    The datasheet tells, that when erasing a block (of 64k) , code may be executed from a different flash block. So if block-erasing the 0x10000-0x1ffff area, code within 0x05c00-0x0ffff will continue executing.

    It does not apply on segment erase (512 byte segments). If erasing a segment, code execution from flash is halted, interrupts must be disabled. Actually, any read to any flash region will be a 3fff read (jmp on self), including reading the interrupt vectors. Same happens when writing to flash.

    Unfortunately, (and that's the silicon bug), the MCU will crash when the block erase command is issued from within flash code. code execution will not only be haltet, it will actually do something unpredictable. A block erase command can only be started from code running in RAM. I haven't tested myself whether code execution may then return to flash while erasing is in progress. There's another thread about this somewhere in this forum (march or later)

    it's best to either don't use bank erase at all or copy a small function to RAM and start bank erase from there, waiting until finished.

    That's a very unlucky thing. It was meant to make things better and made them actually worse - unless you ignore the bank erase and go the slooow way of manually erasing the segments one by one, which takes 128 times as much time. If you do, you're back where things were all the time before. :(

    Personally, I'd see it a VERY good thing if one could continue executing code while erasing any segment in a different bank, not only while doing a bank arase (if working at all). It would make a 'flash disk' more reliable - ISRs and code threads running in other flash banks wouldn't be affected by writing to the flash disk, e.g. for storing measured data. Currently, the MSP has a 32ms 'blackout' when you erase a segment. (writing data can be sliced sufficiently). 32ms are an eternity.

     

  • 0 in reply to Jens-Michael Gross
    Intellectual 355 points

    Jens-Michael,

    Thanks for the info.  I agree, it is a major limitation having interrupts disabled for such a long time.  It makes the onboard flash useless for storing data.  Until TI get this fixed I will just have to settle for external SPI Flash.

  • 0 in reply to Andrew Harwood
    Guru 227245 points

    There's a workaround for this:

    on some MSPs, you can move the interrupt vector table into RAM. If you create a 'dummy' table there, put your ISR into RAM too and disable all Interrupts which don't have an ISR in RAM (this is the toughest part in a modular code design), you can continue gathering data while flash code is unavailable.

    If you MUST store data in Flash (because external flash is too expensive or whatever), this is a possible way to go.

    I made good experience with MMC/SD cards (up to 1GB) attached to an F1611 using the SPI interface (above 1GB, they don't have 512bytes sectors anymore, requiring too much RAM for data buffers). And with the 5438, it should be even better because the SPI can run with full system clock. DMA transfer is required to use this speed. (the SPI/DMA is running fine on my demo board, but I haven't tested it with a real SD card yet)

**Attention** This is a public forum