• State Resolved
  • Replies 8 replies
  • Subscribers 32 subscribers
  • Views 90 views
  • Users 0 members are here
Support feedback
Options
Options
Related

MSPM0G3507: Powering up on HFCLK

Dimo Dimov1
Prodigy 170 points
Part Number: MSPM0G3507
Other Parts Discussed in Thread: SYSCONFIG

Hi there,

I have MSPM0G3507 Launchpad here. First steps: I am migrating from MSP432 which was an amazing MCU. 

I managed to get it to receive UART packets where UART is being clocked by SYSPLL. Now I want to switch to the external crystal clock which is 40MHz. On the surface there shouldn't be a problem: in syscgf I am configuring:

MCLK sourced from HSCLK

HSCLK sourced from HFCLK

Enable HFCLK: ticked

HFCLK Source : HF External XTAL

Set External HF Clock Frequency (Hz) : 40 000 000

External HF Clock Frequency: 40.00MHz

The above configuration completely bricks the Launchpad when attempting to debug. It does behave as if I have forgotten to enable the external clock. 

There is an example of using external clock but MCU there boots on SYSCLK after which the swich is made to HFCLK through code.

Can the board boot directly in HFCLK?

Cheers

Dimo

  • 0
    TI__Mastermind 27665 points

    Hi Dimo,

    Dimo Dimov1 said:
    Can the board boot directly in HFCLK?

    MCU boot with SYSOSC=32MHz, after it boot, in users' application, user can enable HFXT and after HFCLK is good, switch the MCLK from SYSOSC to HFCLK.

    If you have further issues on the implementing the HFCLK, please share the clock initial code and I can double check it.

    B.R.

    Sal

  • 0 in reply to Sal Ye
    Prodigy 170 points

    Just to confirm: Is it impossible to boot straight with HFCLK without using SYSOSC?

  • 0 in reply to Sal Ye
    Prodigy 170 points

    Another question: if booting with HFCLK is not possible, why booting with SYSPLL (which itself is clocked by HFCLK) works?

    Is it because PLL is available and running as soon as MCU powers up, albeit not synchronised to the crystal clock (which is  [probably] not running at power up)?

  • 0 in reply to Dimo Dimov1
    TI__Mastermind 27665 points

    Hi Dimo,

    Dimo Dimov1 said:
    , why booting with SYSPLL (which itself is clocked by HFCLK) works?

    Where do you find the MSPM0G3507 can boot with SYSPLL?

    Or the booting stage you are refer to customize bootloader user defined, rather than MCU startup with ROM?

    B.R.

    Sal

  • 0 in reply to Sal Ye
    Prodigy 170 points

    Hi Sal, many thanks for attempting to demystify this .

    This configuration works. It fails if I attempt to direct HFCLK directly to MCU and when I disable PLL

    Kind Regards

    Dimo

  • 0 in reply to Dimo Dimov1
    Prodigy 170 points

    My thoughts are the PLL fires up and is available immediately whilst the HFCLK has a delay built in or my 10 cycles of HFXT Startup Time (increments of 64us) are delaying it. Even if PLL is not locked to crystal it still clocks the CPU at some clock which is enough to boot.

  • 0 in reply to Dimo Dimov1
    TI__Mastermind 27665 points

    Hi Dimo,

    The configuration in SysConfig tool is not for boot setting.

    It configure the MSPM0 peripheral per users requirement and call the initialization code after MCU boot and jump to main application code.

    Dimo Dimov1 said:
    It fails if I attempt to direct HFCLK directly to MCU and when I disable PLL

    I recommend you use the clock tree to configure the MCU clock system:

    Dimo Dimov1 said:
    My thoughts are the PLL fires up and is available immediately whilst the HFCLK has a delay built in or my 10 cycles of HFXT Startup Time

    The SysConfig should take care of this. It will start HFXT first and wait it for good (users should enable startup monitor), and then start PLL:

    B.R.

    Sal

  • 0 in reply to Sal Ye
    Prodigy 170 points

    Thanks Sal