• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 372 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.

MSPM0L1105: Access to last 8 bytes of flash bank

Gavin Li
Prodigy 45 points
Part Number: MSPM0L1105
Other Parts Discussed in Thread: MSPM0G1105, MSPM0G1106, MSPM0G1107, MSPM0G1505, MSPM0G1506, MSPM0G1507, MSPM0G3105, MSPM0G3106, MSPM0G3107, MSPM0G3505, MSPM0G3506, MSPM0G3507, MSPM0L1227, MSPM0L1228, MSPM0L2227, MSPM0L2228

Tool/software:

The datasheet for MSPM0L1105 states the following:

CPU access to one of the last 8 bytes of a flash region will cause a hard fault. This occurs because the prefetch logic tries to read one flash word (64 bits) ahead, resulting in a read attempt to an invalid memory location.

Does this refer only to instruction accesses, or does this apply to data accesses too? Do data accesses have prefetch logic that would cause the CPU to read more than what is requested?

  • 0
    TI__Guru 70726 points

    Hi Gavin,

    Should only apply to prefetch instructions, not data.

  • 0 in reply to Dennis Lehman
    Prodigy 45 points

    Thanks Dennis. Does this mean that I can use the entire 32 KiB flash region (0x0 - 0x8000), so long as the last 8 bytes (0x7FF8 - 0x8000) consist of data and not code?

  • +1 in reply to Gavin Li
    TI__Guru 70726 points

    Hi Gavin,

    This question was asked before -> E2E link.  I did some further research and apparently the last 8 bytes are not accessible for either a read or write operation, so cannot be used for data storage.

    Sorry for any confusion.

  • 0 in reply to Dennis Lehman
    Prodigy 45 points

    Got it, thanks. I can't view the E2E link because it seems to refer to an internal site that I don't have access to.

    I checked the linker files included in the SDK, and it appears that while some linker files take this limitation into account, the linker files for the following parts do not and should be updated:

    • mspm0g1105
    • mspm0g1106
    • mspm0g1107
    • mspm0g1505
    • mspm0g1506
    • mspm0g1507
    • mspm0g3105
    • mspm0g3106
    • mspm0g3107
    • mspm0g3505
    • mspm0g3506
    • mspm0g3507
    • mspm0l1227
    • mspm0l1228
    • mspm0l2227
    • mspm0l2228
  • 0 in reply to Gavin Li
    TI__Guru 70726 points

    Hi Gavin,

    Thank you so much for checking all those linker scripts.  I'll notify the SW team to follow up.

    I re-copied and re-pasted the link to the other E2E forum post (it is not an internal link), but essentially it says check the datasheet.  So looking at the MSPM01105 datasheet I see the memory allocation does not use the last 8 bytes.

    Checking the other family datasheets, G350x,G310x,G110x,L130x,L110x, etc., I see they also show same as above.

    Now, I spoke with one of our design engineers and asked why this is. He says the MSPM0 FLASH (actually it's an ARM convention) addresses are word aligned (64-bit or 8byte), so technically 0x...FFF8 is the last addressable location.  Yes, some of the linker scripts have not been updated to reflect that, so thank you for pointing this out.

    Now according to the MSPM0L series TRM, section 6.3, FLASH is aligned on 64-bit (8byte) boundaries, but it does appear possible to program 32-bit, 16-bit and even 8-bit, but takes some fiddling with the NVM controller to do so.  So if trying to use FLASH for byte data storage it looks possible.

    Does this help?

  • 0 in reply to Dennis Lehman
    Prodigy 45 points

    That helps, thanks. I was just curious about the difference since it looks like the MSPM0C110x don't have this restriction despite having the same Cortex-M0+ core with presumably the same prefetch logic.

    One more question: we're also considering the MSPM0L1228, and it appears to have the same restriction at the end of each flash bank:

    This means that if we were to use the entirety of the dual-bank flash as a single bank, there may exist an 8-byte unusable "hole" in the middle of the flash that we must account for and avoid. Though I'm guessing that if prefetch is the cause, it should work in this case since it would just prefetch the start of the second bank. Greatly appreciated if we can get some clarity on this.

  • +1 in reply to Gavin Li
    TI__Guru 70726 points

    Hi Gavin,

    For MSPM0C, the pre-fetch mechanism has been removed (cost reduction), therefore it won't have this limitation.  Regarding the dual bank, yes, you are correct.