• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 611 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: CLK_OUT triggers hard fault exception

Robert Chen
Mastermind 9115 points
Part Number: MSPM0G3507
Other Parts Discussed in Thread: MSPM0L1105

Hi there,

When I try to enable CLK_OUT function, the program triggers hard fault exception. The tested MCU is labeled with MSPM0G3507. Yes it is production silicon, not early sample. I also tested it with MSPM0L1105TDYYR got yesterday. The situation is the same.

Here is the test program:

void main()
{
	iomux_PA22_as_CLK_OUT(PINCM_OUTPUT);

	reg_SYSCTL.GENCLKCFG = SYSCTL_GENCLKCFG_EXCLKSRC_SYSOSC;

	reg_SYSCTL.GENCLKEN |= SYSCTL_GENCLKEN_EXCLKEN;

	while (1);
}

The code looks weird because I use my own driver library, not the SDK provided by TI. Please ignore the syntax, they are just simple register level operations. For MSPM0L1105, I also connect the CLK_OUT pinout to an oscilloscope. When the debugger steps over line-7, the oscilloscope shows 32MHz waveform immediately. But the program also jumps to hard fault exception handler right away.

If I don't use stepping debug and let it run free then the debugger can no longer connect to the target. I have to jump a wire from PA18 (with BSL_invoke) to VCC and power cycle. After the target is in BSL mode, the debugger can re-program it again.

Since I can see the SYSOSC clock is shown on the oscilloscope, the program code itself should be fine. So I think it could be a silicon bug. Some how the CPU clock becomes unstable at the moment when SYSOSC is routed to CLK_OUT.

Any idea?

Robert.

  • 0
    Expert 1330 points

    I hope TI will reply you soon. Till then you can study this datasheet to find a clue: https://www.ti.com/lit/ds/symlink/mspm0g3505.pdf

  • 0 in reply to Zain Nasir
    TI__Mastermind 39705 points

    Which pin you are using? Only HSIO can output the 32MHz clock.

    I would suggest to try to use the example code and divide the clock freq to below than spec requirement.

  • 0 in reply to Eason Zhou
    Mastermind 9115 points

    Thanks for your reply.

    For MSPM0L1105TDYY, the only pinout with CLK_OUT is PA22 which is SDIO, not HSIO. For MSPM0G3507SRHB, PA7, PA14 and PA22 are tested where PA14 is HSIO. But I don't think SDIO is an issue since SDIO should be able to run up to 32MHz with 3.3V VDD. In fact, I also tried different division ratio, all have the same issue.

    I will try to test TI example code "sysctl_mclk_syspll" today. 

    Robert.

  • 0
    Mastermind 9115 points

    Finally I found the root cause. It is not a silicon bug, it is a toolchain bug. The TI-Clang compiler doesn't generate correct code for "while (1);".

    In order to find the bug, I insert a __BKPT(0) instruction before "while (1); ". The following picture shows the disassembly:

    We can see the opcode on 0000:196a is "BE00 bkpt #0" that is correct. But the next line is garbage. This is why the hard fault exception is triggered.

    If I add a NOP instruction inside the while-loop

    void main()
{
	iomux_PA22_as_CLK_OUT(PINCM_OUTPUT);

	reg_SYSCTL.GENCLKCFG = SYSCTL_GENCLKCFG_EXCLKSRC_SYSOSC;

	reg_SYSCTL.GENCLKEN |= SYSCTL_GENCLKEN_EXCLKEN;

	while (1) {
	    asm(" nop");
    }
}

    then the disassembly becomes

    We can see the NOP opcode is added after "BE00 bkpt #0" and then a correct opcode "E7FD b #0x196c" is followed.

    So, it's no doubt a TI-Clang toolchain bug.

    Robert.

  • 0
    Mastermind 9115 points

    UPDATE: With further test, I found only TI-clang C++ compiler has the issue. The reason I encountered this issue but most people don't have the problem is because I always use C++ in my projects.