For reference the command being used and its output is: $ openocd -f interface/stlink.cfg -f target/stm32h7x.cfg -c "program nuttx.bin 0x08000000 verify reset exit" Open On-Chip Debugger 0.12.0 Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'. Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD Info : clock speed 1800 kHz Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748 Info : Target voltage: 3.308108 Info : [stm32h7x.cpu0] Cortex-M7 r1p1 processor detected Info : [stm32h7x.cpu0] target has 8 breakpoints, 4 watchpoints Info : starting gdb server for stm32h7x.cpu0 on 3333 Info : Listening on port 3333 for gdb connections [stm32h7x.cpu0] halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x0800136c msp: 0x24001ccc ** Programming Started ** Info : Device: STM32H74x/75x Info : flash size probed value 2048k Info : STM32H7 flash has dual banks Info : Bank (0) size is 1024 kb, base address is 0x08000000 Info : Padding image section 0 at 0x0801d5f8 with 8 bytes (bank write end alignment) Warn : Adding extra erase range, 0x0801d600 .. 0x0801ffff ** Programming Finished ** ** Verify Started ** ** Verified OK ** ** Resetting Target ** shutdown command invoked
On Tue, Jan 21, 2025 at 8:47 PM Matteo Golin <matteo.go...@gmail.com> wrote: > Hello everyone, > > InSpace has manufactured our flight computer now, which is intended to run > NuttX. It is STM32H743 based (VIT6 version). We would like to flash one of > the existing STM32H743 builds from NuttX onto it to verify that it works > before proceeding to create our own board support package. We are able to > get access to its DFU loader via USB, and I can flash binaries to it. > However, it appears all of the H743 binaries that exist are for flashing > with an STLink or similar, not for DFU. > > I have attempted flashing the chip with an STLink using the openocd > commands suggested here, and the binaries can be flashed and verified > properly. I am attempting to flash the chip with the configuration for the > weact-stm32h743:nsh since it is the most similar to our board. I cannot > seem to detect a shell on USART1 despite the binary flashing. I have also > changed the definition of GPIO_LD1 (autoled) to be the pin PA4 where we > have our status LED, and updated the HSE clock to 24MHz to match the > frequency of the clock on our board. `ARCH_LEDS` is enabled and the USART1 > pins have been modified to PB6 and PB7 to match our board setup. No luck > yet getting a shell or seeing an LED blink. Wondering if anyone with > experience porting to new STM32 boards has some debugging tips for us to > try. > > Thank you for all your help so far! > Matteo > > On Tue, Oct 1, 2024 at 9:36 AM Matteo Golin <matteo.go...@gmail.com> > wrote: > >> Thank you everyone for the responses, lots to consider. >> >> I'll have some of our members look into reading the STM32 datasheets to >> check for information about whether or not the >> particular chip(s) we're interested will ship with DFU support or not. >> We're trying to make the use of this board >> as easy as possible since there are lots of different student members. >> >> Thank you for the programming information using openocd; that will be >> useful for us when it comes time to program, >> especially some of the example scripts. The Florida Institute of >> Technology project looks very interesting and is >> definitely something for us to read up about! >> >> Thanks everyone, >> Matteo >> >
