2025-04-07 6:20 AM
Hello STM community,
I have built and assembled a custom PCB board with an STM32U083CC on it. I have made 5 boards, after the first two did not work, I only populated the minimum on the other three. However, I am unable to debug or event connect to it through any means I tried, and I fear I have a systematic error in my schematic or workflow.
I connect to the target over SWD, using a NUCLEO-WL55JC1 board on which I have removed both JP1 and JP7, as well as attached directly to the JP8 headers. I have independently tried using a picoprobe, which gave the same result: Seemingly no answer from the MCU, as both programs report a timeout when trying to communicate with the target.
To connect I use the `st-link` utility on linux, and have attached the NUCLEO-WL55JC1 via usb.
I have verified the following:
- Proper MCU placement wrt to pin numbering
- No shorts during soldering or after
- I read through the guide for hardware development for this MCU and have the appropriate capacitors on the power pins
- I have NRST connected to GND via a 100nF cap
- BOOT0 is connected to ground via a 10K resistance (although it shouldn't matter with factory settings)
The impedance between any of the SWD lines as well as 3v3->GND is shown as being above multiple MΩ or not-connected. I made sure no reverse-voltage is applied at any point.
For soldering, I am using a hot-air station at 180°C with low-temperature solder. The connections afterwards are continuous as far as my multi-meter can tell, so I do not believe it is a soldering issue. I have looked up the guidelines for soldering and temperature. And I do not believe I have exceed the "250°C for 1 Minute" that is given as a guideline.
I have the following schematic. The board I have is not populated except for the MCU, the "Reset" Block, the "IC Power Decoupling" block, and the "Debug Header" block. This should be sufficient to get the MCU in a state where it can be debugged. As nothing else is populated, I am trying to make sure that no other components may be interfering.
3v3V and GND is supplied over the debug header.
The PCB itself is a two-layer PCB, with a GND fill on the back, and the MCU on the front. I have also attached an image of the front layer, showing the MCU as well as the capacitors/resistance around it.
I am assuming the FAB has not done a mistake here, but checking for continuity between the debug header as well as the corresponding pad is correct.
I bought the MCUs via Mouser, so I do not believe those to be counterfeit or particularly prone to be defective.
Thus my question to the community is, can someone tell me what I did wrong here? I re-read most documentation that I could find, and considering the simplicity of this design, I feel like I covered the most obvious problems.
-----
I also made some measurements for current consumption, and when turning on it uses about 5mA. When NRST is pulled low, that drops to 0.1mA and stays there after it is no longer pulled low. Only reconnecting power brings it back to the initial 5mA.
2025-04-07 12:25 PM
Assuming you're using STM32CubeIDE, you haven't shown what the error it reports.
You have a 5-pin debug header, but haven't shown how you've connected it to the debugger pin for pin. What is supplying the 3.3V to the custom board?
2025-04-07 1:09 PM
@Karl Yamashita wrote:Assuming you're using STM32CubeIDE, you haven't shown what the error it reports.
I am not using the IDE, and instead use the command-line tool `st-util`.
When trying to connect to the target it gives me this error:
❯ st-util -u
st-util 1.8.0
2025-04-07T22:02:31 WARN common.c: NRST is not connected
2025-04-07T22:02:31 ERROR common.c: Soft reset failed: error write to AIRCR
Failed to enter SWD mode
2025-04-07T22:02:31 ERROR gdb-server.c: Unsupported Target (Chip ID is 0000000000, Core ID is 0000000000).
If I try to connect to a known working target, it instead displays:
❯ st-util -u
st-util 1.8.0
2025-04-07T22:04:20 INFO common.c: STM32WLEx: 64 KiB SRAM, 256 KiB flash in at least 2 KiB pages.
2025-04-07T22:04:20 INFO gdb-server.c: Listening at *:4242...
Which is all I'd need for now.
@Karl Yamashita wrote:You have a 5-pin debug header, but haven't shown how you've connected it to the debugger pin for pin.
I have connected:
Target -> Debugger
3v3 -> CN7 16
GND -> CN7 19
SWDIO -> JP8 T_SWDIO
SWCLK -> JP8 T_SWCLK
NRST -> JP8 T_NRST
I have removed the jumpers for JP1 and JP7 as well as T_SWO and the VCP pins on JP8.
I verified that under this setup there is 3v3V on those outputs. Removing the Debug jumpers and hooking directly should allow me to 'hide' the on-board chip on the NUCLEO-WL55JC1. To be sure, I tried either side, but neither is giving me the expected connection.
2025-04-20 3:39 AM
Could someone take a look at this maybe again? I am really stumped what might be the problem.