STM32 Question

[ev64bug]

Posted on April 16, 2008 at 10:37

STM32 Question

[ev64bug]

Posted on May 17, 2011 at 12:29

That is an excellent suggestion. That would give me a way to troubleshoot the offending bit. I really hate to walk away from a mystery.

[jj]

Posted on May 17, 2011 at 12:29

Believe that you will NOT be able to confirm the

effectiveness of ''JTAG/GPIO'' test on your ''Locked'' boards. (as you can't get into them - to erase/ reprogram) Thus you must first implement the suggested ''JTAG/ GPIO'' test code very early in your program (on a fresh/working board - and THEN attempt to CAUSE the offending ''incident/configuration!'' Many are interested in your results - this test may be of value to our STM community as well! (extra safety @ cost of 50 or so bytes seems worthwhile) It would be illuminating to learn ''just what'' causes the JTAG to go AWOL... Please let us know of your results... Good luck. [ This message was edited by: jj.sprague on 14-04-2008 16:55 ]

[lanchon]

Posted on May 17, 2011 at 12:29

> That is an excellent suggestion.

taken from one link you posted. for maximum safety, when configuring the button pin for input be careful not to program bits you don't need to program. (ie, use reg|=(1<<n) or reg&=~(1<<n) instead of reg=(1<<n).) [ This message was edited by: lanchon on 15-04-2008 03:11 ]

[jj]

Posted on May 17, 2011 at 12:29

Wow - to get an ''excellent suggestion'' from the ''king''

is a big deal - thank you. But I've thought more - as I've NOT encountered this lock-out - and I employ the ''JTAG/GPIO'' switch code ''Defense'' early in ALL my code - I confess I may be as lucky as skillful! It makes me ''feel good'' but this is anecdotal ''proof'' at best - I don't have enough board population (~175) in the field to know if I am charging clients for mere ''luck!'' Good grief... However - as I suggested in the other forum - simply CHANGE ALL references from Port B to Port A. Port A has NO shared JTAG pins - and - as I suspect - IF you are inadvertently altering PB7 (JTAG pin) switching to Port A will REMOVE this as a culprit. Do NOT deal with Ports B or C - AT ALL - during your follow-on testing. (both these ports ''house'' shared JTAG pins.) There may be extensions between Cortex devices - and thus any success with one may benefit others/all. This is my hope. Change to Port A as I've advised and TRY to kill it! We await your results. [ This message was edited by: jj.sprague on 15-04-2008 16:53 ]

[ev64bug]

Posted on May 17, 2011 at 12:29

Well it looks like I was doing something to /TRST which is on Port B. I switched the LED blink from Port B to Port D pin 2 and that did the trick. I chose this pin since this doesn't have an alternate function and Port D isn't involved with JTAG. I also ORed (|=) the bits instead using equals for the port enable, direction, and digital enable. I most likely was disabling the /TRST on Port B.

I'm going to implement a way to recover the part next. Since I implemented the LED as a pull up, I'll put in a little loop that tests the pin for 100ms or so. If the pin is grounded it puts the code in an infinite loop. This will be the first piece of code that it runs out of reset, then if I do something that locks up the JTAG later in the code I can cycle power while grounding the pin. This will allow me to reprogram the part. Thanks for the Help.

[lanchon]

Posted on May 17, 2011 at 12:29

> I'll put in a little loop that tests the pin for 100ms or so

more than enough if you just check it once. on the /TRST pin: the JTAG standard defines the test reset signal to reset the TAP, but my understanding is that there's no need for the signal. the standard also defines a shift sequence that will also reset the TAP without using the pin. I believe this is mandatory for all JTAG devices. (check a description of the TAP state machine.) so there may be two ways to recover your devices: -maybe your programmer can be configured not to use the TRST (and will use the shift sequence instead). -long shot: maybe your programmer will issue a single reset at the begining and that's all it needs. so maybe you can recover by injecting the shift sequence somehow before invoking the programmer.

[jj]

Posted on May 17, 2011 at 12:29

Again - this ''program shift'' is an imaginative and

likely a successful solution. However - I believe that there is a BIGGER JTAG Issue which has not yet been featured. Will put our ducks in a row and start a fresh topic as I believe this new JTAG issue will of be high interest/value to a broader population of STM32/ARM users. Will post again to this topic when we've finished our study.