MQX on custom board stuck in dispatch.s

cancel
Showing results for 
Search instead for 
Did you mean: 

MQX on custom board stuck in dispatch.s

4,094 Views
Contributor II

Hi guys, I hope you can help me

I developed a multitasking application using MQX and a TWR-K60N512 evaluation board. The chip on the tower is a PK60N512VMD100 (0M33Z).

While I was working on the firmware, some collegues developed a custom board using MK60DN512ZVLQ10 (4N30D) chip which apparently seems to

be the same except for the presence of an internal DSP on the second one.

My application is made of 3 tasks. The init task is the auto start task and has a priority set to 9. It should run first and initialize the board. Before dying

it creates the other two tasks both with a priority of 10. They should run indefinitely.

When I use the tower everything is good. I can execute and debug the code (I'm using IAR and J-Link).

When I switch to the custom board I have many problems. Sometimes an error occurs when I try to upload the code so I need to erease all the memory

and try severl times before it stops tell me that the flash loader reported an error.

I don't know if this problem could be due to the linker file or the flash loader.

When I finally succed in uploading the code, something weird appens. I launch the debugger and I can see that the execution is stuck in "dispatch.s"

before the first task is scheduled.

The following code is copied by "dispatch.s" starting from line 432.


  1. ASM_LABEL(find_noempty_que)
  2.                 ldr r2, [r1, #0]                    ; address of first td
  3.                 cmp r2, r1                          ; ready_q structure itself?
  4.                 bne switch_task
  5.                 ldr r1, [r1, #RQ_NEXT_Q]            ; try next queue
  6.                 movs r1, r1
  7.                 bne find_noempty_que
  8.                 ; r1 is 0 -> empty
  9. ASM_LABEL(no_one_to_run)
  10.                 ; TODO set system task ???
  11.                 ; enable all interrupts (r1 = 0)
  12.                 ; TODO maybe (maybe not necessary) restore PendSV priority and BASEPRI after wfi
  13.                 msr BASEPRI, r1
  14.                 ldr r1, =0xE000ED20                    ; SHPR3
  15.                 ldr r2, =0xff
  16.                 strb r2, [r1, #2]
  17.                 ; wait for interrupt
  18.                 cpsie.n i
  19.                 wfi
  20.                 cpsid.n i
  21.                 ; TODO check r0, must be kernel data
  22.                 ldr r1, [r0, #KD_READY_Q_LIST]      ; get first que from ready list
  23.                 b find_noempty_que

By now the line numbers I will use are the ones used in the following piece of code.

I found the pointer always at line 23. If I go step by step it reaches line 27, then jumps to line 1 and cycles in this function 15 times.

Then it goes on to line 9, 10, 11,.... until it come back to line 1 and repeat the cycle

NOTE: the custom board has been tested with other sample code, for example with a demo of FreeRTOS and works perfectly. When I try to upload

a demo of MQX (with multitasking) the result is the same: it stucks in dispatch.s, wheras the same code in the tower works perfectly.

If someone solved a similar problem before or has some advices to give, I will really appreciate it.

Tanks

PS sorry for my English :smileyhappy:

...

42 Replies

228 Views
Contributor III

Check you task stack size. I have the same problem and when was solved increasing stack size.

0 Kudos

228 Views
Contributor V

Hi,

you are speaking about the stack size of the interrupts ? because my stake size of this is 2048 byte now. Thanks

0 Kudos

228 Views
Contributor III

Stack size of the task. Not of the stack size of the interrupts.

My problem was solved increasing th stack size  MQX_template_list[].

0 Kudos

228 Views
Contributor V

Thanks, tried but nothing..... 

0 Kudos

228 Views
Contributor V

Hi all, i'm using MQX lite on a MKL46Z256VLL4 and with processor expert i use a TIMERINT with use the LPTMR0 with a period of 1ms. My problem is when i debug the firmware, one time on two the system stop in the dispatch.s file executing this code in a infinite loop. If i reset the debug the system re-begin to work :

ASM_LABEL(find_noempty_que)

                ldr r2, [r1, #0]                    // address of first td

                cmp r2, r1                          // ready_q structure itself?

                bne switch_task

                ldr r1, [r1, #RQ_NEXT_Q]            // try next queue

                movs r1, r1

                bne find_noempty_que

                // r1 is 0 -> empty

ASM_LABEL(no_one_to_run)

                // wait for interrupt

                cpsie i

                wfi

                cpsid i

                // TODO check r0, must be kernel data

                ldr r1, [r0, #KD_READY_Q_LIST]      // get first queue from ready list

                b find_noempty_que

the problem is that the event of the timer :

 

void TI1_OnInterrupt(void)

{

  milliseconds++;

}

is fired before the end of the function TU2_Init. Why? Thanks

PS: tha package selected for the project is right

0 Kudos

228 Views
Contributor II

I have the same problem with twr-k53n512. I've tried what you mentioned above but doesn't seem to work

Here is the discord code

/* kernel interrupt handler */

ASM_PUBLIC_BEGIN(_int_kernel_isr)

ASM_PUBLIC_FUNC(_int_kernel_isr)

ASM_LABEL(_int_kernel_isr)

                cpsid.n i

                push {lr}

0 Kudos

228 Views
Contributor II

Problem resolved. It appears to be the SIM_SOPT6 register which doesn't exist for twr-k53n512, but in mqx -> source -> bsp -> bsp_cm -> line 950 is not commented. I guess this is a bug of freescale.

0 Kudos

228 Views
NXP Employee
NXP Employee

Your board has Kinetis 100MHz rev 2.x silicon, and MQX is expecting a 1.x device (see this app note for differences). It was recently changed for new board builds so we'll work on getting a note up about that. Since your board has a 2.x device, you may run into other issues using the TWR-K53N512 BSP provided by MQX (as you can see from the app note there are quite a bit of differences), so it may be useful to try using the TWR-K60D100M BSP instead which is for 2.x devices. Just want to give a heads up on that.

0 Kudos

228 Views
Contributor II

Great, thanks!

0 Kudos

228 Views
NXP Employee
NXP Employee

Hi Roberto,

  The TWR-K53N512 is natively supported by MQX 4.1, so there shouldn't be any issues with the BSP init in your case. Perhaps there's something in your application code? As a check, can you run some of the example MQX applications (like C:\Freescale\Freescale_MQX_4_1\mqx\examples\hello) on it successfully?

-Anthony

0 Kudos

228 Views
Contributor II

It is so, I can't run any example or demo, the problem is when to debug

0 Kudos

228 Views
Contributor III

Hello All... Where can I find the PIN initialisations of Ethernet module in TWRK60N512 BSP and related source code.


I had the similar issue that was discussed here and this post helped me a Lot and now I am able to get MQX up and running on

our custom board which has "MK60DN512ZVLQ10" -4N30D-(144 pin) uC on it. You all have saved me a lot of time... :smileyhappy:

Tower board has Ethernet in RM-II interface mode...

Our team mates have interfaced Ethernet in M-II mode which needs PTA-(24-29) to be set in ALT-4 MUX functionality.

I got it working with FNET's TCP stack with the above changes but we really need it work as well as with RTCS stack.

Tools: CW10.2/ Keil & MQX4.0.1 ---- Debugger: PE micro universal Multilink.

regards ...........

0 Kudos

228 Views
NXP Employee
NXP Employee

Hi,

  The ENET pin initialization is in \mqx\source\bsp\twrk60n512\init_gpio.c in the function _bsp_enet_io_init()

  Take care that some of those MII pins may be initialized by other drivers. So if you're having trouble, double check that some later driver isn't changing the GPIO mux of those pins.

-Anthony

0 Kudos

228 Views
Contributor IV

great! Thanks

0 Kudos

228 Views
Contributor IV

Hello All,

I have almost a similar issue so I want to discuss it here. I developed a MQX application on TWR-K60N512 evaluation board. The chip on the tower is a PK60N512VMD100. When I use the tower everything is good.

When I switch to the custom board with the exactl same bsp and app code I have a problem. I didn't clone the bsp. I just use the original one because we didn't change any hardware so far. The same clock rate. the same io pins.

The problem is we I try debug the code  and press debug button it stucks in dispatch.S (see the below figure)

debug-stuck1.jpg

and when I press it again it stucks in another line and stays there forever (bellow)

debug-stuck2.jpg

it a bit weird because I use exactly the same code and bsp that I use for twrk60!

I did add RTC battery and disable RTC didn't help. I changed the debugger to start at program entry point no difference!!

So I wonder if anybody out there have had the same issue and can give me some hints.

Cheers,

Sina

0 Kudos

228 Views
Contributor IV

I forgot to say the cpu on the custom board is MK60DN512VND10.

0 Kudos

228 Views
Contributor II

If I remember right, that's the difference - PK60N512VMD100 vs. MK60DN512VND10.  If you look at the datasheets, there are differences so you cannot use the same BSP.  I forget what the differences are though.  We had to link the correct MK60DN512VND10 files instead of the PK60N512VMD100 files into the BSP.

0 Kudos

228 Views
NXP Employee
NXP Employee

That was going to be my response too. The TWR-K60N512 board has a MK60DN512ZVMD10 part, which is Rev 1.x. The MK60DN512VMD10 part is a 2.x part. This app note describes the differences, and so you need to use the TWR-K60D100M BSP then on your part.

0 Kudos

285 Views
Contributor III

Try opening your bsp and disable the RTC in processor expert. Also set BSPCFG_ENABLE_RTCDEV in user_config.h to 0. Re-generate the code, compile and try it again.

285 Views
Contributor III

Yes Disabling the BSPCFG_ENABLE_RTCDEV does fix the issue for me. Thanks Farhan

0 Kudos