MQX on custom board stuck in dispatch.s

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

MQX on custom board stuck in dispatch.s

7,163 Views
lorenzomalagia
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

1,696 Views
anthony_huereca
NXP Employee
NXP Employee

To give some more information on why disabling BSPCFG_ENABLE_RTCDEV works, it is because the RTC registers are on a different power domain than the rest of the microcontroller. So if you don't power VBAT on your board (or there's a hardware error there) then an access to the RTC registers will cause it to crash. When that #define is set, MQX will attempt to turn on the RTC, and thus causes the problem.

For other people coming across this thread in the future trying to figure out their BSP porting problems, most issues that cause someone to get stuck in dispatch.s are symptoms of some other issue. Especially if it happens before you even start any tasks. That's just where MQX crashes to, but often is not related to the cause of it.

Doug also had a really good suggestion when debugging BSP porting issues, which is to make the debugger start at the program entry point instead of at main() (Re: MQX on custom board stuck in dispatch.s) By the time the code gets to main(), MQX has already executed a LOT of setup code and makes jumping straight to main() makes the problem hard to debug.

1,696 Views
nikhilsarnaik
Contributor III

Hi Anthony,

So do you suggest that the problem which I think is fixed might not be so and I should be digging into the code pre-main() to be sure everything is initialised correctly?

Thanks

Nikhil

0 Kudos

1,696 Views
anthony_huereca
NXP Employee
NXP Employee

Hi Nikhil,

  No, your solution is correct, I apologize for the confusion. I was just trying to give more background to other readers on why exactly disabling BSPCFG_ENABLE_RTCDEV fixed the problem. And also how to debug other BSP init problems people might run into in the future. I edited my post to try and make that more clear.

-Anthony

0 Kudos

1,696 Views
gordonfinlay
Contributor I

Hi Anthony and others,

Thanks for your excellent discussion of init_bsp() problems and getting stuck in the dispatch.s!!

I have a very similar problem where at startup my _bsp_enable_card function in init_bsp.c hangs inside the dispatch.s loop in _pend_svc (near no_one_to_run). We are using MQX 4.0 on a Kinetis K20 with a custom board. Our BSP was cloned from the TWRK20D72M BSP. 

The calling tree is:
       main -> _mqx -> _bsp_enable_card -> systick_init ->  <excpt 0xE> -> _pend_svc (dispatch.s).

