ASM_LABEL(no_one_to_run)

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

ASM_LABEL(no_one_to_run)

1,140 Views
Mit_3000GT_VR4
Contributor II

Hi,

I am running the hello world example on a TWR-K60N512 ( the device number: PK60N512VMD100  Date Code 0M33Z)

With IAR, I just rebuilt the lib. (twr_k60n512) and ran the example with a bit of modification.

In the task loop I have the following:

     for(;;){

          printf("\r Hello World %d",counter++);

         _time_delay(1000);

//         _task_block();

    }

Using the _time_delay(), I sometimes got to ASM_LABEL(no_one_to_run) and it stay there.  Sometimes it goes here after a couple of stop and go using the IAR debug.

Replace _time_delay() with _task_block(), I could see the mqx idle task runing.

My question:

1.     Am I using the right bsp package for my board?

2.     Is there any person having the same problem? if so please help with a fix (I had not seen this problem in previous mqx version)

3.     Should idle task runing during _time_delay ? (I have only one task, and I did have #define MQX_USE_IDLE_TASK        1 )

4.    Why would the idle task run with _tack_block() but not with _time_delay()

I put in another task I call lazyboy with the lower priority and have it do not thing( for the task loop I have for(;;); ) ; and I do not see the problem no matter how many time I try the stop and go)

4.    Is this the way to work around this problem?

Please Advice:smileysilly:

Tags (1)
0 Kudos
7 Replies

808 Views
daweiyou
NXP Employee
NXP Employee

Hi Tongle:

0M33Z is really V1.0 part, so twr_k60n512 is correct bsp.

no_one_to_run normally occurs when OS crash, idle task will run while your task give up control.

So try not change anything, just run original project to see what happened.

Dawei You(尤大为)

0 Kudos

808 Views
Mit_3000GT_VR4
Contributor II

Hi Dawei,

First, thanks for the response.

Second, thank you for confirm my package selection.  I had my application run with previous mqx version before but had to give up because of the flash size.

Third, yes I knew the OS crash.

Fourth, yes I knew the idle task will run when my task give up control. (so you implied that calling _task_block() my task give up the control but not _time_delay()?)

Question:

Please inform me the different between calling _task_block and _time_delay regarding giving up control or not?

Your answer does not answer my question, maybe you misunderstood.

0 Kudos

808 Views
daweiyou
NXP Employee
NXP Employee

Hi:

Call taskblock, your task can’t be wake up again, it have give up control anytime.

timedelay will make your task add into ready queue again after timeout.

Dawei You(尤大为)

0 Kudos

808 Views
Mit_3000GT_VR4
Contributor II

Thanks Dawei,

That is what I thought. But don't you think neither of them should make the OS crash?

0 Kudos

808 Views
Mit_3000GT_VR4
Contributor II

More over, why idle task ran when call _task_block() and not _time_delay()?

The only task, by calling _time_delay(), it is not ready to run again until timeout, where is the idle_task?

0 Kudos

808 Views
daweiyou
NXP Employee
NXP Employee

Hi:

I couldn’t say what’s the root cause.

The time_delay function register timeout notification, which is based on system tick,

So if no clear situation, it’s better to build original BSP and application to try, keep original code is clean.

Dawei You(尤大为)

0 Kudos

808 Views
Mit_3000GT_VR4
Contributor II

Hi,

I build the bsp as is, no modification.  It is only the example that I changed. I don't think, mqx is written for printing one line of "Hello world" one time.

Thanks for being honest, you don't know what the cause is.

Your information is text book accurate, but does not help.

Thanks

0 Kudos