Problems porting from KL27Z64 to KL17Z128 - cannot see interrupts

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Problems porting from KL27Z64 to KL17Z128 - cannot see interrupts

1,258件の閲覧回数
katieelliott
Contributor I

I'm in the middle of HW bring up on a custom board using the KL17Z128. We did initial development on the FRDM-KL27Z development kit and had everything working fine. Now that we've ported to the KL17Z, we've run into a problem where interrupts are not firing.

Even when we force a hard fault by dereferencing a null pointer, we cannot break in the hardfault ISR. When we halt execution, the code is indeed in the weeds, which is expected if we had a hardfault but didn't go to the ISR. We have also tried other interrupts and so far have not been able to get ANY interrupt to go to its ISR. The vector table and map file appear to be correct, with the vector table address pointing to the correct interrupt handler.

Any suggestions on what could be wrong?

Dev environment: Using IAR v7.70.2 with jlink debugger on Windows 10 and Windows7.

ラベル(2)
3 返答(返信)

1,095件の閲覧回数
kerryzhou
NXP TechSupport
NXP TechSupport

Hello Katie Elliott,

   This is the same question as case 00119803 which you created.

  Thank you for your interest in NXP Kinetis product, I would like to provide service for you.

KL17Z128 can't refer to FRDM-KL27 board, it should refer to the FRDM-KL43 board.
When KL17 flash larger than 128K, it should refer to FRDM-KL43 board, when the KL17 flash is lower than 64K, it should refer to FRDM-KL27 board.
About your attached code, I have test it on my FRDM-KL43.
1. when use *((uint32_t*)0) = 0; generate a hardfault.
  The code can enter without problem.
2. Your SysTick_Config(48000000); is wrong.
  As you know, the systick is just 24 bit counter.

__STATIC_INLINE uint32_t SysTick_Config(uint32_t ticks)
{
  if ((ticks - 1UL) > SysTick_LOAD_RELOAD_Msk)
  {
    return (1UL);                                                   /* Reload value impossible */
  }

  SysTick->LOAD  = (uint32_t)(ticks - 1UL);                         /* set reload register */
  NVIC_SetPriority (SysTick_IRQn, (1UL << __NVIC_PRIO_BITS) - 1UL); /* set Priority for Systick Interrupt */
  SysTick->VAL   = 0UL;                                             /* Load the SysTick Counter Value */
  SysTick->CTRL  = SysTick_CTRL_CLKSOURCE_Msk |
                   SysTick_CTRL_TICKINT_Msk   |
                   SysTick_CTRL_ENABLE_Msk;                         /* Enable SysTick IRQ and SysTick Timer */
  return (0UL);                                                     /* Function successful */
}

From the sysTick_config function, you can get that if your make ticks=48000000, it is larger than 0xffffff, then it will return 1, it won't configure the systick any more.
If I define it like this:
sysTick_Config(48000), the code will enter SysTick_Handler.
pastedImage_1.png

Now, describe your problem.
When you put a break point in code:
  SystemCoreClockUpdate();
Can you enter it?
Please also check your NMI pin, did you add a external 4.7K to 10K pull up?

Please check these points at first.

Besides, give me your chip full name!


Have a great day,
Kerry

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

1,095件の閲覧回数
kelliott
Contributor I

Further update. We created a tiny example project that exhibits the problem. Below is a screenshot of what happens after we trigger a hard fault (line 12). We never break in the hardfault ISR in startup_MKL17Z4.s (part of the SDK). When we halt the processor we are somewhere in the boot ROM.

pastedImage_1.png

0 件の賞賛
返信

1,095件の閲覧回数
mjbcswitzerland
Specialist V


Hi

Almost certainly you haven't set the vector base register to match your interrupt vectors or you haven't installed interrupt handlers. In such a case a hard fault will result in a second hard fault (unrecoverable) and thus provoke a reset - which ends up in the boot loader again.

If you have problems finding it, simply request a remote desktop session at http://www.utasker.com/services.html where the reasons can be identified and fix explained in few minutes. The first hour is always free so it won't cost you anything.

Regards

Mark

0 件の賞賛
返信