Systick Timer and Debug Console with MQX_KSDK 1.3.0 + PEx in KDS 3.0.0

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

Systick Timer and Debug Console with MQX_KSDK 1.3.0 + PEx in KDS 3.0.0

Jump to solution
2,121 Views
Vagni
Contributor IV

I created my first MQX_KSDK project with PE on a TWR-K65F180M board following this great tutorial:

https://community.freescale.com/docs/DOC-103429

I am using KDS 3.0.0 and KSDK 1.3.0.

I selected MQX Standard in the MQX_KSDK Configuration parameters.

Now I see the systick timer is configured with a 5 ms period. I would like a 1 ms systick, but the systick timer (fsl_hwtimer) configuration is unchangeable. Why? It is not allowed to modify the fsl_hwtimer_InitConfig0 configuration nor to add a new one.

In the fsl_hwtimer1.h file generated by PEx the macro FSL_FSL_HWTIMER1_PERIOD_CNF0 is set to 5000: I think the systick timer period in microseconds is set with this macro, right?

Is manually changing that macro the only way to get the desired systick period for MQX RTOS component ?

The MQX RTOS component also inherits one UART as debug console.

What if my custom board has no available UART to assign as debug console?

I think it is better a RTOS componenet that inherits only the systick timer with a changeable configuration (tick period) and optionally a debug console UART (which is already configurable in baud rate and hardware pins; but what if I have only a RS485 serial port on my custom board?)

0 Kudos
1 Solution
1,177 Views
DavidS
NXP Employee
NXP Employee

Hi Alessandro,

Let me answer your questions first then I will add a comment or two.

Q1) In the fsl_hwtimer1.h file generated by PEx the macro FSL_FSL_HWTIMER1_PERIOD_CNF0 is set to 5000: I think the systick timer period in microseconds is set with this macro, right?

A1) No and yes ;-).  No that the this is not the correct method to modify the systick timer period and yes it is a MACRO PE generates.  But for MQX it is not used!  Go figure...

Q2) Is manually changing that macro the only way to get the desired systick period for MQX RTOS component ?

A2) The answer would be yes if the macro were used...but it is not for MQX.  If it were being used by MQX then you could have manually changed it and then disabled the fsl_hwtimer from Code Generation by right clicking the component and saying "Don't write Generated Component Modules".  But since this macro is not used you don't need to do that.

Q3) The MQX RTOS component also inherits one UART as debug console.

What if my custom board has no available UART to assign as debug console?

A3) when you use KSD/KSDK+PE and select MQX as the RTOS, you want to remove the fsl_debug_console Component as it is not needed with MQX.  Then in the wizard for the MQX_KSDK Component, have the Inherited components debug console select "KSDK 1.3.0/fsl_uart".  You can then configure that fsl_uart Component to use whatever UART you want.

Comment:

No idea why PE wouldn't be used to change the systick value.  Maybe next release of KDS/KSDK will allow that.

To change the systick to 1ms do the following:

In bsp_config.h make the following modifications:

#ifndef BSP_ALARM_FREQUENCY

    #define BSP_ALARM_FREQUENCY             (1000) //DES was (200)

#endif

/*

* HWTimer period

*/

#ifndef BSP_ALARM_PERIOD

    #define BSP_ALARM_PERIOD             (1000) //DES was (5000)

#endif

Do a clean, re-compile, then debug.

Regards,

David

View solution in original post

0 Kudos
4 Replies
1,178 Views
DavidS
NXP Employee
NXP Employee

Hi Alessandro,

Let me answer your questions first then I will add a comment or two.

Q1) In the fsl_hwtimer1.h file generated by PEx the macro FSL_FSL_HWTIMER1_PERIOD_CNF0 is set to 5000: I think the systick timer period in microseconds is set with this macro, right?

A1) No and yes ;-).  No that the this is not the correct method to modify the systick timer period and yes it is a MACRO PE generates.  But for MQX it is not used!  Go figure...

Q2) Is manually changing that macro the only way to get the desired systick period for MQX RTOS component ?

A2) The answer would be yes if the macro were used...but it is not for MQX.  If it were being used by MQX then you could have manually changed it and then disabled the fsl_hwtimer from Code Generation by right clicking the component and saying "Don't write Generated Component Modules".  But since this macro is not used you don't need to do that.

Q3) The MQX RTOS component also inherits one UART as debug console.

What if my custom board has no available UART to assign as debug console?

A3) when you use KSD/KSDK+PE and select MQX as the RTOS, you want to remove the fsl_debug_console Component as it is not needed with MQX.  Then in the wizard for the MQX_KSDK Component, have the Inherited components debug console select "KSDK 1.3.0/fsl_uart".  You can then configure that fsl_uart Component to use whatever UART you want.

Comment:

No idea why PE wouldn't be used to change the systick value.  Maybe next release of KDS/KSDK will allow that.

To change the systick to 1ms do the following:

In bsp_config.h make the following modifications:

#ifndef BSP_ALARM_FREQUENCY

    #define BSP_ALARM_FREQUENCY             (1000) //DES was (200)

#endif

/*

* HWTimer period

*/

#ifndef BSP_ALARM_PERIOD

    #define BSP_ALARM_PERIOD             (1000) //DES was (5000)

#endif

Do a clean, re-compile, then debug.

Regards,

David

0 Kudos
1,177 Views
rajbatra
Contributor IV

Hi David,

There are two bsp_config.h files. One in my project which when I change, gives me the 1kHz clock, but there is also one located in rtos/mqx/mqx/source/bsp. Are we to change this and rebuild mqx and other libraries (mqx_stdlib, rtcs, usb, etc.)? I ask only because there is a document entitled 'Using the MQX Timers.pdf' (Using the MQX timers ) that points to the mqx path version of bsp_config.h

Also, they note the following: 

"In conclusion if you want to have smaller ticks it is necessary to modify the BSP_ALARM_FREQUENCY value, however it is necessary to remember, we cannot guarantee the correct behavior if you modify original settings. Some of drivers, for example USB, Ethernet PHY, ESDHC, etc, use commands like _time_delay; if the resolution is changed then we could get unexpected behavior of these drivers."

Is this something that has occurred with these drivers?

Thanks,

-Raj

0 Kudos
1,177 Views
Vagni
Contributor IV

Thank you David.

OK for systick value.

About MQX debug console.... OK, I can select and configure whatever UART I want in the MQX_KSDK Component wizard. But to have a debug console in a MQX application developed with KSDK is mandatory? It seems the wizard does not let me have no debug console, because the debug console is an inherited component.... The inherited components must always exist and be properly configured?

0 Kudos
1,177 Views
DavidS
NXP Employee
NXP Employee

Hi Alessandro,

Short answer to MQX debug console is yes it is required and I too wish there was a check to disable.

Regards,

David

0 Kudos