Alternate SWD pins

[lpcware]

Content originally posted in LPCWare by jdurand on Thu Jul 26 16:48:56 MST 2012
I'd like to use the alternate SWDIO pin on the LPC1226 but thought I'd ask first if there's anything special I need to do to enable it.  As in...how does a blank part know to look at the alternate pin, does it sample both until one toggles or what?

[lpcware]

Content originally posted in LPCWare by fjrg76 on Fri Oct 12 16:13:50 MST 2012
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.

[lpcware]

Content originally posted in LPCWare by jdurand on Fri Oct 12 15:08:11 MST 2012
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).

[lpcware]

Content originally posted in LPCWare by fjrg76 on Thu Oct 11 13:04:35 MST 2012
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.

[lpcware]

Content originally posted in LPCWare by jdurand on Thu Oct 04 10:02:58 MST 2012
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.

[lpcware]

Content originally posted in LPCWare by jdurand on Fri Sep 07 16:52:22 MST 2012
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.

[lpcware]

Content originally posted in LPCWare by jdurand on Thu Sep 06 13:51:31 MST 2012
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.

[lpcware]

Content originally posted in LPCWare by DiligentMinds.com on Thu Sep 06 10:29:50 MST 2012
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?

[lpcware]

Content originally posted in LPCWare by jdurand on Tue Aug 28 08:47:57 MST 2012
Wow, a fast answer (once the case was opened):

---

Quote:

Jerry
Thank you for contacting NXP Semiconductors.
The SWD interface by default uses pin P0.25 and P0.26.  The alternate pins (P0.18 and P1.2) are only available after you change the values in the IOCONFIG registers.
Regards
NXP Technical Support

---

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

[lpcware]

Content originally posted in LPCWare by Dave on Mon Aug 27 11:14:13 MST 2012
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...

[lpcware]

Content originally posted in LPCWare by jdurand on Mon Aug 27 09:41:08 MST 2012
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.

[lpcware]

Content originally posted in LPCWare by jdurand on Wed Aug 01 09:29:39 MST 2012
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.