KL17 Crashes When Setting Master Mode in Kinetis Studio Debug

[rbowen]

Using Kinetis Studio 3.2.0.

Using OpenOCD to flash/debug the KL17.

When using a Debug build the following line of code causes unexpected execution and hard faults. 

I2C0->C1 |= I2C_C1_MST_MASK;

When using a Release build this does not occur. 

Any ideas on what the root cause of this.  

[kerryzhou]

Hi Ryan Bowen,

    Before you do the I2C0 operation, did you enable the I2C0 clock gate?

   Please check register SIM_SCGC4[I2C0], you need to enable it, otherwise, when you do the I2C0 operation, the mcu will enter hardfault.

Wish it helps you!

If you still have question, please let me know!

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[rbowen]

Kerry,
Yes I have enabled the clock gate and clock source. For clarification below is my init code for both modules. I have the 48 pin package of the KL17. 

SIM->SCGC5 |= SIM_SCGC5_PORTE_MASK | SIM_SCGC5_PORTA_MASK | SIM_SCGC5_PORTC_MASK;
PORTE->PCR[24] = PORT_PCR_MUX(0x5u);
PORTE->PCR[25] = PORT_PCR_MUX(0x5u);
PORTC->PCR[1] = PORT_PCR_MUX(0x2u);
PORTA->PCR[4] = PORT_PCR_MUX(0x2u);
PORTE->PCR[24] &= ~(PORT_PCR_PE_MASK);
PORTE->PCR[25] &= ~(PORT_PCR_PE_MASK);
PORTC->PCR[1] &= ~(PORT_PCR_PE_MASK);
PORTA->PCR[4] &= ~(PORT_PCR_PE_MASK);
SIM->SCGC4 |= SIM_SCGC4_I2C0_MASK | SIM_SCGC4_I2C1_MASK;
I2C0->F = I2C_F_MULT(0x00) | I2C_F_ICR(0x18);
I2C1->F = I2C_F_MULT(0x00) | I2C_F_ICR(0x18);
I2C0->C1 = I2C_C1_IICEN_MASK;
I2C1->C1 = I2C_C1_IICEN_MASK;

Some time later I attempt to enter master mode to generate a start condition. The same code runs in Release does not hard fault. Debug crashes with or without any breakpoints. I have used this code in KEIL without any issue, when run in Kinetis Studio under debug there are problems. 

I2C0->C1 |= I2C_C1_MST_MASK;

The issue appears to be isolated to I2C0, as the following is fine in Debug and Release modes.

I2C1->C1 |= I2C_C1_MST_MASK;

[kerryzhou]

Hi Ryan Bowen,

     If you are convenient, please attached your problem project. You can delete the code which you think is important to you, just leave the I2C code which can reproduce the problem.

    Please tell me the full name of your chip.

    I need to check it on my side.

Waiting for your reply!

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[rbowen]

I have stripped down a project to just the bare essentials all application code is included in main.c

Attached is the archived project. 

I am referencing KSDK_2.1.0_GA.

I have highlighted the problem line in function I2C_ping contained in main.c.

I am very curious if you are able to duplicate this issue. 

[kerryzhou]

Hi Ryan Bowen,

     I have test your attached project directly on my side.

    It works ok on my side, no hardfault happens no matter I use breakpoint or without the break point in the debug mode.

   This is my test wave:

   You can try to clean the project, then build again and test it.

   Besides, you also can refer to this post:

Debugging Hard Faults on ARM Cortex-M | MCU on Eclipse 

   To check what is the root code which caused enter in the hardfault.

   Please also check your chip part number, the project you give me is used for:

**     Processors:          MKL17Z128VFM4
**                          MKL17Z128VFT4
**                          MKL17Z128VLH4
**                          MKL17Z128VMP4
**                          MKL17Z256VFM4
**                          MKL17Z256VFT4
**                          MKL17Z256VLH4
**                          MKL17Z256VMP4
**

Not for KL17 32K and 64K flash chip.

Wish it helps you!

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mjbcswitzerland]

Ryan

In order to identify hard fault problems you should step the failing code in disassemble mode. You will get to a line that hard faults and you can check the assembler code to see which address was written/read. This is usually seen as [r0] for example, where the value in r0 is the pointer.
There are 4 possibilities:
- the pointer is misaligned (not an issue on m4 parts but causes hard fault on m0+). Eg. a long word access to an uneven address
- the access to a byte register is being performed as a word (too wide)
- the memory doesn't exist (bad pointer)
- the peripheral register being accessed is not enabled (clock missing)

The first 3 should be obvious and then the reasons for the difference can be seen by repeating/comparing with operational  and non-operational code.

In the 4th case use the peripheral register display to see whether the debugger can access the registers. If it can't the peripheral is probably not powered up.

Your case is strange since optimised code tends to fail in some cases whereas 'debug' - non-optimised code - has less risk, and therefore I don't have any suggestion as to what causes it but using the technique above it should become obvious with a few minutes work. I have used the technique hundreds of times and typically the reason is identified almost immediately.

Regards

Mark