AnsweredAssumed Answered

KL15Z128VFT4 Arm M0+ SysTick Issue

Question asked by Jonathan Guinta on Feb 18, 2016
Latest reply on Feb 22, 2016 by Hui_Ma

Hi,

 

I'm in the process of getting my bootloader to application portion of code working and I've been having issues after writing FW from an external SPI flash to the internal uC via the C90TFS driver. I checked and it appears all of the data is being transferred correctly from my SPI flash to my internal uC program memory. I've set up the linker files for the booloader and application to to be as such:

 

Bootloader:

MEMORY {

  m_interrupts          (RX)  : ORIGIN = 0x00000000, LENGTH = 0x00000200

  m_flash_config        (RX)  : ORIGIN = 0x00000400, LENGTH = 0x00000010

  m_interrupts_ram      (RW)  : ORIGIN = 0x1FFFF000, LENGTH = 0x00000200

  m_text                (RX)  : ORIGIN = 0x00000410, LENGTH = 0x0001FBF0

  m_data                (RW)  : ORIGIN = 0x1FFFF200, LENGTH = 0x00003DFC

  m_comm                (RW)  : ORIGIN = 0x20002FFD, LENGTH = 0x00000003

}

Application:

MEMORY {

  m_interrupts          (RX)  : ORIGIN = 0x00007800, LENGTH = 0x00000200

  m_interrupts_ram      (RW)  : ORIGIN = 0x1FFFF000, LENGTH = 0x00000200

  m_flash_config        (RX)  : ORIGIN = 0x00008000, LENGTH = 0x00000010

  m_text                (RX)  : ORIGIN = 0x00008010, LENGTH = 0x00017FEF

  m_data                (RW)  : ORIGIN = 0x1FFFF200, LENGTH = 0x00003DFC

  m_comm                (RW)  : ORIGIN = 0x20002FFD, LENGTH = 0x00000003

}

 

I can successfully make the jump from the bootloader to the application portion of the code if I program the application and bootloader using the j-link debugger tool. However, my issue arises when I make the jump after completing the FW update. I'm using the BareMetal OS with the SysTick timer. Before making the jump from the bootloader to application portion of code, I set these registers:

 

//Disable OSA timer and interrupt
SysTick->CTRL = 0U;
/* A write of any value to current value register clears the field to 0, and also clears the SYST_CSR COUNTFLAG bit to 0. */
SysTick->VAL = 0U;

 

I set my app stack pointer to address 0x7800. SCB->VTOR = 0x7800.

I set my boot address to 0x7804 - where the Reset_Handler is.

 

When I step through my application portion of the code, an exception is thrown when I get to the OSA_TimeInit function where I set the divider value

 

void OSA_TimeInit(void)

{

  uint64_t divider;

 

  /* Disable timer and interrupt */

  SysTick->CTRL = 0U;

  /* A write of any value to current value register clears the field to 0, and also clears the SYST_CSR COUNTFLAG bit to 0. */

  SysTick->VAL = 0U;   

#if FSL_FEATURE_SYSTICK_HAS_EXT_REF

    /* Set the clock source back to core freq */

    CLOCK_SYS_SetSystickSrc(kClockSystickSrcCore);

#endif 

  /* Get SysTick counter input frequency and compute divider value */ 

  divider = ((((uint64_t)CLOCK_SYS_GetSystickFreq() * OSA1_TIMER_PERIOD_US)) / 1000000U);

  assert(divider != 0U);

  /* Set divide input clock of systick timer */

  SysTick->LOAD = (uint32_t)(divider - 1U);

  /* Set interrupt priority and enable interrupt */ 

  NVIC_SetPriority(SysTick_IRQn, 1U);

  /* Run timer and enable interrupt */

  SysTick->CTRL = (SysTick_CTRL_CLKSOURCE_Msk | SysTick_CTRL_ENABLE_Msk | SysTick_CTRL_TICKINT_Msk); 

}

 

The actual issue is that the g_slowInternalRefClkFreq is returning a value of 0xFFFFF... instead of the value it should have of  32768U (0x800000). Does anyone know why this would be happening? Why the slow internal Ref clock frequency would be this value? I was checking the .map file and the global is located at this address:

.data.g_slowInternalRefClkFreq

                0x1ffff22c        0x4 ./SDK/platform/hal/src/mcg/fsl_mcg_hal.o

                0x1ffff22c                g_slowInternalRefClkFreq

 

also looking at the .map file, the data starts at 0x1FFFF200 is loaded from 0x00017404 address and so I did a memory monitor and checked the value at offset 0x2C (ie 0x00017430) and the correct value is stored for g_slowInternalRefClkFreq of 0x800000 ( 32768U) before I make the jump. If I step through the code, the values load correctly from the application code program rom to ram. If I make a debugger jump to another breakpoint, it 'appears' there's an issue setting the SysTick clock.

 

Outcomes