• State TI Thinks Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 1673 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.

RM48 MPU restricts reads but not writes

Westin Sykes
Expert 1315 points
Other Parts Discussed in Thread: HALCOGEN

I am using the RM48 HDK with CCS 5.5 and HALCoGen 3.08. I am trying to restrict writing to certain memory locations, but I only seem to be able to restrict reading. When I set the permissions to PRIV_NA_USER_NA_NOEXEC, I cannot read, but I can write to that memory range. When permissions are set to PRIV_RO_USER_RO_NOEXEC, I can both read and write. Do you know any reason why this might happen?

Thanks,

Westin

  • 0
    TI__Intellectual 1115 points

    Hi Westin,

    I've referred your question to one of our experts who will get back to you.

    Best regards,
    Paul B.

  • 0
    TI__Mastermind 49120 points

    Hi Westin,

    Sorry for the delay in getting to this.

    The memory range you are trying to limit access to is in flash. The CPU is not really able to "write" to the flash. Rather, it is using the flash interface module (FMC) to program the flash. The CPU provides the data to be programmed to the FMC. The FMC has a state machine which then carries out the programming command. This programming is not affected by the CPU's MPU settings.

    If you do want to check the ability to prevent CPU writes via MPU, choose an SRAM as the region for applying the restrictions.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Expert 1315 points

    Okay, that's good to know. Is there any method of locking down flash memory in the state machine or elsewhere? I am working on a bootloader for my application, and want to make sure the application cannot overwrite the bootloader.

    Thanks,

    Westin

  • 0 in reply to Westin Sykes
    TI__Mastermind 23000 points

    Hi Westin,

    I'd suggest you take a look at the flash wrapper's sector protection feature.  

    Regards,

    Karl

  • 0 in reply to KGreb
    Expert 1315 points

    Where can I find information on that? Is that part of the F021 API?

    Westin

  • 0 in reply to Westin Sykes
    TI__Mastermind 23000 points

    Hi Westin,

    Sector protection is a hardware feature.  I am not sure if it is supported in the F021 API.  Here is an older discussion on the forum with some information on the feature:  http://e2e.ti.com/support/microcontrollers/hercules/f/312/p/171790/642715.aspx#642715

    Regards,
    Karl

  • 0 in reply to KGreb
    Expert 1315 points

    I don't think that is exactly what I need. Let me be more clear on what I need. After the bootloader executes, it will most likely launch the application code in a non-privileged mode. I want to make sure a bug in the application code cannot write to sectors containing the bootloader. Is there a way to keep the application code from erasing or overwriting the bootloader even if it tried?

    Thanks,

    Westin

  • 0 in reply to Westin Sykes
    TI__Mastermind 23000 points

    Hi Westin,

    I think we are generally aligned on the operational concept.

    From the CPU's perspective, the flash memory is a read-only memory.  The CPU's memory protection unit has the same view as the CPU - it does not understand the complexities of programming a complex NVM such as flash.  This is why there is an additional hardware sector protection in the flash wrapper.  When sector protection is programmed, you cannot erase or over-write the contents of the sector.

    As an additional support, you may wish to use the CPU's MPU to define the reprogramming code of the API to execute only in privileged mode.  In such case a fault should occur if the code sequence were ever be entered by the application software (unprivileged), a prefetch abort due to MPU access violation should occur.

    Keep in mind there are many different ways that your software architecture could be developed to take advantage of the available protections in hardware.  You may well find a different solution which better suits your intended usage.

    Best Regards,

    Karl

  • 0 in reply to KGreb
    Expert 1315 points

    KGreb,

    When you say sector protection, are you talking about the Fapi_enableMainBankSectors function being used to enable and disable sectors or something else?

    Thanks,

    Westin

  • 0 in reply to Westin Sykes
    TI__Mastermind 23000 points

    Hi Westin,

    I am speaking of the hardware sector protection built into the device.  I am not a software engineer so I cannot comment on how this hardware is utilized (or not utilized) by the F021 API.  We'll need someone to respond from the software team to provide such details.

    Regards,

    Karl

  • 0 in reply to KGreb
    Expert 1315 points

    Can anyone tell me if this hardware sector protection is what is behind the Fapi_enableMainBankSectors function or is this something else that may solve my problem?

     

    Thanks,

    Westin

  • 0 in reply to KGreb
    Expert 1315 points

    KGreb,

    Can you explain to me what the hardware sector protection does? Does it allow me to lock a sector and disallow unlocking it after it has been locked (either once per startup or once ever)? I think that is what I need to have. Surely there is a way I can make sure nothing else writes over the sectors my bootloader is in.

    Thanks,

    Westin 

  • 0 in reply to Westin Sykes
    TI__Mastermind 23000 points

    Hi Westin,

    I've asked the flash API experts to comment, will try to run them down again for you.  Apologies that it is taking so long.

    As I understand the hardware, the sector protect is an additional protection which must be disabled before a program/erase operation can occur.  This is not a permanent lock, but a soft lock which can be enabled/disabled by software.  I would assume that an additional lock/unlock routine must be executed in addition to the standard flash API commands.

    Regards,

    Karl