LAUNCHXL-F280049C: POR mixes #pragma control data after UniFlash firmware load

Hi,

Apologies for the delay in response to the query. I have requested the subject matter expert to respond to your question. 

Thanks & Regards

Pramod

Hi Pramod,

This issue is seemingly related to INOSC2 clock not switching over to INTOSC1 when the application configures the 20MHz external XTAL after UniFlash or CCS debug loads firmware.

It seems the PLL is being driven by INTOS2 until disconnect from UniFlash or CCS debug and POR the target. And issue flash API OTP checksum crashing, there was a bug in application that did not appear when target was connected to UniFlash or CCS debug. I had assumed INTOSC1 was the PLL clock source after firmware load.

GI,

The default clock from power up and after a XRSn event is INTOSC2.  I believe, as you have mentioned, that the inbuilt flash programming tools are also using this to give a known clock in which to program the flash.  If you had changed this setting in your code, and then used the flash tools the clocks would need to be re-initialized again.

Can you expand on the order of operations wrt using the flash tools vs loading/running your code?  Are you using the C2000Ware examples for switching clock sources as well?  This should ensure a stable clock is present before the C28x switches over to it.

Best,

Matthew

Hi Matthew,

MatthewPate said:

If you had changed this setting in your code, and then used the flash tools the clocks would need to be re-initialized again.

What flash tools are you referring to, CCS debug or flash API? On POR - INT0SC2 is the PLL source. Yet there is an 20MHz XTAL being initialized prior to flash initialization in LSRAM, only then flash API was loaded. After seemingly related clock issues set PLL to run 100MHz and SYSDIV = 1. So SYSCLK now runs at PLL speed 100MHz. Have not yet tried to run flash API since. Will report back later if PLL corrected OTP checksum failure of flash API tools.

Should we expect SysCtl_setClock() to disable INTOSC2 then configure PLL for XTAL? Seemingly it may not be doing that on hardware reset, rather on POR when ROM Boot invokes OTP checksum. Remain a bit confused by TRM as to what is difference flash API User OTP checksum and ROM boot OTP checksum addresses, are they the same address space?

Is there more than one OTP memory space other than the link pointers addresses? The flash API user guide doesn't differentiate between these OTP checksums. Logically they seem to be different addresses since driverlib calls configure link pointer zones, seemingly not flash API.

GI,

I was referring to the CCS debug flash tools. For example, if you had been debugging some code that had loaded RAMs and set up the clocks; if you then decided to re-load the flash with the debug tools they will change the clock settings back to INTOSC2 and co-opt the RAM to load the flash image.  Before you begin debugging again, you would need to restart your native code to re-initalize things properly for your setup.

Typically flash load with CCS is done at first connection/power up so this doesn't come into play, but I wanted to make this distinction above in case it applies here.  This is a outcome when using the CCS flash tools(or Uniflash) only.

The flash API functions themselves will not change the clock source/PLL settings, so as you use these inside your program that is not a concern.

The InitSysPll() will take care of switching the clock source over to XTAL from INTOSC2 cleanly.  I need to look into the BROM flow a bit more here to see if the PLL is invoked or not.  In any case, during BROM we would be on INTOSC2 since until we hand over control to the user:main we can't know which clocks are available in the system.

Best,

Matthew

MatthewPate said:

Before you begin debugging again, you would need to restart your native code to re-initalize things properly for your setup.

That is forced after Run mode paused and user does MCU reset the code does not run to main. In this thread I was referring to a notable difference after terminating debug and hardware reset, the #pragma code executed as expected but failed on all POR events after.

The same was true flash API during OTP checksum caused NMI after POR but not after termination or run to main in CCS debug. The NMI during OTP checksum was random if at all on run to main. Yet after POR it caused hard NMI exception every time, seems a ROM boot related issue.

GI,

Apologies from me on not getting back with you until now.  Is there any update from your side on the issue?  Looking back at the top line, difference between POR and XRSn, both should force a MEM_INIT.  A debugger reset would not force a MEM_INIT on the SRAMs though, but I think you mean XRSn when referring to hard reset.

Best,

Matthew

Hi Matthew,

MatthewPate said:

A debugger reset would not force a MEM_INIT on the SRAMs though, but I think you mean XRSn when referring to hard reset.

Right the launch pad push button produces a hard (HW) reset. So XRSn input being toggled and ROM boot loader executing flash to mcopy() #pragma sections into LSRAM. Oddly worked fine out of debug but were mangled during POR events. Seems the PLL was set for 200MHz and divided by 2 for 100MHz SYSCLK prescale x1. It seems to be a bit more stable this way.

BTW: I noticed the x25 INT)CS2 clock PLL divisor and other settings differ from x49c but they both have 20Mhz XTAL. Was there a change made to driverlib SysCtl_setClock()?

GI,

I'm wondering if this is an artifact of the clock that is available on the launchpad vs the controlCARD.  I know in the earlier devices, like F28004x, the clock was different between the two platforms, so we had to use pre-defines.  I think in later designs, like the F28002x we made the clocks the same across both platforms, so perhaps that is why you are seeing a difference?

Best,

Matthew