Posted on May 17, 2011 at 12:37''Stealing'' the pins from JTAG to GPIO functionality can be done but requires caution.
Here's a procedure which works for my group: (recall that these pins always default to JTAG use upon Reset - your code then reformats these to GPIO - which removes their JTAG functionality)
A)we NEVER assume that product is ''done'' - we can thus ''grab'' JTAG and use it as GPIO! For safety - and to allow reclaim of JTAG - we implement a small GPIO, ADC or Timer routine which looks for an ''unlikely'' condition shortly after Reset. If this condition is met - we ''bypass'' the code block which converts JTAG pins to GPIO - thus in ''normal'' operation we can employ these pins as GPIO. However when the ''switch, ADC level or Timer'' is unique - we restore JTAG and prevent GPIO reformat.
B) this method ''frees'' these pins for GPIO yet still allows us the joy of debug via the hi-speed JTAG or SWD. However - you cannot ''run'' your program from within the debugger after JTAG to GPIO ''switch.'' The debugger/IDE will not be able to re-establish commo with your STM32 until'
Reset - when your ''unique'' condition is met.
C) the implication of this seems to be that you should develop and test any challenging code on ''other - NON-JTAG'' pins first to confirm that your code is good. After you're happy - you can reconfigure your code to match the JTAG pins - program your part - and observe performance ''live.''
Be sure to check that your JTAG-GPIO switching code block/logic really works before implementing it. Suggest that you test via Led - only reconfigure the JTAG when you have confidence.
Attended STM32 Seminar (2nd time in year) today and learned that SWD has very similar performance to JTAG - AND surprising benefits. (such as TRACE!) As SWD uses fewer pins perhaps you should switch to this - this will - in itself - give you additional GPIO pins without the ''switch-test'' requirement outlined earlier.
Hope this helps - plz let the forum know how you progress...
