• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 55 subscribers
  • Views 160 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC1350: Custom flash erase running from flash?

Paal Oeyvind Reichelt
Prodigy 152 points
Part Number: CC1350

To support a low power design, we were provided a great example by Max Wennerfeldt of a custom flash erase function that allowed us to solve a power supply issue. This was basically a small rewrite of FlashSectorErase from flash.h in the driver lib. The documentation for that function states that "Please note that code can not execute in flash while any part of the flash is being programmed or erased.", so the rewritten function is therefore correctly decorated with __attribute__((ramfunc)). However, placing this in RAM causes quite a bit of compilation headache for us, so we would want to avoid it if at all possible. 

I found that running the custom flash erase code from flash did not appear to cause any issues. Therefore I want to ask: Are there any risks to running the equivalent of FlashSectorErase from flash, when it is always the case that the code runs from a different sector than the one being erased? If so, what are those risks and how can the critical sections be narrowed down to occupy a minimal amount of RAM?

  • 0
    TI__Guru 58425 points

    Hi Paal,

    There is no publicly available information on what the risks is exactly but in general, there is both internal parts of the flash module as well as registers that has specific read/write mode values. This means that the flash is really meant to be in one mode at the time which is the reason for the documentation note (also part of the Technical reference manual). 

    While I can't tell you exactly what could happen, we could assume that the worst case scenario here is flash corruption. There is no difference from read/write on a page basis which leaves me to believe that the limitation stand even if you are performing the operation from another page. 

    If I remember the example I write correctly, I'm not sure it could be made much smaller in terms of RAM. I expect most of the calls in the patched functions to be ROM calls. I will have a second look at it and see if I spot something obvious but I could not promise to work wonders. Also, it is nothing that we officially support which means I could not share any results here in the public forum. 

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Prodigy 152 points

    Thanks, then we will make it RAM based for sure.