Strange MK20 GPIO Receive Issue

[mwutley]

Hello,

I'm writing a built in self test and having issues with some very basic sending/receiving. On the MK20DN512 I have PTA17 (output) tied to PTA16(input), and I'm setting PTA17 high then checking PTA16 to make sure it changed state. I'm doing the very same thing with PTA14 and PTA15. 

The debug probe I am using is Segger J-Link Ultra+. It is also connected to Port A of the processor. 

This is all part of a very basic state machine. After PTA16 and PTA15 see a change of state, the state machine moves forward to the next state and I display text on my onboard LCD. When I am running in debug mode, everything works fine and it make it to the final state. If I unplug the debugger and start over, the code hangs right before making it to the final state. However, looking at my oscilloscope I can see that both pins properly changed state. The hardware is working as expected and pins are toggling as expected, but for some reason the code never moves on unless the debugger is connected and running.

I checked the errata and didn't see anything directly pertaining to this.

Has anyone experienced this before? Why does the debug probe connection matter?

Thanks! - Matt

[myke_predko]

Hey Matt,

Do you have any PRINTF statements in your code?  I've seen the same behaviour with my J-Link Plus where the processor seems to hang waiting for a response from the programmer.  This is not an issue with the openSDA used in the Freedom and Tower boards as the programmer is always present.  

Remove/comment out any and all PRINTF statement and try again.  

Good luck!

myke

[loren040]

There isn't enough information, so all I can do is speculate (and wildly at that).

My gut tells me that this is a race condition.  That is, there is something happening such that timing is off, as if some kind of propagation delay causes a missed edge or something.