SDK Real-time clock adaptation hanging after running cmd_get_datetime

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SDK Real-time clock adaptation hanging after running cmd_get_datetime

1,011 Views
piotrcerba
Contributor III

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:

1.

RTC_DRV_GetDatetime(0, &date);

Then:

2.

RTC_HAL_GetDatetimeInSecs(RTC_Type *rtcBase, uint32_t * seconds)

3.

RTC_HAL_GetSecsReg(RTC_Type *rtcBase)

And from 3. it calls

4.

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?

Labels (1)
Tags (3)
0 Kudos
2 Replies

533 Views
piotrcerba
Contributor III

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)

Capture9.PNG

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

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.

0 Kudos

533 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

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

0 Kudos