Stuck somewhere at startup of application code, SWD not working

[EmptyDemise]

Hello everyone,

I created a new project with STM32Cube Version: 1.13.2 on Linux, selected my microcontroller (STM32WB35CCU6A), enabled all peripherals necessary (including USB and SWD, haven’t enabled anything RF related (yet)), and tried to upload my code on a brand new IC on a custom PCB. For the PCB, I followed the schematic without SMPS in AN5290 as shown on this screenshot.

I should also mention that I added a 100nF capacitor on nRST, as well as a pulldown on BOOT0 and two push buttons to pull nRST low or to pull BOOT0 high, and I didn’t try to use these pins for my application. Didn’t forget to supply Vbat. For the crystals I made sure to use compatible ones and used appropriate values for the capacitors that go with them. When entering application mode, the board (which contains other devices) draws ~20mA and ~30-40mA when I enter the bootloader with BOOT0. I use a cheap unofficial st-link v2, after connecting to the pc STM32Cube proposed to update the firmware on the st-link, It worked and after this I’m still able to program blue pill board with it (via SWD).
I have two problems, wich I have no idea how to solve:

• I can’t upload / debug code with SWD. Doesn’t matter if I’m in application mode or bootloader mode. Everytime it says "No device found on target". However, I’m successfuly able to program it with DFU (trough USB), only in bootloader which I think is normal. I tried using dfu-utils but had problem reading back the flash, so now I’m using STM32CubeProgrammer, which tells me that the code I uploaded and the code I read from the flash with it is identical.
• However, it seems that there is a problem entering the while(1) of the main generated by STM32Cube. The only code I added is one to blink an output which is tied to an external 100k pull-down and the enable input of some IC, that’s in the while(1), and I also added a write 1 (with HAL_GPIO_WritePin (thing_GPIO_Port, thing_Pin, 1);) in the Error_Handler() to try and see if something was going wrong. However, I never saw this ouput GPIO going to Vddd.

I looked at SWDIO and SWCLK, I see a lot of toggling when I try to upload/debug with SWD. I checked every voltage of the decoupling capacitors, I can see a solid 3.3V and I never saw it dropping by even a mV when I reset the chip to re-enter application mode. nRST stays at 3.3V and BOOT0 stays at 0V when I try to enter application mode. I resoldered the chip 3 times, it looks good, and I tried to replace the chip by another one one time, but to no avail. I  tried to check for shorts, disabled the use of LSE and HSE to replace it with LSI and HSI, replaced all input interrupt pins with inputs, re-uploaded dozens of time with DFU using STM32CubeProgrammer and checked what had been wri, still can’t see this pin going toggling or going high. I also tried to use another pin which is also connected to a 100k pull-down and some chip enable input. At this point I have no idea what to try, and would greatly appreciate any advice.

[EmptyDemise]

So I created a new project from scratch (C and not C++ this time, although I don’t think this was the problem) and in the device configuration tool I enabled only these two GPIOs as outputs + the SWD, didn’t enable anything else and now I can see the pin blinking meaning the chip entered the main(1). I’m going to try re-enabling everything one by one to see where is the problem.

However, I still can’t program/debug the chip with SWD as I’m still getting "No device found on target" in both application mode or bootloader mode. (and I can program blue pill dev board fine with my st-link dongle in the same environment so It’s not fried). I’ve no idea what’s wrong.

[AScha.3]

is vddusb connected to vdd ?  cannot see in your circuit...

or

mixed up  swd+swc ? check continuity from cpu-pin to stlink-pin ! (i did this once... :) )

[EmptyDemise]

Yes Vddusb is connected to Vdd. I cannot really check the connectivity to the pin as the pins are under the package, but I just verified the connectivity to the solder on the pad below the package up to the pins to which the st-link connects and it’s good.

Also I found the culprit as to why I couldn’t reach the while(1), it’s USB peripheral. Whenever I enable it by clicking on "Device (FS)" in the Device Configuration Tool, my application program will stay stuck at some place during setup (and I did not add a single line of code related to USB myself). I don’t understand why. It cannot be a hardware problem (I think?) as currently, USB (trough DFU) is the only way I’m using to program the IC.

[EmptyDemise]

The plot thickens: another peripheral  prevents application code from starting: ADC with DMA mode in circular mode. But now it looks like having USB enabled in the configuration manager is not an issue for the application code to start...
ADC without DMA or with DMA in normal mode, I2C, SPI and GPIOs all work fine. I should also mention that I have to randomly power the board several time before the application code starts, otherwise the STM32 is stuck in a state where nothing starts and it’s not bootloader mode. I thought this was a power supply issue, but I’m starting to think something very wrong is going on.
If I recap:

• The SWD never works
• Enabling ADC with DMA circular mode (or seemingly USB, before....) in STM32CubeX  is enough to prevent application code from starting
• I sometimes need to power-up the board several times in a row before application code decides to begin (but each time the 3.3V supply is nice and clean)
• I can always enter bootloader mode without any issue

I think this all points out to something specific but I don’t know what it is.

[EmptyDemise]

I think my power supply startup issue is normal, I believe it happens when there’s some misconnect when connecting with the cable and the power supply gets rapidly connected unconnected connected which according to documentation can generate result in bad POR.
As for the ADC+DMA, if I generate the code without it, upload, everything works, re-generate with circular mode, change nothing else, re-generate and upload the STM32 won’t boot application code anymore. If I comment the MX_DMA_Init(); and MX_ADC1_Init();, then it boots again.
And I just realized that if I uncheck "Force DMA channels Interrupts" which allows me to uncheck "ADC1 Global Interrupt", then it can boot with circular mode and I can use the ADC fine... maybe there is something rotten in my NVIC which also prevents me from using SWD? Though it should work in bootloader mode I think...

Here’s my current clock tree as well in case this could help