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.
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:
...
Check you task stack size. I have the same problem and when was solved increasing stack size.
Hi,
you are speaking about the stack size of the interrupts ? because my stake size of this is 2048 byte now. Thanks
Stack size of the task. Not of the stack size of the interrupts.
My problem was solved increasing th stack size MQX_template_list[].
Thanks, tried but nothing.....
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
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}
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.
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.
Great, thanks!
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
It is so, I can't run any example or demo, the problem is when to debug
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 ...........
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
great! Thanks
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)
and when I press it again it stucks in another line and stays there forever (bellow)
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
I forgot to say the cpu on the custom board is MK60DN512VND10.
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.
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.
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.
Yes Disabling the BSPCFG_ENABLE_RTCDEV does fix the issue for me. Thanks Farhan