Reset oscillating when not connected to debugger

[JBM]

We have a custom board that used an MK10DN512VMC10.  We got another order for the board and since that part is not currently available we have rebuilt the board with the MK30DX64VMC7 (mask 2N36B).  The board is pretty simple, just a serial port (UART2), 7 GPIOs and the JTAG interface.

When I started trying to test the new boards, I noticed the following:

1) I can't program or debug it with a PEMicro Multlink Universal

2) I can program it with a Segger JLink and the code appears to run fine in the debugger

3) When I remove the debugger, the code does not run and the reset pin (J11) is osciallating at about 15KHz.

I can reprogram the board and debug it after I see the oscillation, but if I remove the debugger, reset the board it oscillates again.

I'm not using semi-hosting, I have no printfs in the code and I have disabled the EzPort.  I had a low power mode set up (LLS) but the errata for this mask says that it doesn't work, so all of that code is commented out.

I can connect to the processor through the JLink.exe command line tool and I programmed it manually and it all seemed to work.  I even issued the "reset Kinetis" command and it appeared to work.  When I remove the JLink, it does the same thing - reset oscillating.

I've gone through the rest of the errata and I don't see anything that sounds like the issue.

The JLink has firmware version V10, compiled Nov 2 2021 12:14:50 and hardware version V10.10.

I'm using KDS 3.0 as this chip does not appear to be supported by MCUXpresso, at least I can't build/download an SDK for it.

Any ideas?  Please note that this problem is holding up production and delivery of a bunch of boards.  I cannot post the code or schematic, but I can post some sections of both if there is something that might be helpful.  Thanks.

Just to add, I created a simple program that feeds the watchdog timer.  It exhibits the same issue.

#include "MK30D7.h"

int main(void)
{
  SIM->SCGC5 |= SIM_SCGC5_PORTD_MASK;
  PORTD->PCR[2] = PORT_PCR_MUX(1);
  PTD->PDDR = 0x1 << 2;
 
  for (;;)
  {
    WDOG->REFRESH = 0xA602;
    WDOG->REFRESH = 0xB480;
    PTD->PTOR = 0x1 << 2;
  }
  return 0;
}

[JBM · Accepted solution]

We have produced these boards for years without problems, so we're pretty convinced it's not our hardware.   We found some MK11 processors and they work fine.  

There is a 2017 post here:

https://community.nxp.com/t5/Kinetis-Microcontrollers/We-have-been-having-problems-with-MK20DX64VLH7...

that details the same issue.  This processor is the same mask (2N36B) as the MK30 processors we tried.

We are writing this off to a mask issue.  I have created a trouble ticket, but that's been frustrating to say the least.