• State
  • Replies 4 replies
  • Subscribers 35 subscribers
  • Views 88 views
  • Users 0 members are here
Support feedback
Options
Options
Related

MSPM0G3518-Q1: Accessing Factory Region issue

mahmoud ghorab
Prodigy 20 points

Part Number: MSPM0G3518-Q1
Other Parts Discussed in Thread: MSPM0G3519

Hello TI support team,

I am currently implementing the Secure Debug feature on the MSPM0G3519 series, utilizing the provided SDK examples and the dl_flashctl driver for NONMAIN area access.

I am encountering a critical issue where the Factory Region (Information Area) becomes inaccessible during runtime. Upon initial flashing and prior to system initialization, the Factory Region memory (starting at 0x41C40000) contains the correct calibration and configuration data. However, immediately following the execution of the ( MCU_Init) routine, Factory Region memory returns all zeros in the debugger’s memory view.

Furthermore, any attempt by the software to access this region (e.g., via DL_FactoryRegion_getNumBanks()) results in the system entering the Default_Handler. This suggests a Bus Fault or a hardware-level security lockout triggered by the system configuration.

Could you please clarify the issue and propose a solution for it?



thanks and best regards,






  • 0
    Guru 101605 points

    What clock are you using during the Factory area references? 

    Erratum FLASH_ERR_01 [Ref Errata (SLAZ758D) p. 7] reports that references to the Factory region will encounter a Bus Fault if the Wait States are =2. This wait-state setting happens (automatically) when a high-speed clock is used [Ref TRM (SLAU846C) Sec 2.4.5].

    If you want to use a high-speed clock, you should fetch/cache any Factory data you'll want before you switch the clock.

  • 0
    Prodigy 10 points

    yes, This is actually the issue. I am working on high-speed clock and when I switched the clock to Low-Frequency clock, I read Factory data normally.

    I know that the solution is to read this data before switching the clock to high-speed clock but what if I want to read this data after the switch? is there a way to do so? because I am switching the clock in the initialization and I am using the API "DL_FlashCTL_unprotectSector" in runtime and this API needs to read Factory data. 

    I thought about two solutions:

    1. to switch the Clock to LFCLK before calling this API and after the call I will switch the Clock back to HSCLK.
    2. change ULP Clock Divider to UDIV_3 instead of UDIV_2

    Please tell me if one of the two solution will work or suggest another solution to solve this issue.

  • 0 in reply to Mostafa Ahmed
    Guru 42445 points

    It is not like the data will change during runtime. Caching it, assuming you are not severely hampered by RAM would be the way to go. Another way to go would be to set aside a persistent storage area and cache it in Flash with a checksum. When you start up the program check this area. If the checksum is good, you continue on, if not you copy the values to the flash, along with the checksum.

  • 0 in reply to Mostafa Ahmed
    Guru 101605 points

    The way this is supposed to work is that driverlib caches the Factory region in SRAM (DL_FACTORYREGION_TrimTable) via a call to DL_FactoryRegion_initTrimTable(), as seen in (e.g.) DL_SYSCTL_configSYSPLL(). The DL_factory_xxx functions check to see if this has been done, and if so reference the RAM copies.

    But I don't see this initialization being done in any of the FlashCtl functions. I suppose it would be done ("by accident") if you were using SYSPLL, but this seems like a gap in driverlib somehow.

    You might try duplicating (in your code) the sequence in configSYSPLL, specifically:

        if (!DL_FactoryRegion_isTrimTableInSram()) {
        DL_FactoryRegion_initTrimTable();
    }

    You would need to do this early on, before switching the clock. But maybe this will be easier than changing the clock for every Flash operation.

    [Edit: Minor clarification]