MK22FN256VMP12 detecting problem

[NenadJ]

Hello,

I have a design with Kinetis® MK22FN256VMP12 MCU, the schematic is attached.

It's a simple add-on board, with just the MCU, a few components, and connectors to connect to the host board and external programmer/debugger.

I have a problem with not being able to detect the MCU with the programmer/debugger.
This is a case when the add-on board is mounted to the host board, and also when the add-on board is just connected to the programmer and powered from it as well.

I am using J-Link programmer and have confirmed its functionality and connections with another Kinetis MCU. I have also confirmed the host functionality with a similar add-on board with a different MCU.

I have not excluded possible soldering problems, since it is a 64-MAPBGA footprint, but would like to exclude design mistakes before dealing with soldering.

I would appreciate it if anyone could do a design review and let me know if there is anything that could be a cause of this problem.

Thank you,

Nenad

[Pavel_Hernandez]

Hello, I recommend reviewing this thread that maybe could help you.

Design Considerations for Debug - NXP Community

And suggest based on the design of the EVK board.

Best regards,
Pavel

[NenadJ]

Hello Pavel,
Thank you for the fast response, I added 10k pull-up resistor to SWDIO line, and 10k pull-down resistor to SWCLK line.
That didn't help, let me know if there is anything else.
Best regards,
Nenad

[tomas_voda]

Hello,

Please check the SWD connection.

In schematic there are no pull-ups/downs.

Can you please share schematic and device type which is working on your side?

Regards,

Tomas

[NenadJ]

Hello Tomas,
Thank you for the fast response, I added 10k pull-up resistor to SWDIO line, and 10k pull-down resistor to SWCLK line, that didn't help.
What exactly do you think by the device that is working on our side?
Best regards,
Nenad

[tomas_voda]

Hi Nenad,

As you mentioned: "I am using J-Link programmer and have confirmed its functionality and connections with another Kinetis MCU. I have also confirmed the host functionality with a similar add-on board with a different MCU."

Would be great to understand the difference the board which you have working compared to board which is not working.

Regards,

Tomas

[NenadJ]

Hello Tomas,
I have confirmed the programmer with this board with MK22FN512VLH12 MCU:
https://www.mikroe.com/clicker-kinetis
And I have confirmed the host functionality with another add-on board in the same format as the problematic one, just with the STM32 MCU. I don't think that design would help since it's a completely different MCU.
Best regards,
Nenad

[Pavel_Hernandez]

Hello,

The most common error is the length of the cable, the pull ups and caps for the noise, and the voltage. Could you share a picture of your setup?

Best regards,
Pavel

[NenadJ]

Hello Pavel,

Thank you for the feedback, I agree things listed can be a problem.

I am connecting J-Link over standard jumper wires, let me see what I can improve here.

One thing I forgot to mention, I tried testing with CODEGRIP programmer as well.
I attached the picture of the setup, testing is done with the target add-on board powered by the programmer, and no connections with the host board.
I think this is the cleanest setup I have, and there shouldn't be any of the problems you listed.

Did you have a chance to review the design in more detail, did you see any problems with MCU connections or anything missing that could cause this problem?

Best regards,

Nenad

[Pavel_Hernandez]

Hello,

Are you sure that debugger provides voltage to the target? did you measure it?

Best regards,
Pavel

[NenadJ]

Hello Pavel,
Yes, I am sure the debugger provides voltage to the target, that part is fine.
Best regards,
Nenad

[Pavel_Hernandez]

Hello, sorry but in that case, I recommend reviewing the part as X-ray to confirm if this was soldering right. I attached the KQRUG there are some tips and tricks that maybe could help you.

Best regards,
Pavel

[NenadJ]

Hello Pavel,

Thank you for the feedback and the document.
I will see what we can do about X-ray review and the recommendations in the document.
I am out of office this week, so sorry if I am a little slow in response. But you can let me know if you see anything else in the design or have any other ideas how we can debug, and I will check it out asap.
Best regards,
Nenad

[Pavel_Hernandez]

Hello,

I suggest opening a ticker not in the community to get support, in that way you can share schematic or other private information.

Best regards,
Pavel

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[NenadJ]

Hello Pavel,
Thank you, I will open a ticket and share the entire project.
Can you please check one more thing since you are already familiar with the issue?
Does pin PTA4 (G5), which is an EZP_CS, require an external pull-up?
Best regards,
Nenad

[Pavel_Hernandez]

Hello, 

I suggest reviewing the chapter from RM 3.5.1.6 Flash Modes for more details and checking table 48 if you do not want to use that pin. Table 48. Recommended connection for unused analog interfaces (continued).

Best regards,
Pavel

[NenadJ]

Hello Pavel,
Thank you.
Yes, I have seen Table 49. recommendations for unused interfaces, which is why I have concerns about the PTA4 pin.
The thing is, we have designs with some other Kinetis MCUs, where PTA4 has the same functionalities, and is left floating in the design, and we have no problems with those designs.
It's still not clear to me, because when looking at the RM Table 10-2, it seems like the default state for PTA4 is pull-up, which should be fine when left unconnected in the design.
Do you think that PTA4 not connected could be the cause of the MCU detecting problem?
Best regards,
Nenad

[ErichStyger]

Hi @NenadJ ,

PTA4 is connected to NMI by default. So if you have PTA4 floating, that's OK.

If not, you need to disable NMI functionality, see https://mcuoneclipse.com/2020/06/09/disabling-nmi-non-maskable-interrupt-pin/

I hope this helps,

Erich

[NenadJ]

Hello Erich,
Thank you for the fast response and confirmation.
Yes, we had problems with designs where PTA4 is used and had something to pull it down on startup, but never with designs where it's left floating.
This helps, but means we still need to figure out what is the problem with this design (smiley face)
Best regards,
Nenad