Strange bug with MQX stack monitoring

[dave408]

I don't know how to "prove" that there is a potential bug with MQX_MONITOR_STACK except to describe my test case.

I have a MK22FN256VLL12 that drives 2 H-bridges via the MK22's PWM output.  I am using the PWM function FTM_DRV_PwmStart() in the KSDK.

Regardless of what I set for the PWM duty cycle, the PWM output of the MK22 is just logic low, only when I have MQX_MONITOR_STACK in my preprocessor settings.  If I remove it, the PWM driver works as expected.

I have read that all this does is write the "stak" watermark in the remaining stack space, and it looks like this is done here in dispatch.S:

1. #if MQX_MONITOR_STACK 
2. ASM_LABEL(_fill_stack) 
3.                 lsrs  r1, r1, #2 
4.                 adds  r1, r1, #1    /* Calculate size in _mqx_uints. */ 
5.                 ldr r2, =0x7374616B /* Load pattern "kats". */ 
6.                 b.n _fill_stack_1 
7. ASM_LABEL(_fill_stack_0) 
8.                 str.w r2, [r0], #4  /* Store pattern to address and increment pointer to next address. */ 
9. ASM_LABEL(_fill_stack_1) 
10.                 subs r1, r1, #1      /* Decrement size counter. */ 
11.                 bne.n _fill_stack_0 
12. #endif /* MQX_MONITOR_STACK */ 

I've also read that MQX_KERNEL_LOGGING has to be added to enable the _klog* functions, but I have verified that kernel logging is NOT enabled, so I'm having trouble seeing how filling the stack would cause the KSDK PWM function to stop working.

Has anyone else here experienced this?  Can anyone at FSL test out what I am describing to see if you can reproduce it?  It is reproducible on all of our PCBs.

[dave408]

Just bumping this question again, since the problem has also surfaced on another project that is using a MK22 as well.  Same problem, PWM does not work if MQX_MONITOR_STACK is enabled.

[danielchen]

Hi Dave:

Do you have a project for us to reproduce your issue with FrdmK22 board?

Regards

Daniel

[dave408]

I'm new to ARM assembly (and most assembly, actually), but I did go through the ARM instruction manual and decoded the assembly listing line by line.  It totally checks out fine, so I don't understand how this problem could have occurred, unless the task stack is somehow able to occupy the same space as the KSDK code.