STM32H735 Anyone? #1085
Replies: 2 comments 3 replies
-
The Nucleo-H723ZI sets the power source to LDO in the BSP. Perhaps you can use |
Beta Was this translation helpful? Give feedback.
-
Okay, I'm up and running. There are two things I fixed, so I can't be 100% certain, but I think both of them were real problems. (1) Changed the LDO to SMPS setup in startup.cpp for my board configuration. Whether or not that was killing my SWD sessions, I'm not sure. But I certainly needed to change this to match what is on the real circuit board. (2) I had some weirdness going on with the BOOT0 pin. I had attempted to lift that pin from ground, and bring it out on a tiny wire for testing. As best I can tell, the initial cut on the trace indeed lifted it, but my attempt to solder a wire did not work. So even though I thought I was grounding BOOT0, it was in all likelihood floating high, and entering one of the factory programmed boot loaders. Somehow, that messes with the SWD, at least partially. I took a second board, with BOOT0 solidly attached to ground, and it's now working. Hopefully now that I have the power-up initialization sequence working, I won't brick this again. |
Beta Was this translation helpful? Give feedback.
-
I've run into a brick wall getting an STM32H735 board up and running. I'm suspicious that I've oversimplified my initialization and overlooked something critical (vs an Nucleo H723 project I'm using as a baseline). When I look at the family chart for the STM32H7 family, the only top-level difference between these two chips is the SMPS vs LDO power supply, which is where I'm going to look next.
I searched through the MODM project examples and can't find any "hello world" program for the H735, although it is mentioned in the list of supported chips. If there were such an example program, it sure would be helpful for me to see what I'm missing -- or possibly identify some hardware issue relating to this custom board.
But I do think the hardware is working. I can perform flash and other operations on the board using MODM scripts and others (st-link tools, STM32Cube MX Programmer, etc.). I can also load a large example program of my client using Keil (and the same STLINK adaptor) and it works. I'm reasonably sure the problem is me and not the hardware.
I did find one small issue about doing target resets in OpenOCD. I think the default settings were at the limit of being too fast for my board, which uses the simple capacitor-only circuit on the NRST pin of the MCU. I observed the reset pulse from OpenOCD was super quick, and as you'd expect, the trailing edge of the pulse was leisurely rising back to the supply voltage. I put some commands in the OpenOCD script file to tell it to use a 2 ms reset pulse and to wait 10 ms before proceeding. This seemed to fix my reset problem.
Another thing that makes me think my program is wrong is that I after erasing the chip, it seems much better "behaved". Some of the quirks I see, besides my hello world program not writing to the serial port as expected, go away. That makes me think it is a setup problem. I experienced a similar "bricking" last week, because this board design didn't have BOOT0 readily available and I got it accidentally into a state where the clock was not running. In that condition, I couldn't access UART3 Bootloader, nor would the SWD work. Once I performed surgery on the board and lifted BOOT0, I was able to get it un-bricked.
Beta Was this translation helpful? Give feedback.
All reactions