Alternate SWD pins

So, nothing? I sent the same question to NXP support and got the same dead air.

I guess I'll just design around it, can't chance making a board that I can't plug the debugger into.

I started this thread right after sending a question into NXP support and not receiving an answer. That would have been towards the end of July.

Today I received an e-mail that their customer support is running slow and I've just been assigned a case number. Since our PC boards are already being fabricated, I'll probably answer the question myself when I get the boards (I added jumpers to allow different connections).

Anyway, the only slower response to a support question I've seen was from another company starting with T, they assigned me a case number about 2 years after I sent in the question.

LOL - That's pretty bad... I've sort of given up on tech support, as it's message based, and so much seems to be misinterpreted - which ultimately leads to multiple messages that are trying to explain what you meant in the first place - it's a shame you can't just pick up the phone...

Wow, a fast answer (once the case was opened):

So my jumpers are needed. One set to program the part on a new board, different set to debug the board. :(

What's also strange is that NXP spent all this money and time creating this forum, and then they didn't assign any application engineers to babysit it.-- They should at least check in twice a day for questions we have-- I don't think that they "get it"-- that we can be "dead in the water" (at a dead stop in design) until we get an answer to an important question.

I have been noticing this problem with a *LOT* of manufacturers. I think when the economy tanked, a lot of support engineers were let go, and now those that are left are just trying to keep their heads above water. (I *think* company T's problem is that they are so big, they don't care so much about the little customers). If these companies want us to design their parts into our products, they better hire some support engineers-- or suffer the consequences. BTW-- I seem to always get reasonably fast support from company F-- and it has been that way for the 3 decades I have interacted with them-- and they have done this even through the economic depression-- why not NXP?

Years ago (pre-ARM) I was a big Keil supporter, then we had an economy dip and their support (which I was paying a fee for) disappeared. Especially bad since their then-new version of the compiler started overlapping memory areas...not nice to have a variable in your interrupt table!

As for NXP, I presume they're understaffed and considering that I think they're doing ok. Not super great, but I can get products out the door.

I now have the first LPC1226 board stuffed and debugging (the blanks came in from China yesterday). What I did was run the SWDIO trace from the connector to the alternate SWDIO pin, then add a pre-shorted jumper to the original SWDIO pin.

On production boards, powering up with a blank part will allow use of the original SWDIO pin to program the part. Once the part is programmed the part changes the original SWDIO to a GPIO input and changes the alternate from GPIO to SWDIO.

As long as I don't step into the instructions swapping pins around, it works fine.

If I ever need to debug a board with code in it, I can either ground the ISP pin or cut the jumper.

Update on using these pins... BAD IDEA!

I've had to cut and jump my boards to dedicate the default SWD pin to the connector. Having the main and alternate tied together works fine with switching from one to the other until you actually want to use the other pin in debugging.

If the pin is an input you can ignore during debug, then there's no need to have the jumper to an alternate.

If you actually need to use the original pin, then opening the jumper leaving the debugger only connected to the alternate pin works UNTIL you do a reset. Then the hardware is back to the main pin which is no longer connected to the SWD connector.

So, short version: Alternate SWD pins aren't worth the effort.

Hi

Hope my answer is still valid for your project.

In order to use the alternate SWD pins you first need, through serial ISP, to upload a tiny program that (only) reprogram the alternate pins, so the next time, the microcontroller is aware of its new location.

After that, you need to include that tiny program (couple of source lines) in your application, so each time you reprogram the MCU, it always use the alternate location.

I couldn't make it work, I'll just consider those lost pins for most designs (or possibly button inputs that I can ignore during debug).

They always choose the worst location for the debugging pins. One way to use those pins is not to debug, just to upload your code through the ISP and then "guess" about your application behavior (you might use printf()s to track your program).

Of course this is not a viable solution. In my designs I always consider those pines exclusively for debugging purposes. But we're lucky!! LPC2129 (and its cousins) implements a complete JTAG, 5 lost pins, whilst Cortex-M is just two.