i.MX ProcessorsのトピックRe: FreeRTOS configUSE_TICKLESS_IDLE

FreeRTOS configUSE_TICKLESS_IDLE

ffloree — Wed, 30 May 2018 19:32:53 GMT

Hi,

I'm using MIMXRT1051CVL5B with latest SDK (SDK_2.3.1_EVKB-IMXRT1050), but when i enable configUSE_TICKLESS_IDLE feature, and run example project SDK_2.3.1_EVKB-IMXRT1050\boards\evkbimxrt1050\rtos_examples\freertos_tickless, freeRTOS will crash when wait by VTaskDelay(), and jump to unknown address (0x50xxxxxx), i have tried others projects in SDK like power_mode_switch, it's the same, what's the matter? see attached picture, thanks!

Re: FreeRTOS configUSE_TICKLESS_IDLE

ffloree — Wed, 30 May 2018 20:29:30 GMT

some day's ago, i worked on RT1051DVL6A with previous SDK (SDK_2.3.0_EVK-MIMXRT1050), configUSE_TICKLESS_IDLE feature works. My project source code has the same phenomenon, so i verified on NXP SDK source code, unfortunately, it also has the same issue.

Re: FreeRTOS configUSE_TICKLESS_IDLE

Carlos_Musich — Thu, 31 May 2018 17:36:35 GMT

Hi tom,

If you take a look into i.MX RT1050 Evaluation Kit|NXP > BUY/PARAMETRICS tab, you will find that there are 2 versions of the i.MXRT Evaluation Kit

- i.MXRT1050-EVK which uses Silicon Rev A0

- i.MXRT1050-EVKB which uses Silicon Rev A1

There are important changes (mainly in clocks) that you can find in Errata https://www.nxp.com/docs/en/errata/IMXRT1050CE.pdf

Now, SDK2.3.0 was developed to work with Silicon Rev A0, SDK2.3.1 and SDK2.4 are inteded to work with Silicon Rev A1. If you are using a SDK with the incorrect Silicon Rev you will face this kind of issues.

You can find more information here: https://community.nxp.com/docs/DOC-340660

Regards,

Carlos

Re: FreeRTOS configUSE_TICKLESS_IDLE

ffloree — Thu, 31 May 2018 21:49:20 GMT

Thanks Carlos,

I know what you said, but I really foundd this issue in silicon A1 with SDK 2.4 and 2.3.1, I also updated some clock settings according to migration guide AN12146, just some clock default status should set to enable.

could you help to check the SDK and EVK board?

Re: FreeRTOS configUSE_TICKLESS_IDLE

ffloree — Thu, 31 May 2018 22:16:40 GMT

by the way, BOARD_BootClockRUN() always waiting for DCDC_REG0_STS_DC_OK_MASK to be set 1, our board connects VDD_SOC to 1.2V power and DCDC_REG0_STS_DC_OK_MASK is always 0, so i commented out this waiting condition, does it result in this issue? could you look at the picture?

Re: FreeRTOS configUSE_TICKLESS_IDLE

Carlos_Musich — Tue, 12 Jun 2018 22:11:43 GMT

Hi tom,

I am sorry for the delay. I just have ran the freertos_tickless example with MCUXpresso + SDK2.4 + IMXRT-EVKB and it worked fine. So I find most likely that the differences you mention in your last message could be affecting the example behavior because they are intended to work with IMXRT1050-EVKB as is.

Please note that if you are using the SDK2.4 examples you dont need to make any clock adjustments. SDK2.4 already consider the new clock settings required for IMXRT1050-EVKB.

AN12146 is intended to help developers who have a significant progress in a project using Silicon Rev A0 and now they have to move that project to Silicon RevA1, but not to be used with SDK2.4 projects.

Regards,

Carlos

Re: FreeRTOS configUSE_TICKLESS_IDLE

ffloree — Wed, 13 Jun 2018 21:10:57 GMT

could you change the DCDC_REG3_TRG to (0x10) and try?, it will set VDD_SOC_IN to 1.2v, you will find this issue.

Re: FreeRTOS configUSE_TICKLESS_IDLE

ffloree — Fri, 15 Jun 2018 18:11:57 GMT

update steps as below, it makes the issue more detailed:

I got the SDK_2.4.0_EVKB-IMXRT1050 source code and EVKB board, and run sample project SDK_2.4.0_EVKB-IMXRT1050\boards\evkbimxrt1050\rtos_examples\freertos_tickless (see details in emails below),

Everything is fine, but when I changed VDD_SOC_INx to 1.2v by setting DCDC_REG3 (see below code and schematic), sleep mode made system crashed.

The best important thing is that EVKB board never works fine once sleep mode crashed, whatever set VDD_SOC_Inx to 1.25v, 1.2v or 1.5v, it’s consistent, sleep mode always crashed! Never works again.

Re: FreeRTOS configUSE_TICKLESS_IDLE

Carlos_Musich — Fri, 15 Jun 2018 22:44:53 GMT

Hi tom,

I found something really strange today.

I have here 2 iMXRT1050-EVKB boards. One is SCH-REV A1 and the other is SCH-REV A2.

When I tried with SCH-REV A1 it failed once and I was not able to program it again. SCH-REV A2 works always. I need to do deeper investigation.

Regards,

Carlos

Re: FreeRTOS configUSE_TICKLESS_IDLE

ffloree — Tue, 19 Jun 2018 02:49:52 GMT

Thanks Carlos, my iMXRT1050-EVKB board wasn't able to be programmed either.

Re: FreeRTOS configUSE_TICKLESS_IDLE