In my case, I believe that when our bootloader starts up (after a software reset or else a watchdog timeout reset), that the bootloader jumps to MQX main entry point when somehow there is still a pending PENDSV task switch request.
The PENDSVSET bit is set in the SCB ICSR register (asynchronous PENDSV is pending but not yet handled) at the time the init_bsp() function calls _bsp_enable_card. When the systick_init function modifies the SVCall priority by writing to the SCB_SHPR2 register, the asynchronous pending exception is immediately triggered (see the bold line from init_bsp.c code: 

static void systick_init(void) 
{
 /* Get system clock for active clock configuration */
 uint32_t system_clock = _cm_get_clock(_cm_get_clock_configuration(), CM_CLOCK_SOURCE_CORE);
.
.
 systick_config(system_clock, BSP_ALARM_FREQUENCY);
 SYST_CSR = 7;

 /* SVCall priority*/
 SCB_SHPR2 |= 0x10000000;              <------ Exception 0xE (PENDSV) occurs right here
 /* SysTick priority*/
 SCB_SHPR3 |= SCB_SHPR3_PRI_15(CORTEX_PRIOR(BSP_TIMER_INTERRUPT_PRIORITY));
}

I assume that SVC priority bits in SHPR2 apply to both SVCall and PENDSV exceptions? Once the SVC priority has been elevated, this triggers the asynchronous pending PENDSV exception 14 (0xE) immediately, and the code is hijacked away to the  _pend_svc handler for vector 0x0E (ivINT_PendableSrvReq).  Of course this is problematic as there are no MQX tasks initialized at the time that _bsp_enable_card is called by the MQX BSP initialization code!!!

Note the calling stack at the time I get the exception in the images below.
2017-05-19_16-37-38.jpg

2017-05-19_16-37-59.jpg

SCB registers including ICSR:

ICSR_bits.jpg

So the next question then is why is there a pending service request (PENDSVSET bit is 1 and VECTPENDING is 0xE) when MQX starts up?


I have been testing hundreds of deliberate software resets to repeat MQX initialization, and finally was able to repeat the intermittent hang or loop in dispatch.s where this issue occurred.  After each software reset (deliberately setting SYSRESETREQ bit in AIRCR at the completion of the completion of the autostart task), our bootloader will run after reset and jump to the application entry point which calls the application main() entry point which starts up MQX.  Is it possible that somehow that the ICSR register (and in particular the pending service request PENDSVSET) was not cleared at the time a software reset was performed (via SYSRESETREQ) or when a watchdog timeout in WDOG causes a reset?  Normally, I would not expect that there would be any service requests for a task switch pending (PENDSV) during MQX startup.

Your comments are most appreciated!

Cheers,

Gord Finlay

0 Kudos

1,696 Views
nikhilsarnaik
Contributor III

Hi Anthony,

Ok thanks for the information.I looked at the hardware anyways and found I do not have VBAT connected on my custom board, that might be one of the reasons for code getting stuck in dispatch.s as you suggested. I'll try to connect the VBAT and then ENABLE the RTC to see if it makes difference. But as of now i am happy my code is running OK so far just by disabling RTC.

Thanks

Nikhil

0 Kudos

1,753 Views
robertogracia
Contributor I

Hi to all,

I have exactly the same problem, i have the twrk60n512 with mqx 4.0. On the tower my program runs well, but on my own board the program stops on dispatch.s and never starts the main code. On my board I have the MK60DN256ZVLL10 micro controller, and i have used the MQX BSP Cloning Wizard to modify the bsp.

The hardware is tested and I´m sure that the problem is on the bsp configuration but I don´t know how to solve it.

Thanks and waiting for a correct answer,

Robert


0 Kudos

1,753 Views
ee_dugan
Contributor II

Robert,

The Z in the micro controller part number makes a difference.  Does the BSP use the mem file that has the Z in it?

How far do you get in the startup process?  What is your clock configuration?


Thanks,
Doug

0 Kudos

1,753 Views
robertogracia
Contributor I

Hi Douglas,

I don´t understand what means this about Z on the mem file that uses the BSP.

I have used the MQX BSP Cloning Wizard to create the new bsp for the MK60DN256ZVLL10.

The startup process arrives until:

ASM_LABEL(_int_kernel_isr)

                cpsid.n i

                push {lr}

                ...

on dispatch.s

and then, starts in a loop between this and the next:

ASM_LABEL(no_one_to_run)

                /* TODO set system task ??? */

                /* enable all interrupts (r1 = 0) */

                /* TODO maybe (maybe not necessary) restore PendSV priority and BASEPRI after wfi */

                msr BASEPRI, r1

                ldr r1, =0xE000ED20                    /* SHPR3 */

                ldr r2, =0xff

                strb r2, [r1, #2]

                /* wait for interrupt */

                cpsie.n i

                wfi

                cpsid.n i

                ...

my clock configuration is:


#ifndef BSP_CLOCK_CONFIGURATION_STARTUP

     #define BSP_CLOCK_CONFIGURATION_STARTUP (BSP_CLOCK_CONFIGURATION_96MHZ)

#endif /* BSP_CLOCK_CONFIGURATION_STARTUP */

/* Init startup clock configuration is CPU_CLOCK_CONFIG_0 */

#define BSP_CLOCK_SRC                   (CPU_XTAL_CLK_HZ)

#define BSP_CORE_CLOCK                  (CPU_CORE_CLK_HZ_CONFIG_0)

#define BSP_SYSTEM_CLOCK                (CPU_CORE_CLK_HZ_CONFIG_0)

#define BSP_CLOCK                       (CPU_BUS_CLK_HZ_CONFIG_0)

#define BSP_BUS_CLOCK                   (CPU_BUS_CLK_HZ_CONFIG_0)

#define BSP_FLEXBUS_CLOCK               (CPU_FLEXBUS_CLK_HZ_CONFIG_0)

#define BSP_FLASH_CLOCK                 (CPU_FLASH_CLK_HZ_CONFIG_0)



Thanks,

Robert




0 Kudos

1,753 Views
ee_dugan
Contributor II

Robert,

Let me try to explain the Z issue.  One of the issues we encountered was that the micro we were using on our board had the Z in the part number.  The Z in the part number denotes initial silicon from Freescale.  There are newer parts that do not have the Z in them.  Our issue was that we were trying to clone a BSP from a newer silicon part (non-Z) and then trying to use that BSP on an older silicon part (Z).  It is my understanding that If you cloned the twrk60n512, then this should not be your issue.  But it was ours and what you described is very similar to what was occuring for us.

Do you have your debugger set to start at program entry point or main?  We were able to debugger this issue when it was set to program entry point.

Capture.JPG

Thanks,
Doug

0 Kudos

1,753 Views
robertogracia
Contributor I

Douglas,

Thanks for your explanation, now i understand a bit more this about the Z, and yes, i have cloned the BSP from the twrk60n512 that is my test board.

And now, my debugger set to start at main.

thanks again


0 Kudos

1,753 Views
ee_dugan
Contributor II

If you change the debugger to start at program entry point, how far can you step before it goes to dispatch.s?

0 Kudos

1,753 Views
robertogracia
Contributor I

changing this, the last instruction that the code does is the "else" condition and "bl main" (startup.c line:182):

#if SUPPORT_SEMIHOST_ARGC_ARGV

        lda    r1,argv

        mov    r0,#__MAX_CMDLINE_ARGS    // size of argv array

        bl    __argc_argv

        lda    r1,argv    // reload r1 w/ addr of argv

        // r0 is correct w/ rtn from argc_argv

#else

        mov    a1,#0

        lda    a2,argv

#endif

        bl    main

after execute this instruction the code jumps to dispatch.s


0 Kudos

1,753 Views
ee_dugan
Contributor II

lorenzomalagia,

Has this issue been resolved yet?  If so, please let me know how.  I am experiencing a very similar issue.  The https://community.freescale.com/thread/302060 thread does not seem to resolve it.

0 Kudos

1,753 Views
juliank_
Contributor I

Hi Douglas,

Most probably the error is an interrupt at the same priority level as the mqx-maintimer interrupt priority level. Please check that you have disabled all interrupts or at least giv em less priority level. That did it for me

Best regards,

Julian

1,753 Views
c0170
Senior Contributor III

Hello lorenzomalagia,

Is there any update with the issue?

I have seen similar problem in this thread:

https://community.freescale.com/thread/302060

Please read it, it might help you:smileywink:

Regards,

MartinK

0 Kudos

1,753 Views
lorenzomalagia
Contributor II

Thank you for the reply, but I had already read that article which is similar but different to my problem.

Unfortunately it was not so helpful :smileysad:

Is there someone who can help me with the configuration of the MQX libraries? I think that the problem

could be there. I know that the most important files to be modified by the user for a custom board are

user_config.h and board_name.h but I think that maybe there is something more to be modified to

make the library compatible with the custom hardware. Maybe some pin which is in high impedance in

my board and is not supposed to be so for the libraries is causing the bug.


Any ideas? Which procedure do you follow for a correct configuration of the libraries?


Thank you

0 Kudos

1,753 Views
hake
NXP Employee
NXP Employee

can you share your BSP source code? do you follow the BSP Cloning Wizard for MQX™ wizard?

0 Kudos

1,753 Views
lorenzomalagia
Contributor II

I read the instruction in "MQX Board Support Package Porting Guide" but I did not use the Cloning

Wizard because I did not hear from it before and now I noticed that it is a tool included in MQX 4.0, but I am currently using MQX 3.8.

I tried to install MQX 4.0 but the IAR project to recompile the libraries was not set properly and I was not able to compile the libraries.



I uploaded the entire BSP folder with the *.c and *.h BSP files. It is downloadable with the following link:

http://dl.dropbox.com/u/2270531/twrk60n512.zip


0 Kudos

1,753 Views
c0170
Senior Contributor III

Hi lorenzomalagia,

I would start with a flash loader and a linker command file in order to fix flashing problems. As Yong Huang suggested, it might be hardware related (even flash loader problems).

Regards,

MartinK

0 Kudos

1,753 Views
lorenzomalagia
Contributor II

I know that my BSP code is not so different from the original one and that is the question. I have the hardware schematic, I know perfectly how the board is made, what I don't know is what I need to change in my BSP in order to make it work in relation to the differences between my board and the TWRK60 development board.

I think (but I could be wrong) that the flash loader should be the same, because the chip is in the same family so the addresses of the memory and the ram should be the same.

0 Kudos

1,753 Views
hake
NXP Employee
NXP Employee

it is the sam if your chip version is the same. I even meet this problem on my tower board when the board is not well connected with elevator board, do you check the IO pins setting? some interrupt pins may be in reverser state.

0 Kudos