LPC4333 Debugging

[yaroslav]

Hello,

I'm having problems with debugging LPC4333. We followed all design notes when layouting our board. But it's already 5-th MCU that I can't debug. We use SWD for debugging.

We've put resistors 100R in serial to avoid possible short circuit and protection diodes on all IOs (ESD) to limit the voltage in parallel.

Right now I have a LPC4333 on our board, that I've programmed yesterday, and it worked. Today it doesn't. The firmware runs and does it's job, the only problem is, I can't program it. If I setup the boot pins to start internal bootloader and load the firmware over FlashMagic it also works. Just SWD is down.

I have another board with the same MCU that I can program over and over again, the SWD interface works fine on it.

No debug pins are configured in the firmware, they're left at their default states. DBGEN is left unconnected, due to its internal 50k pull up being enough to enable SWD.

Could someone please give any tip of what can go wrong?

Best regards,

Yaroslav

[victorjimenez]

Hello Michael and Yaroslav, 

After a deeper search I found two different community posts of the same thread. 

Please refer those community posts: 

• LPC4337 JTAG Not working 
• JTAG not working on LPC4337 

If you still have question after use that recommend, please let me know!

Regards, 

Victor.

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

[michaelgraf]

Hello,

I have really the same problem with the LPC4333 as Yaroslav. As we use also the LPC4357 on other boards without having problems like this, I think it must be specific to the 433x serie.

I have 5 protoboards equiped with the LPC4333 with the same SW running on them. But after some debug sessions I get 2 boards which I could accessed over SWD any more.

I use ULINK2 and Segger JLink, both with Keil uVision5.

I used the bootloader to erase the flash, but access over SWD isn´t possible any more. After changing the chip everything works well again.

So the question is why on the 435x serie we don´t have problems like this?

I don´t want to use the 435x in this project, because no LCD interface is needed.

Do you have further ideas how to protect the SWD interface??

BR

Michael

[victorjimenez]

Hello Yaroslav, 

Just to be sure, you mentioned that one day you were able to debug the LPC4333 but the day after you were not able to do it? If this is the case, then apparently you need to regain the debug access. We have a community post that explains why this happens and how to fix it. 

• Regaining debug access to target MCU 

We have another community post with the design considerations for Debug. I recommend you to take a look to this post so you can see if you are missing some configurations on your board. 

• Design Considerations for Debug 

Please let me know the results so we can continue with the follow up. 

Regards, 

Victor.

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

[yaroslav]

Hello Victor,

thank you for the fast response. We considered the debug pins design rules given in UM for LPC43xx. As the chapter "51.6.2 Cortex debug connector (10-pin)" shows (fig. 193), we implemented those two pull-ups. Also we've put a 47k to RESET pin, so that we're sure that the reset must actively be driven low. The difference to the page you've given is that the UM doesn't suggest any R for SWCLK.

Considering the link to debug access points: I use

• no low power mode
• no watchdog
• no debug pins (the're left at default mode)

in the firmware.

The thing with the incorrect clock: why some boards start well and others don't?

The reason why we put resistors in serial and additional protection diodes is: on our first board after a couple of debug sessions and discovering the MCU not be debuggable, we've measured the resistance of the chip at the SWD pins and they were at low resistance. But the MCU worked well and could be reprogrammed through ISP UART with FlashMagic.

So, unfortunately, those links are not helpful. Have you had any similar case? The MCU exists since a very long time on the market, so I'm pretty sure, that if I'm not the first one with such a problem, there're other requests of this art, aren't they?

Regards,

Yaroslav

[victorjimenez]

Hello Yaroslav, 

Thanks for providing more information!

So, unfortunately, those links are not helpful. Have you had any similar case? The MCU exists since a very long time on the market, so I'm pretty sure, that if I'm not the first one with such a problem, there're other requests of this art, aren't they?

Although the MCU exists since a very long time, the board you are using is custom. So, is difficult to have another case similar to this one. The weird thing is that you were able to debug the MCU one day but the day after you weren't. 

You mentioned something before: 

I have another board with the same MCU that I can program over and over again, the SWD interface works fine on it.

I have one question here: did you load the same program in the different boards?  Could you please swap the MCUs between these boards. Put the MCU that you are not able to debug in the board that the SWD interface works fine and try to debug several times in this board, with the same program that you tried before. If everything works fine then the problem is not in the MCU or in the program, but it's in one of your boards. 

What are the differences between the two boards that you mentioned? 

Regards, 

Victor.