2021-08-20 08:14 AM
I'm posting here because STM32CUBEProgrammer announces it cannot find my Rev.2 target board. More puzzling is that it finds my Rev. 1 target just fine.
I made these design changes between Rev. 1 and Rev.2 target boards:
--I boosted the voltage on my VDD rail to +3.05V to account for the fact that the STLINKV3SET programmer doesn't do VDD voltages below 3V. The STLINKV2 programmer I used with Rev. 1 target boards was fine with my earlier VDD=2.8VDC.
--I added signals to my already-crowded TagConnect programming header to permit the use of STM's older SWD programming interface. For safety, I left in place some of the JTAG pins.
The older SWD interface requires fewer signals, allowing me to add the COM port signals that the STLINKV3SET programmer offers. Calibration of our end product could be done using the COM port signals embedded in the TagConnect header.
So how does the STLINKV3SET programmer "inform" a freshly-birthed target board that the SWD programming regime will be used rather than the JTAG regime?
If both SWD and JTAG signals are implemented between an STLINK programmer and target board, can a new target board be confused about this matter, prompting STM32CUBEProgrammer to shout "target not found"?
Does the STM interface use signal voltages that fall outside of the normal VSS-->VDD bounds? I ask because my analog 'scope tells me this is occurring on some SWD pins.
Thanks for any feedback that you might have on this topic.
Jim in Indianapolis US
2021-08-20 08:31 AM
I forget to say that our target board uses the STM32F413 micro.
2021-08-20 12:07 PM
Reviewing the hardware changes I did to the target board to create Rev. 2 and enable SWD programming, I retired the 32F413 pins known as JTDO (port PB3) and JTDI (port PA15), leaving them unterminated in the lay-out, i.e. no pull up or pull down.
My programming partner on this project said that he did not need the SWO functionality of the SWD interface. a role normally played by the JTDO pin.
I relabeled the JTMS pin (port PA13) in my Rev. 2 PCB lay-out and schematic to SWDIO. It is still mapped out to pin #7 of the traditional 20-pin programmer interface. I notice that the STLINKV2 programmer is trying to pull this line a bit higher than VDD, but I see no wiggles on it..
I relabeled the JTCLK pin (port PA14 ) in my Rev. 2 lay-out and schematic to SWCLK. It is still mapped out to pin #9 of the traditional 20-pin programmer interface. I notice that the STLINKV2 programmer is trying to pull this line a bit higher than VDD, but I see no wiggles on it.
Both JTRST pin (port PB4) and nRST pin (aka /RESET pin #14) are/were present in both PCB lay-outs and mapped to pins #3, and #15 respectively, in the traditional 20-pin JTAG programmer interface.
The nRST pin has a 10K pull up to VDD. There is no pull up or pull down on JTRST.
2021-08-20 12:35 PM
There are TMS/SWDIO and TCK/SWDCLK sequences that will switch to JTAG or SWD. That way, the target does not need prior knowledge. First time bringup is a venture. Best chances are: Connect ground, best with multiple line, SWD and SWCLK and try SWD communication. If youtr debugger is verbose, this can help. Or a scope or better a LA that can decipher SWD. Then extend to 2 line to get full JTAG. But CortexM Debugging is best doen with SWD.
2021-08-22 06:59 AM
Thanks for the reply, Uwe Bonnes.
Presumably a freshly-birthed 32F413 target board runs on the micro's internal oscillator because there is no configuration to indicate otherwise.
In the absence of any micro response to the SWD port, is there any way to tell if the chip is running? Do any of its 100 pins exhibit "heartbeat" behaviors to show that the device awaits its first code download?
And if the SWD port is the intended one, do the unused JTDI and JTDO pins need any pull up or pull down resistor?
2021-08-22 09:11 AM
New thread, same topic https://community.st.com/s/question/0D53W000011wZJhSAM/what-to-do-when-swd-port-is-nonresponsive-to-stlink
Signs-of-Life should be sought via the ROM based System Loader, BOOT0 = HIGH
See AN2606 for list of possible pins