Kinetis Software Development Kit中的主题 Re: SDK Real-time clock adaptation hanging after running cmd_get_datetime

SDK Real-time clock adaptation hanging after running cmd_get_datetime

piotrcerba — Thu, 01 Oct 2015 22:18:34 GMT

Hello, in this thread Unable to use an RTC example - source files missing in KDS 3.0 thanks to Jorge Gonzalez I managed to successfully build a project adopting majority of code from SDK example for RTC.

Now I have encountered another problem.

When I debug the SDK example after calling

cmd_get_datetime();

it goes for the following calls:

RTC_DRV_GetDatetime(0, &date);

Then:

RTC_HAL_GetDatetimeInSecs(RTC_Type *rtcBase, uint32_t * seconds)

RTC_HAL_GetSecsReg(RTC_Type *rtcBase)

And from 3. it calls

RTC_RD_TSR(rtcBase);

Stepping into 4. returns the debugger up to point 2.

Everything works OK.

However, in my application putting same (with all preceeding initializations copied from SDK example):

cmd_get_datetime();

After identical jumps to 1, 2, 3 and 4 it jumps to one more file startup_MKL43Z4.S

where it loops infinitely around the following fragment of assembly code (ldr and bx):

DefaultISR:     ldr r0, =DefaultISR     bx r0     .size DefaultISR, . - DefaultISR

So the behaviour differs from original SDK example, where after calling RTC_RD_TSR(rtcBase); it immediately returns to the calling function.

Do you have any idea what might be causing it?

Why does it enter a section concerning some DefaultISR, if I do not trigger any interrupt?

Re: SDK Real-time clock adaptation hanging after running cmd_get_datetime

piotrcerba — Mon, 02 Nov 2020 13:20:19 GMT

After searching for USB0_IRQHandler I found a topic with identical observation MK2251212_features.h error? USB IRQ Location? , despite the fact that mr Donald Bosley was using DMA and some USB functionalities and I am not.

In my case after thorough debugging session I managed to find that not necessarily

cmd_get_datetime();

is causing trouble.

The first line causing problems is the call to

hardware_init();

which has the following body:

void hardware_init(void) {
  /* enable clock for PORTs */
  CLOCK_SYS_EnablePortClock(PORTA_IDX);//This line does NOT cause error
  CLOCK_SYS_EnablePortClock(PORTC_IDX);//This line does NOT cause error
  CLOCK_SYS_EnablePortClock(PORTD_IDX);//This line does NOT cause error
  /* Init board clock */
  BOARD_ClockInit();//These DO
  dbg_uart_init();//These DO
}

and the BOARD_ClockInit(); and dbg_uart_init() are the lines causing the jump to the Default interrupt, leading to an infinite loop.

My guess is that the ISR vector table is somehow wrong. Am I right? If yes - how to fix it?

NOTE: I do not use UART (it seems that the error is connected with it)

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

EDIT: I found this in SDK FAQ:

I’m trying to use a driver and keep falling into the default ISR in startup_<mcu>.s
Make sure to include an interrupt handler for the peripheral you’re using inside your project. By default, all the peripheral IRQ handlers go into a default handler that does an infinite branch. The easiest way to fix this issue is to add the C:\Freescale\KSDK_1.2.0\platform\drivers\src\<drivername>\fsl_<drivername>_irq.c file inside your project.

I placed fsl_rtc_irq.c in my Project folder, however this did not change the behaviour. Application is still jumping to infinite Default IRQ. What am I doing wrong?

EDIT2:

Relocating vectors to RAM

from "Interrupt_handling_KSDK.pdf" also did not help. Program still goes to USB0_IRQHandler.

Maybe I should add some of the Cross ARM C Linker -> Miscellaneous -> Other linker flags from the working SDK RTC example?

They are as follows:

-Xlinker -z -Xlinker muldefs --specs=nano.specs -Wall -fno-common -ffunction-sections -fdata-sections -ffreestanding -fno-builtin -Os -mapcs -Xlinker -static -Xlinker --defsym=__stack_size__=0x2000 -Xlinker --defsym=__heap_size__=0x2000

^ I have checked them, and with this linker flags the project does not compile.

After performing the steps from Edit1 and Edit2 the program again "crashes" with the call to cmd_get_datetime()

hardware_init(); does not cause the jump to Default ISR now.

Re: SDK Real-time clock adaptation hanging after running cmd_get_datetime

Jorge_Gonzalez — Mon, 05 Oct 2015 23:36:48 GMT

Hello Piotr Cerba:

At the beginning you mentioned "...adopting majority of code from SDK example for RTC".

What do you mean with majority? Could you post your project so I can give it a check?

In case it is useful I attached the standalone version of the demo rtc_func_frdmkl43z.

About your edits and the steps I took to create the project:

- EDIT1: That is true, for most projects you need to pull the fsl_<module>_irq.c file, but in this case the functions in fsl_rtc_irq.c are different from those of the demo, defined in main.c. So you can remove the file and use the same functions as in main.c.

- EDIT2: For MQX it is required to have vectors in RAM so you can install interrupt handlers. For a baremetal application it is not strictly required.

- Copy the linker flags and change the language (in Cross ARM C Compiler -> Optimization) to GNU ISO C99(-std=gnu99).

Let me know about any doubts.

Regards!

Jorge Gonzalez