• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 915 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.

TMS570LS1227: Reconfiguring MPU extends flash f021 sector erase time

Steven Aris26
Prodigy 210 points

Part Number: TMS570LS1227

I've been reconfiguring our MPU settings to test our stack overflow mechanism and have found that reconfiguring a number of MPU regions (even if they are "reconfigured" with exactly the same settings as per their current configuration) extends the erase time of the first sector we try to erase by up to 100%.

While this isn't a show stopper (at the moment at least), we need to understand what is causing this increase in sector erase times in case we inadvertently change something in future that has a similar effect.

Our MPU is initially configured in the bootloader and this all works okay, with no effect on flash sector erase times.

To test the stack overflow protection I was reconfiguring a number of the stack related MPU regions (4 to be precise - regions 4, 5, 6 and 7).  I was doing this in our application code to force a permission fault, but was finding that any subsequent attempts to reprogram the Application over our CAN connection were failing - this turned out to be due to a (possibly unnecessarily restrictive) timeout on our flash wait function which waits on the FMSTAT register BUSY flag.  It should be noted that the processor gets reset (using the ESM nError pin) between reconfiguring the MPU and erasing the Application flash, either via our Abort handler or through our normal programming mechanism.

If I only reconfigured (any) 3 of the 4 aforementioned regions our flash wait timeout didn't trip and the flash sector erase time was only slightly increased - about 10% or so.

If I simply reprogram these regions (or, as it turns out regions 8 and 9, which are our abort and undef stack traps) with the values they already contain, I see exactly the same behaviour.

Our base MPU settings are as follows:

Region Base Address Size and enable Access control Description
0 0x00000000 0x0000002B 0x00000308 Program Flash
1 0xF0000000 0x0000002D 0x00001308 Bank 7 EEPROM
2 0x80000000 0x0000002D 0x00000308 RAM
3 0xFC000000 0x00000033 0x00001301 Peripheral registers
4 0x08000020 0x00000009 0x00001008 User stack guard
5 0x08000820 0x00000009 0x00001008 SVC stack guard
6 0x08001020 0x00000009 0x00001008 FIQ stack guard
7 0x08001820 0x00000009 0x00001008 IRQ stack guard
8 0x08002820 0x00000009 0x00001008 Abort stack guard
9 0x08002C20 0x00000009 0x00001008 Undef stack guard
10 Not used N/A N/A N/A
11 0xFFF80000 0x00000025 0x00001100 System Modules

Any help would be much appreciated.

Best regards,

Steve

  • 0
    TI__Guru**** 200276 points
    Hello Steve,

    The same MPU settings in Bootlader doesn't affect the erase time of erasing the sectors for application (for example sector 7/8/9 starting from 0x20000). You program the application from bootloader, then you execute the application code and re-configure the MPU settings to force the permission fault. The fault causes the CPU reset, then you want to re-program the application again from CAN bootloader, and notice that the erase time is much longer than before. Is my understanding correct?

    After CPU reset, the value in MPU registers (CP15) are reset to default value. MPU will not be able to keep the settings you did in the application code, so the previous settings won't impact the erasing time.

    Erasing a blank sectors (may be erased by CCS when loading the bootloader) takes less time than erasing non-blank sectors (your application).
  • 0 in reply to QJ Wang
    Prodigy 210 points

    Hi QJ,

    Thanks for the fast response.

    Yes, your understanding is correct.

    The sector that is being erased is always non-blank in this instance and is fully programmed, so I would expect the erase times to be consistent, but for some reason they are not and while I was under the impression (which you have now confirmed) that the MPU was reset after a CPU reset, the only thing I've found that makes a difference is adding\removing the code that reconfigures the MPU in the Application...and although I don't think this issue is directly due to the MPU, does the act of configuring (or reconfiguring) the MPU also affect other components or peripherals, for instance the F021 flash interface\state machine?

    I should perhaps also say that when we reprogram the Application, we erase four sectors (Bank 0, sectors 10 to 13 - 0x00080000 to 0x000FFFFF) and it is only the first sector erase (sector 10) that shows the extended erase time.

    Is it possible that some setting is persisted in the F021 interface or state machine that needs clearing?  My guess is probably not, but the only areas I can see that might effect the flash sector erase times are the F021 state machine, ATCM interface and MPU.

    We do also have ECC checking enabled for Bank 0 flash, but that is enabled in all cases (although obviously disabled when erasing or writing to flash).

    Additionally, I can confirm that CCS does not erase our Application when re-programming the Bootloader - CCS is setup just to erase the sectors that are to be programmed.

    Best regards,
    Steve

  • 0 in reply to Steven Aris26
    TI__Guru**** 200276 points
    Hi Steve,

    Have you figured out which caused the slower erasing?
  • 0 in reply to QJ Wang
    Prodigy 210 points

    Hi QJ,

    Unfortunately I've not managed to spend any time on this recently...and probably won't get any chance to look at it in the near future either, as we have more pressing tasks to complete, at least that is unless we inadvertently make a change that triggers this problem again.

    I take it there are no more suggestions or ideas from any of your teams that could give some idea of what may cause this issue?

    Best regards,

    Steve

  • 0 in reply to Steven Aris26
    TI__Guru**** 200276 points
    Hi Steve,

    I checked with our design engineer, and confirmed that changing the MPU settings in application doesn't affect the flash operation (erase/program) in bootloader (jump back to bootloader from application using reset). MPU is reset after CPU reset too.