Patricia Holden

It doesn't matter if I use "echo 1 | tee" or "echo 1". I put my multimeter on BOOT0 & MCU_RSTn pins and added an exit from one stage to another. Both pins are set correctly throughout the script. On Thu, Jan 2, 2025 at 5:04 PM Tormod Volden tormod@users.sourceforge.net wrote: Are you sure echo 1 > file isn't interpreted as echo with stdout (file handle 1) redirected? I usually use echo 1 | tee file which avoids any ambiguity (and also because I can use sudo tee easily). [tickets:#170] https://sourceforge.net/p/stm32flash/tickets/170/...

Is there something I need to configure on the STM32 side to properly support the stm32flash utility? So far I've not gotten into the STM32 side of things, as another engineer is working on that SW. On Fri, Jan 3, 2025 at 4:34 PM Patricia Holden pholden@nklabs.com wrote: It doesn't matter if I use "echo 1 | tee" or "echo 1". I put my multimeter on BOOT0 & MCU_RSTn pins and added an exit from one stage to another. Both pins are set correctly throughout the script. On Thu, Jan 2, 2025 at 5:04 PM Tormod...

Unable to program Nucleo-g070rb using stm32flash utility

I was wondering if anyone has used the nucleo-g070rb with stm32flash. I'm getting the error: stm32flash 0.7 http://stm32flash.sourceforge.net/ Using Parser : Raw BINARY Size : 91512 Interface serial_posix: 115200 8E1 Failed to init device, timeout. My HW is set up with an AM623 SOC that controls BOOT0 and RSTn on the STM32. We are using a ttyS0, which is configured properly according to dmesg to do the programming. The following is my script for running the programming: // Set ttyS0 to 8bit, even...

I have no idea, but it has not happened again since I last reported the anomaly.

It is happening again and I have not touched a thing. I rebooted my laptop, and tried to use dfu-util again. sudo dfu-util -l dfu-util: symbol lookup error: dfu-util: undefined symbol: libusb_set_option ldd output: sudo ldd /usr/local/bin/dfu-util linux-vdso.so.1 (0x00007ffed54f7000) libusb-1.0.so.0 => /usr/local/lib/libusb-1.0.so.0 (0x000073306e600000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000073306e200000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x000073306e9b2000) libpthread.so.0...

Thanks so much, this solved the problem and I am now able to send the rootfs.ext4 file, but u-boot is rejecting it now (not dfu-util issue at this point). I think we can safely close this ticket. On Tue, Aug 6, 2024 at 2:06 AM Tormod Volden tormod@users.sourceforge.net wrote: Exactly, your dfu-util binary is run-time linking a libusb in /usr/local/bin: libusb-1.0.so.0 => /usr/local/lib/libusb-1.0.so.0 (0x000073d5ada00000) This is not the libusb that comes with the distro as part of libusb-1.0-0-dev,...

I followed the build manual on the dfu-util site. I already had libusb-1.0.0-dev installed. I did install dfu-util executable into /usr/local/bin. After running ldd: ldd /usr/local/bin/dfu-util linux-vdso.so.1 (0x00007ffee19ad000) libusb-1.0.so.0 => /usr/local/lib/libusb-1.0.so.0 (0x000073d5ada00000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000073d5ad600000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x000073d5adcb8000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x000073d5adcb3000)...