On Mon, Apr 14, 2025 at 04:11:40PM +0200, Tomek CEDRO wrote:
> Yeah I also had problems flashing this rpiPico boards with USB MSC
> method (mount+cp+umount) on FreeBSD.. is there a OpenOCD like method
> so I could try too? :-)

On FreeBSD I never mount and just dd directly to the device with bs=1M.
That should work for other OS as well.
I never tried to flash via swd, since the USB method worked fine for me.

About the pico probe.
It is a SWD debugger using the DBGU protocoll on USB.
Already used a pico with pico probe firmware to flash Atmel controllers in
the field, since the picos are super cheap to get.
In my lab I use an Atmel-ICE on various Atmel and STM32, which in theorie
should work as well for the RP2040, but I never used a debugger on an RP2040
yet.
The Atmel-ICE uses DBGU as well, however any OpenOCD compatble SWD adapter
should work.

> Tomek
> 
> On Mon, Apr 14, 2025 at 4:09 PM Alan C. Assis <acas...@gmail.com> wrote:
> >
> > Thank you Sebastien,
> >
> > Seems an interesting alternative, but ordering from the Internet will
> > arrive fast too.
> >
> > BR,
> >
> > Alan
> >
> > On Mon, Apr 14, 2025 at 10:43 AM Sebastien Lorquet <sebast...@lorquet.fr>
> > wrote:
> >
> > > Hello
> > >
> > > If you are in a hurry you can use another pico as picoprobe
> > >
> > >
> > > https://mcuoneclipse.com/2022/09/17/picoprobe-using-the-raspberry-pi-pico-as-debug-probe/
> > >
> > > I find that quite cool.
> > >
> > > Sebastien
> > >
> > >
> > > On 14/04/2025 14:09, Alan C. Assis wrote:
> > > > Hi Kevin,
> > > >
> > > > I will order a Pico Debug probe, it is something new for me.
> > > >
> > > > In fact it seems like a heisenbug, I just compiled from mainline and
> > > after
> > > > drag and drop it worked, but this time I had to use nautilus with sudo
> > > > because the Copy option to RPI-RP2 disk wasn't working.
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > > On Mon, Apr 14, 2025 at 8:48 AM Kevin Witteveen <kevinwit1...@gmail.com>
> > > > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Thanks for the fast response.
> > > >> I'm glad posting this issue to the mailing list was worth it. The 
> > > >> github
> > > >> issue got no attention.
> > > >> The RP2040 support is very important to me.
> > > >>
> > > >> There is something I want to add to this issue.
> > > >>
> > > >> -- Flashing --
> > > >>
> > > >> I mainly flash the firmware using the Pico Debug probe or the picotool
> > > via
> > > >> USB.
> > > >> I tested the drag&drop method and it actually does create ttyACMx for
> > > me.
> > > >> But what concerns me is that this can be another unreliable symptom or
> > > >> "heisenbug".
> > > >>
> > > >> Best,
> > > >>
> > > >> Kevin
> > > >>
> > > >> Op ma 14 apr 2025 om 13:27 schreef Alan C. Assis <acas...@gmail.com>:
> > > >>
> > > >>> Hi Kevin and Alin,
> > > >>>
> > > >>> I confirmed that NuttX 12.9-RC1 is broken on Raspberry Pi Pico.
> > > >>>
> > > >>> After copying the nuttx.uf2 to virtual disk RPI-RP2 the board restart
> > > by
> > > >>> the /dev/ttyACM0 is not created.
> > > >>>
> > > >>> Please find the steps below:
> > > >>>
> > > >>> alan@dev:/tmp$ cd nuttx/
> > > >>> alan@dev:/tmp/nuttx$ . tools/configure_completion.bash
> > > >>> alan@dev:/tmp/nuttx$ ./tools/configure.sh raspberrypi-pico:usbnsh
> > > >>>
> > > >>> alan@dev:/tmp/nuttx$ make -j
> > > >>> Create version.h
> > > >>> LN: platform/board to /tmp/apps/platform/dummy
> > > >>> Register: hello
> > > >>> Register: nsh
> > > >>> Register: sh
> > > >>> Register: getprime
> > > >>> Register: ostest
> > > >>> CPP:
> > > >>>
> > > >>>
> > > >>
> > > /tmp/nuttx/boards/arm/rp2040/raspberrypi-pico/scripts/raspberrypi-pico-flash.ld->
> > > >>> /tmp/nuLD: nuttx
> > > >>> Memory region         Used Size  Region Size  %age Used
> > > >>>             flash:        152 KB         2 MB      7.42%
> > > >>>              sram:        8872 B       264 KB      3.28%
> > > >>> Generating: nuttx.uf2
> > > >>> Done.
> > > >>>
> > > >>> alan@dev:/tmp/nuttx$ arm-none-eabi-gcc -v
> > > >>> Using built-in specs.
> > > >>> COLLECT_GCC=arm-none-eabi-gcc
> > > >>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/13.2.1/lto-wrapper
> > > >>> Target: arm-none-eabi
> > > >>> Configured with: ../configure --build=x86_64-linux-gnu --prefix=/usr
> > > >>> --includedir='/usr/lib/include' --mandir='/usr/lib/share/man'
> > > >>> --infodir='/usr/lib/share/info' --sysconfdir=/etc --localstatedir=/var
> > > >>> --disable-option-checking --disable-silent-rules
> > > >>> --libdir='/usr/lib/lib/x86_64-linux-gnu'
> > > >>> --libexecdir='/usr/lib/lib/x86_64-linux-gnu' --disable-maintainer-mode
> > > >>> --disable-dependency-tracking --mandir=/usr/share/man
> > > >>> --enable-languages=c,c++,lto --enable-multilib --disable-decimal-float
> > > >>> --disable-libffi --disable-libgomp --disable-libmudflap
> > > >>> --disable-libquadmath --disable-libssp --disable-libstdcxx-pch
> > > >>> --disable-nls --disable-shared --disable-threads --enable-tls
> > > >>> --build=x86_64-linux-gnu --target=arm-none-eabi --with-system-zlib
> > > >>> --with-gnu-as --with-gnu-ld --with-pkgversion=15:13.2.rel1-2
> > > >>> --without-included-gettext --prefix=/usr/lib
> > > >>> --infodir=/usr/share/doc/gcc-arm-none-eabi/info
> > > >>> --htmldir=/usr/share/doc/gcc-arm-none-eabi/html
> > > >>> --pdfdir=/usr/share/doc/gcc-arm-none-eabi/pdf --bindir=/usr/bin
> > > >>> --libexecdir=/usr/lib --libdir=/usr/lib --disable-libstdc++-v3
> > > >>> --host=x86_64-linux-gnu --with-headers=no --without-newlib
> > > >>> --with-multilib-list=rmprofile,aprofile ASFLAGS= ASFLAGS_FOR_BUILD=
> > > >>> CFLAGS='-g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
> > > >>>
> > > >>>
> > > >>
> > > -ffile-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=.
> > > >>> -flto=auto -ffat-lto-objects -fstack-protector-strong
> > > >>> -fstack-clash-protection -Wno-format -Wno-error=format-security
> > > >>> -fcf-protection
> > > >>>
> > > >>>
> > > >>
> > > -fdebug-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=/usr/src/gcc-arm-none-eabi-15:13.2.rel1-2'
> > > >>> 'CFLAGS_FOR_BUILD=-g -O2' CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=3'
> > > >>> CPPFLAGS_FOR_BUILD= CXXFLAGS='-g -O2 -fno-omit-frame-pointer
> > > >>> -mno-omit-leaf-frame-pointer
> > > >>>
> > > >>>
> > > >>
> > > -ffile-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=.
> > > >>> -flto=auto -ffat-lto-objects -fstack-protector-strong
> > > >>> -fstack-clash-protection -Wno-format -Wno-error=format-security
> > > >>> -fcf-protection
> > > >>>
> > > >>>
> > > >>
> > > -fdebug-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=/usr/src/gcc-arm-none-eabi-15:13.2.rel1-2'
> > > >>> 'CXXFLAGS_FOR_BUILD=-g -O2' DFLAGS=-frelease 
> > > >>> DFLAGS_FOR_BUILD=-frelease
> > > >>> FCFLAGS='-g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
> > > >>>
> > > >>>
> > > >>
> > > -ffile-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=.
> > > >>> -flto=auto -ffat-lto-objects -fstack-protector-strong
> > > >>> -fstack-clash-protection -fcf-protection
> > > >>>
> > > >>>
> > > >>
> > > -fdebug-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=/usr/src/gcc-arm-none-eabi-15:13.2.rel1-2'
> > > >>> 'FCFLAGS_FOR_BUILD=-g -O2' FFLAGS='-g -O2 -fno-omit-frame-pointer
> > > >>> -mno-omit-leaf-frame-pointer
> > > >>>
> > > >>>
> > > >>
> > > -ffile-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=.
> > > >>> -flto=auto -ffat-lto-objects -fstack-protector-strong
> > > >>> -fstack-clash-protection -fcf-protection
> > > >>>
> > > >>>
> > > >>
> > > -fdebug-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=/usr/src/gcc-arm-none-eabi-15:13.2.rel1-2'
> > > >>> 'FFLAGS_FOR_BUILD=-g -O2' LDFLAGS='-Wl,-Bsymbolic-functions -flto=auto
> > > >>> -ffat-lto-objects -Wl,-z,relro' LDFLAGS_FOR_BUILD= OBJCFLAGS='-g -O2
> > > >>> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
> > > >>>
> > > >>>
> > > >>
> > > -ffile-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=.
> > > >>> -flto=auto -ffat-lto-objects -fstack-protector-strong
> > > >>> -fstack-clash-protection -Wno-format -Wno-error=format-security
> > > >>> -fcf-protection
> > > >>>
> > > >>>
> > > >>
> > > -fdebug-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=/usr/src/gcc-arm-none-eabi-15:13.2.rel1-2'
> > > >>> 'OBJCFLAGS_FOR_BUILD=-g -O2' OBJCXXFLAGS='-g -O2
> > > -fno-omit-frame-pointer
> > > >>> -mno-omit-leaf-frame-pointer
> > > >>>
> > > >>>
> > > >>
> > > -ffile-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=.
> > > >>> -flto=auto -ffat-lto-objects -fstack-protector-strong
> > > >>> -fstack-clash-protection -Wno-format -Wno-error=format-security
> > > >>> -fcf-protection
> > > >>>
> > > >>>
> > > >>
> > > -fdebug-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=/usr/src/gcc-arm-none-eabi-15:13.2.rel1-2'
> > > >>> 'OBJCXXFLAGS_FOR_BUILD=-g -O2'
> > > >>> INHIBIT_LIBC_CFLAGS=-DUSE_TM_CLONE_REGISTRY=0
> > > >>> AR_FOR_TARGET=arm-none-eabi-ar AS_FOR_TARGET=arm-none-eabi-as
> > > >>> LD_FOR_TARGET=arm-none-eabi-ld NM_FOR_TARGET=arm-none-eabi-nm
> > > >>> OBJDUMP_FOR_TARGET=arm-none-eabi-objdump
> > > >>> RANLIB_FOR_TARGET=arm-none-eabi-ranlib
> > > >>> READELF_FOR_TARGET=arm-none-eabi-readelf
> > > >>> STRIP_FOR_TARGET=arm-none-eabi-strip SED=/bin/sed SHELL=/bin/sh
> > > >>> BASH=/bin/bash CONFIG_SHELL=/bin/bash
> > > >>> Thread model: single
> > > >>> Supported LTO compression algorithms: zlib
> > > >>> gcc version 13.2.1 20231009 (15:13.2.rel1-2)
> > > >>>
> > > >>>
> > > >>> NuttX support on Raspberry Pi is very important (low cost board widely
> > > >>> available), so I suggest we work fixing it before releasing the
> > > official
> > > >>> 12.9 release.
> > > >>>
> > > >>> BR,
> > > >>>
> > > >>> Alan
> > > >>>
> > > >>>
> > > >>> On Mon, Apr 14, 2025 at 8:12 AM Alan C. Assis <acas...@gmail.com>
> > > wrote:
> > > >>>
> > > >>>> Hi Kevin,
> > > >>>>
> > > >>>> Thanks for reporting the issue!
> > > >>>>
> > > >>>> I will test the new 12.9-RC1 on rasp pico and if the issue happen
> > > >> there I
> > > >>>> will suggest Alin to wait before releasing the final 12.9 version.
> > > >>>>
> > > >>>> BR,
> > > >>>>
> > > >>>> Alan
> > > >>>>
> > > >>>> On Mon, Apr 14, 2025 at 7:46 AM Kevin Witteveen <
> > > >> kevinwit1...@gmail.com>
> > > >>>> wrote:
> > > >>>>
> > > >>>>> Hi NuttX,
> > > >>>>>
> > > >>>>> This is a follow up on previous github issues.
> > > >>>>>
> > > >>>>> After building and flashing my RP2040 based boards with NuttX on any
> > > >> OS,
> > > >>>>> for example Windows, Linux, macOS and different machines (including 
> > > >>>>> a
> > > >>>>> clean
> > > >>>>> Linux install) with default configurations, they do not pass the
> > > >> ostest.
> > > >>>>> Symptoms:
> > > >>>>>
> > > >>>>> The ostest freezes up around the watchdog test, but sometimes it
> > > >> happens
> > > >>>>> on
> > > >>>>> different tests as well. The entire OS hangs in random applications
> > > >> too.
> > > >>>>> Another problem is that if you run "help", the output is a mess.
> > > >>>>>
> > > >>>>> However, the very strange part is that sometimes this issue does not
> > > >>> show
> > > >>>>> up at all.
> > > >>>>>
> > > >>>>> To reproduce:
> > > >>>>>
> > > >>>>> Any configuration, any OS, any machine. Run "help" to see a
> > > misaligned
> > > >>>>> mess. Run ostest to see it freeze up. Some apps might fail too.
> > > >>>>> But sometimes things just run fine.
> > > >>>>>
> > > >>>>> Tested on:
> > > >>>>>
> > > >>>>> Raspberry Pi Pico (two boards)
> > > >>>>> Raspberry Pi Pico W
> > > >>>>> Custom RP2040 board
> > > >>>>> RAKwireless RAK4630 RP2040
> > > >>>>> Non-RP2040 boards (they pass and work fine)
> > > >>>>> RP2040 boards with year-old firmware (they pass and work fine)
> > > >>>>>
> > > >>>>> The frustrating part:
> > > >>>>>
> > > >>>>> I tried to figure out the problem, and sometimes it seems like I
> > > found
> > > >>> it,
> > > >>>>> because after changing some configurations or apps, it starts 
> > > >>>>> working
> > > >>>>> again. Only to break after flashing it a few more times with tiny
> > > >>> changes.
> > > >>>>> USB:
> > > >>>>>
> > > >>>>> I previously thought USB was the issue, because it looked like the
> > > >>> system
> > > >>>>> didn’t crash if USB wasn’t connected. But later the OS started
> > > hanging
> > > >>>>> even
> > > >>>>> without using USB at all.
> > > >>>>>
> > > >>>>> Help:
> > > >>>>>
> > > >>>>> I’m unable to figure out the problem and this is blocking my
> > > projects,
> > > >>>>> including some driver development for NuttX.
> > > >>>>> Can anyone help test this or try to reproduce it?
> > > >>>>>
> > > >>>>> Thanks,
> > > >>>>>
> > > >>>>> Kevin (MartiniMarter github)
> > > >>>>>
> > >
> 
> 
> 
> -- 
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

-- 
B.Walter <be...@bwct.de> https://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

Reply via email to