Cannot connect J-TAG after programming chip once (and then power cycling)

[Grizz]

STM32Cube IDE w/ STM32L562QEIX part - generated a .IOC to match my hardware. Have a Sky High eMMC 8-bit part configured to use the eMMC/SD peripheral in 8-bit mode. Also using FS USB CDC as another large peripheral. I can program/debug the chip with my Segger probe up until I power down the probe and UUT for the the night. Once that happens I can no longer connect J-TAG, I get an unable to power up DAP error. I have the J-TAQG fully configured to use the full 5 pins as it performs better than SWD for debugging. I set the HAL Settings "Set all free pins as analog (to optimize power consumption). Is there a bug or quirk here? Does this disable my J-TAG? If not what did? And why only after a power cycle? I've bricked two chips and am on a third. It's consistent. I want J-TAG enabled while I am developing.

[Tesla DeLorean]

Have a means of escape. Consider having a delay at startup, or a user initiated mode, via button or UART, that idles in a place the debugger can gain control, and the pins and logic behind them isn't turned OFF.

Try pulling BOOT0 HIGH, so that at power-on / reset it enters the System Loader in ROM, this is usually a safe harbour from which to erase the user memory, and start over. I suspect Segger has some command line tools, or equivalent. Here I can erase via Keil, or ST-LINK w/STM32 Cube Programmer.

Power-Up vs Reset? Well ST keeps moving the goal posts here. The options are latched once at power-up, likely to do with ensuring the device remains in a protected state, and avoids a bunch of glitching and other attacks/vectors.

The ST-LINK also has assorted "Connect under Reset" and other connectivity modes, allowing for alternate methods to wrestle control of the part as it starts. Obviously NRST needs to be one of the pins connected to the debugger to facilitate this.

[Grizz]

I'm curious... since the j-tag connect strategy is "connect under reset", what difference does it make what the code does? While reset is asserted, I would think the processor is not freely executing instructions.

There are no sleep or low power states yet, those go in only after the code is functionally tested and solid.

This is an embedded medical product, but it does have USB and BT BLE connections, and right now the code idles on message wait from either connection.

With this additional information, what do you suggest now?

Thanks!

[Grizz]

Forgot to mention, Segger and ST-Link V2 do the same. Command line tools and IDE all have same results.

I tried turning off the Set Free pins as analog, and one unit connects although it does take more than one attempt to connect. I verified that the GPIO pins set to analog did NOT include the J-TAG pins PA13/14/15 and PB3/4. So it doesn't seem that this contributes to the issue.

[Tesla DeLorean]

Using an L562 in a product here, not managed to brick them in that design. LDO version, not SMPS one.

Might start to expect a power related issue, or option bytes.

[Grizz]

I'm using a Linear Tech triple regulator and each channel is set to 3.100 DC. The input is a Lion 4.0 VDC camera battery. I've been using this power source and set up for a number of years. The decoupling and low ESR surge protection is to spec + 25% due to medical device reqs.

What option bytes are you thinking might play into this?

[Tesla DeLorean]

>>What option bytes are you thinking might play into this?

If you're changing them, any or all of them if not done properly. The RDP2 one being where you'll definitely brick the device from a debugging perspective.

The secure boot loader, also apt to be unhelpful in the debugging stages.

[Grizz]

Okay, I'll go back and review what things I am programming. I've already backed out the trust zones and security stuff... maybe I overlooked something. Thanks.

[Grizz]

FLASH OPTR: RDP set to 0xAA by generated code and TZEN = 0x00 as expected.

[Grizz]

Separate question:: Noticed this chip has nBOOT0 pin and nSWBOOT0 signal in the option register. Is there a code sample that shows how to sequence this internal control to reboot yourself into DFU mode? I would like the USB code to receive a command then reboot into DFU and use the built into boot loader for updates. This way I can eventually lock down the j-tag but still perform field upgrades.