I'm trying to connect to a custom PCB made using an STM32L552ZET6Q using SWD and Cube Programmer, but I keep getting the "No STM32 target found!" error.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-09-20 11:07 AM
I've gone over the hardware with a multimeter and all the pins have the right continuity, I've checked the design against the Nucleo-144 L552ZET6Q schematic and it checks out so far, and I've also checked the connections to the ST-LINK/V3 pins I'm using.
I haven't been able to program the MCU once yet via SWD or USB (I'm mostly sticking with SWD for now).
If anyone has any suggestions or thoughts, I'd appreciate any help I can get. If any additional information is needed from me, I'll do my best to provide
Solved! Go to Solution.
- Labels:
-
STM32CubeProgrammer
-
STM32L5 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-09-21 10:34 AM
Will do. In the meantime though, I might have found something. There's an 100k ohm resistor between the NRST pin, and the rest of the SWD connection. The SWD side of the resistor is being pulled low, but is it possible that the MCU side of it is still being held high by the internal pull-up? It looks that way based on the multimeter I'm using, but it could just as easily be too slow to pick it up.
Edit: Here's the photo you asked about. The resistor I mentioned is R6
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-09-21 11:12 AM
There's an internal pull-up, probably 10K type magnitude
Picture seems to check out, right part, markings, orientation.
Not a SMPS user here so not sure expectations, but would suggest double checking outputs meet expectations.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-09-21 11:28 AM
I'll take a look. Do you think the R6 I mentioned could be a problem? My gut says it is, but I don't want to rush in without a second opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-09-21 11:58 AM
The SWD interface doesn't need an NRST connection to function.
The MCU should pull it high, and it should be high if the VDDA thresholds. On a scope, over time you should see it initially clamped low, and then release.
Current ST-LINK firmware, and STM32 Cube Programmer should be able to connect with L5 / CM33 parts
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-09-21 12:03 PM
Okay, let me rephrase: Could R6 prevent it from being clamped low on the microcontroller's side, and if so, would that prevent an attempted connection?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-09-21 12:08 PM
I seriously doubt a 100K R6 would prevent the MCU clamping it low, even if you were driving it with a PP driver, which you shouldn't be.
Other driver(s) of NRST should be using OD/OC as it's a bidirectional signal, and actively driving it high will prevent ARM MCU resetting properly.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-09-22 7:07 AM
Alright, I finally had time to do a better test, and I think I was half on the ball.
The internal pull-up and the 100k resistor are creating a voltage divider, causing the debugger's side of the 100k resistor to drop to logic low, but the mcu side of the resistor to drop to about 2.3 (manually shorted debugger NRST to GND with a jumper wire).
I feel silly for not trying this yesterday.
UPDATE: So, that didn't fix the connection problem, but I get the sense it would have been an issue anyway. Onward I go, I guess
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-09-26 8:14 AM
Well, this is getting even more concerning. It looks like I can't even get the L552 to start the system bootloader either. This is getting ridiculous
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-09-26 9:10 AM
It's consistent with the device not being electrically viable
Suggest you go over your design netlist, make sure there aren't disconnected islands (groups of same but wrong named), or shorted nets.
Check the solder-test or a unpopulated board for pad level connectivity. Starting with supplies. And double check expectations from SMPS operation.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-09-26 9:17 AM
I did that before starting this thread, and several times afterwards, using the CUBEMX file, NUCLEO-144 schematic and the project schematic as a reference. Everything checks out. Every VDD, VDDIO, VDDA, VREF+, all of them are connected without shorts.
SMPS is running the voltages it should (1V3). At this point, I'm wondering if I should try swapping out the microcontroller for one off of a NUCLEO board I know is working. At least then I can learn if its a problem with the board, or the microcontroller
