K20 pll_init() failed after reset in IAR EWW debugger

[kai_liu]

It is really wired.

OS: Windows XP

IDE: IAR EWW 6.70 & Keil MDK4.73

Interface: CMSIS-DAP debugger running on FRDM

Hardware: K20 custom board with external 8MHz

Source: kinetis_50MHz_sc\k20d50m_sc_baremetal\build\iar\serial_test_19200 and any other project.

• If I run code after loading in EWW, the code will run into main and start following steps.
• If I preset "reset" in EWW, the code runs away and stops only at pll_init().

From the very beginning, I thought it is crystal related issue. But when I found it acts in same manner every time, I got very confused.

The software chart

crt0.s -> start() in start.c

start()

     +--> sysinit()

     ...

     +--> main()

sysinit()

     +-> mcg_clk_hz = pll_init(CLK0_FREQ_HZ,LOW_POWER,CLK0_TYPE,PLL0_PRDIV,PLL0_VDIV,MCGOUT)

Before running pll_init()

MCG_C1 = 0x04

MCG_C2 = 0x80

MCG_C3 = 0x84

MCG_C4 = 0x0B

MCG_C5 = 0x00

MCG_C6 = 0x00

MCG_S = 0x10 (IREFST=1)

MCG_SC = 0x02

MCG_C7 = 0x00

MCG_C8 = 0x80

OSC0 = 0x00

1st running pll_init() after loading

MCG_C1 = 0x18 (red means changed after last step)

MCG_C2 = 0xA4

MCG_C3 = 0x84

MCG_C4 = 0x0B

MCG_C5 = 0x03

MCG_C6 = 0x61

MCG_S = 0x6E

MCG_SC = 0x02

MCG_C7 = 0x00

MCG_C8 = 0x80

OSC0 = 0x00

mcg_clk_hz = 50000000

Other running pll_init() after reset

MCG_C1 = 0x18

MCG_C2 = 0xA4

MCG_C3 = 0x84

MCG_C4 = 0x0B

MCG_C5 = 0x03

MCG_C6 = 0x61

MCG_S = 0x6E (OSCINIT0=1, CLKST=3,PLLST=1,LOCK0=1,LOLS0=0)

MCG_SC = 0x02

MCG_C7 = 0x00

MCG_C8 = 0x80

OSC0 = 0x00

mcg_clk_hz = 1

Then I checked the source in pll_init()

  // check if in FEI mode

  if (!((((MCG_S & MCG_S_CLKST_MASK) >> MCG_S_CLKST_SHIFT) == 0x0) && // check CLKS selcted FLL output

      (MCG_S & MCG_S_IREFST_MASK) &&                                  // check FLL ref is internal ref clk

      (!(MCG_S & MCG_S_PLLST_MASK))))                                 // check PLLS mux has selected FLL

  {

    return 0x1;                                                     // return error code

  }

I would rather is split the logic than the invert logic combination.

if (!((((MCG_S & 0x0C) >> 2) == 0x0) && (MCG_S & 0x10) && (!(MCG_S & 0x20)))) return 1;

if MCG_S_CLKST is FLL AND MCG_S_IREFST is internal AND MCG_S_PLLST is FLL are NOT TURE, return error. :smileysilly:

Basically only MCG_S = 0x10 as default after reset is allowed.

I have not idea why reset behaviors are different for loading code (reset and run to main by CMSIS-DAP) and manually reset in EWW IDE (MCG has not been reset into FEI mode, it still runs in PEE mode).

Conclusion

The code designs and runs in expected way. It should check current MCG mode and switch to desired mode. However why reset in debugger can not perform reset for MCG via DAP? It will bring extra difficulty in our development.

I have double checked reset in Keil MDK4.7x, the result is same. MCG keeps current status (PEE) rather than its reset default mode (FEI).

BTW

During my debug, my IAR broke down, it can not connect to my CMSIS-DAP and its license file is missing. I tried to download a new version of IAR. Its KS version reduces the code limitation from 32KB to 16KB for Cortex-M. However, re-installation of previous version can solve above issues and still offer 32KB code limation.

So keep your copy of previous IAR KS version is important ! Otherwise, part of the FSL code can not run anymore with IAR KS version.

[adriancano · Accepted solution]

Hi,

I tested the issue you are reporting and this is what I found. When you are using CMIS-DAP or some other debugger tools you have the option to configure the way of the reset when you perform it in the IDE; in IAR is when you press the reset button.

In the debugger options of the project you can change the way this reset is performed. If you select a software reset just the program counter is in reset state but the registers do not change. To ensure that all the registers change to their reset values you need to change the reset option for hardware reset.

I hope this information can help you.

Regards,

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. It would be nice!

-----------------------------------------------------------------------------------------------------------------------

[kai_liu]

Hi, Adrian,

Thanks for your information. That is an important configuration I never aware of.