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.

MSPM0G3507-Q1: External Crystal requirements

Part Number: MSPM0G3507-Q1
Other Parts Discussed in Thread: SEGGER, UNIFLASH

Tool/software:

Hi guys,

we build a new prototype board with MSPM0G3507-Q1. We want to use an external 24 MHz crytal. I did not saw any requirements for the choice of the crystal in the HW Design guide, like drive level etc.

We use the XRCGE24M000FBA1AR0 from Murata with the following Caps

Are there no requirements for this MCU regarding to the crystal like drive level?

We have the following problem if I configure the Clock tree in CCS with the following configuration

and activate it in SYSCTL

I can flash the MCU one time and then i get the following error

Trouble Writing Register PC: Error occured in writeRegister()!.

When I try to flash a second time then it is not flashable and the Debug Output brings the following message

We flash with Segger JLINK. When i just use the internal oscillator I have no problems, but the crystal does not go hot or anything.

I then have to unsolder the MCU because I don't know how to restore it to its original state. I think the controller is not damaged just in an unflashable state.

I look forward to hearing from you soon.

Thanks.

Kind regards

Dominik Maier

  • Hi Dominik,

    The crystal probably doesn't have a long enough start time, start with a couple milliseconds or more then reduce the start-up time until if fits your application. Capacitors on the crystals also matters yours looks very small, you can reference this Crystal Oscillators Document (its written for MSP430 and low frequency but the ideas apply the same).

    I would try 14pF capacitors and increase your start up time.

    • To recover your MCU you will need to hold down the NRST and BSL invoke, then when programming release NRST and then BSL.
      • This will get you into the BSL mode and allow the device to be reprogrammed
      • The cause to your situation is because of the misconfigured clock, when the application program starts and it enables the clock it gets into the erroneous state. By doing BSL invoke you won't enter your application code and the MCU will use our internal SYSOSC which will allow you to flash the device, thereby "recovering" the device..

    Regards,
    Luke

  • Hi Luke,

    thanks for the tip. You are right I made a mistake with the capacitors. I correct this issue. I used the method you mentioned (BSL invoke method) and it still does not work.

    The process was: Pull BSL invoke and Reset to GND and release first Reset and BSL while /before flashing.

    I got the same error like before (Can't connect to target). I had to remove the microcontroller. Another error which I got is "Trouble Reading Register PC: Cannot read register 15 (R15) while CPU is running". I dont know what is the problem here.

    Could I use the XDS110 Debug probe to make a factory reset?

    I look forward to hearing from you soon.

    Kind regards

    Dominik Maier

  • Okay BSL invoke mode was successful now. The Controller is flashable again, but does not work properly. The controller is just booting when I am in debug mode CCS. Is it because of the invoke mode?

  • Hi Dominik,

    Can you program the gpio_toggle_output example and let me know if the device still behaves unexpectedly?

    The GPIO toggle is to get the MCU to a good known state. You can use the XDS110 and our tools to do a factory reset, either through uniflash or CCS. There is also the factory reset tool https://dev.ti.com/gallery/view/TIMSPGC/MSPM0_Factory_Reset_Tool/ver/1.0.2/ 

    Regards,
    Luke