MSPM0G3519: accessing factory region data causing hard fault.

Hi,

How are you accessing the factory region?

-Matthew

i am configuring SYSPLL using DL_SYSCTL_configSYSPLL() that function inside call DL_FactoryRegion_initTrimTable that access .TrimTable. 

I would double check that you are jumping to the right location in memory

dev.ti.com/.../node

Yes i have checked register table ro r1 r2 r3 pc lr xpsr . reset handler i am getting is correct. 

one question. if code can access factory region when no bootloader. but as i placed app at different location and bootloader at 0x0000 it is going into hard fault . bootloader is customer secure code provided by TI. does this code any how enabling or disabling something that restrict factory region access?

What clock source does your bootloader use?

On entry to the application, it needs to be set to SYSOSC to avoid triggering Erratum FLASH_ERR_01. [Ref Errata (SLAZ758B) p.7 and TRM (SLAU846B) Sec 2.4.5].

When i configure PLL in Bootloader and remove PLL configuration from application code then everything works fine. Is factory region only accessible from code loaded at start of flash? 

this precaution i have added . solution mentioned in err i have added . kept flash wait state 2. 

If the application doesn't configure the PLL, then (we suppose) it won't reference the factory region using 2 wait states, and thus won't trigger FLASH_ERR_01.

That didn't sound like the result you had in mind, but it would work.

I suppose the reason it's an Erratum is that usually adding wait states doesn't hurt you (just slows you down a little) but in this case it does.

pardon me but dont understand exactly. what exactly i need to do here to resolve this issue?

If you're using something besides SYSOSC in your bootloader (SYSPLL or HFXT) you should switch back to SYSOSC before calling the user program. Then that program can set MCLK as it chooses.

I vaguely recall a driverlib function that sets MCLK back to SYSOSC but I don't have my materials here 

Do you have documentation regarding this? I mean how this clock change affects the code to access some area? And why it required to switch back to SYSOSC before jump from bootloader if bootloader is operating on clock source other than SYSCOSC.

TRM Sec 2.4.5 says that if you use one of the high-speed clocks the Flash wait-states are set to MCLKCFG.FLASHWAIT which is =2. (You can change this but you probably don't want to.)

The description of FLASH_ERR_01 says that reading the Factory region with =2 wait states will trigger a Hard Fault. initTrimTable() is called before disabling the PLL, so it's still running with the clock (and thus the wait-states) from startup i.e. inherited from the boot loader.

If you're using a high-speed clock (e.g. the PLL) in the boot loader I expect that you would call that function just before calling the application entry point. Alternatively: don't use a high-speed clock (stick with SYSOSC) in the boot loader.

More generally: It would seem that a boot loader should (to the extent possible) call the application with conditions resembling those at Reset, since the application probably expects that.