Carlos_Musich — Tue, 19 Jun 2018 22:17:33 GMT

Hi tom,

I have to report this issue as a bug to the development team. Because every time I run freertos_tckless demo the IMXRT1050-EVKB gets stuck.

However we found a way to unblock it:

1) Change SW7 config to 0,0,1,0 (running from QSPI)

2) Program any SDK2.4 example (lets say helloworld)

3) MCUXpresso will program helloworld example in hyperflash, however debug session will be lost as it will try to find the code in hyperflash.

4) Change SW7 config to 0,1,1,0 (running from HyperFlash)

5) IMXRT1050-EVKB is able to run again!

NOTE: If you want to debug you need to reboot MCUXpresso.

Regards,

Carlos

Re: FreeRTOS configUSE_TICKLESS_IDLE

ffloree — Wed, 20 Jun 2018 05:12:09 GMT

Thanks Carlos, but we need to know the root cause and solution, we verified it in IMXRT1050-EVKB since we don't know whether it only happened in our board or something wrong in MCU, and help you to reproduce this issue, so how to fix it by a workaround, it isn't necessary for us, but very appreciated that you can do so many things, and thank you for reporting this issue to development team.

up to now, you just only found IMXRT1050-EVKB stuck issue? did you find sleep mode crash issue?

please refer to my steps:

Open the latest SDK project (SDK_2.4.0_EVKB-IMXRT1050\boards\evkbimxrt1050\rtos_examples\freertos_tickless)
Build and run the project (excluding fsl_tickless_gpt.c, but using fsl_tickless_systick.s. I also tried fsl_ticless_gpt.c to build, it’s the same)
Stop at here then run over vTaskDelay(), it makes system enter sleep mode and also crashed, sometimes I found it crashed at __WFI() in function vPortSuppressTicksAndSleep()

Re: FreeRTOS configUSE_TICKLESS_IDLE

Carlos_Musich — Wed, 20 Jun 2018 21:11:34 GMT

Hi tom,

I have escalated this case to the applications team, now it is on their side, but I will push to get an answer as fast a possible.

What I can tell is that most likely the issue is about the clocks incompatibilities between Silicon RevA0 and RevA1. This effect can be caused by some clock features that were carried from SDK2.3.0 and were not updated to work with the new silicon revision. I am almost certain on this because I tried with silicon Revision A0 and it worked fine, so probably you may find useful information in the following documents:

https://www.nxp.com/docs/en/nxp/application-notes/AN12146.pdf

https://community.nxp.com/docs/DOC-340660

I will keep you in the loop.

Regards,

Carlos

Re: FreeRTOS configUSE_TICKLESS_IDLE

ffloree — Thu, 21 Jun 2018 00:40:17 GMT

Thank you, yes, I agree, silicon A0 works fine.

Re: FreeRTOS configUSE_TICKLESS_IDLE

Carlos_Musich — Thu, 28 Jun 2018 18:42:11 GMT

Hi tom,

As I told before I have reproduce the issue and I have reported it to applications team. They have not been able to reproduce it but I think they are using different version of tools. I will come back to you when they have reproduced and solved the problem.

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

Re: FreeRTOS configUSE_TICKLESS_IDLE

Carlos_Musich — Thu, 12 Jul 2018 17:20:42 GMT

Hi tom,

it looks like the issue disappears after setting following macro:

#define configMINIMAL_STACK_SIZE ((unsigned short)900)

The original value is 90.

Please try and let me know how it goes.

Re: FreeRTOS configUSE_TICKLESS_IDLE

ffloree — Fri, 20 Jul 2018 02:08:20 GMT

I'll try it, but I don't understand there are any relationship between the voltage setting and stack size.

Re: FreeRTOS configUSE_TICKLESS_IDLE

ffloree — Fri, 20 Jul 2018 03:18:54 GMT

Hi Carlos,

1. If you set configMINIMAL_STACK_SIZE=900, it makes system memory allocation failed

2. I set configMINIMAL_STACK_SIZE=300, it's still failed as before, and i checked the stack usage of idle thread by IAR, it's very very small, the default setting 90*4 bytes is absolutely enough.

so configMINIMAL_STACK_SIZE size isn't the root cause i think.

Re: FreeRTOS configUSE_TICKLESS_IDLE

Carlos_Musich — Wed, 25 Jul 2018 21:50:41 GMT

Hi tom,

The latest founding is, what you see is expected, as this code would put CPU in low power mode. In this condition, CPU cannot be connected by SWD again.

one way to avoid this is to modify the code:

PRINTF("Tickless Demo example, \r\n");

to be:

PRINTF("Tickless Demo example, press any key to continue\r\n");
GETCHAR();

then, after reset, the project can be downloaded again.

Regards,

Carlos

Re: FreeRTOS configUSE_TICKLESS_IDLE

ffloree — Fri, 27 Jul 2018 08:47:10 GMT

Hi Carlos,

1. my code doesn't run in EVKB flash, but in internal RAM, so if CPU is in low power mode, but after reset, it should not be low power mode again.

2. even though CPU can't be woke up by SWD, but isn't it able to be woke up by any resource either? Tickless_task() never run again. Normally, it should be run over and over again every each 5s. see attached image

3. change the code as you said, are there any effects? it's in main(), and not yet start any tickless thread.

see result, you can find Tickless_task() never be run second time

I think you have known below:

1. before voltage changing, tickless function works

2. on Silicon Rev A0, tickless function works

so I think there must be something wrong about MCU modules/clock settings or board voltage, but not software functionality changing.

BR,

Tom