Recent

Author Topic: RP2040 with Picoprobe and FreePascal/Lazarus  (Read 3649 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
RP2040 with Picoprobe and FreePascal/Lazarus
« on: May 25, 2022, 01:13:45 pm »
Continuing the excellent discussion cited below and the associated links:

https://forum.lazarus.freepascal.org/index.php/topic,52996.0.html

https://wiki.freepascal.org/ARM_Embedded_Tutorial_-_Installing_Lazarus_and_Free_Pascal

https://wiki.freepascal.org/ARM_Embedded_Tutorial_-_FPC_and_the_Raspberry_Pi_Pico

I've got a pukka Pico sitting on a demo board https://www.cytron.io/p-maker-pi-pico, and a "postage stamp" Waveshare RP2040 Zero running Picoprobe with its UART pins also brought out. Running a Debian Linux host, I can load a "Hello, World!" written in C, capture the output from /dev/ttyACM0, and single-step using gdb connected via OpenOCD.

I have not yet worked through the "Using Visual Studio Code" chapter of the "Getting started with Raspberry Pi Pico" document, but it appears to provide adequate automation of OpenOCD hence gdb to allow debugging to be done: the only thing that needs to be done manually is to start a terminal emulator (minicom in the example) to capture UART traffic.

I've built Lazarus/FPC targeting the Pico using FPCUpdate. I was impressed at how well that went, but I must add that I was concerned at the idea of running a downloaded binary without a published hash/checksum against which I could verify it.

Noting https://github.com/michael-ring/pico-fpcexamples and again the "ARM Embedded Tutorial - FPC and the Raspberry Pi Pico" wiki page, I can see that it provides e.g. uartdemo.lpi and uartdemo.lpr and can verify that the copy of Lazarus described above opens and builds the project without error.



Now, from my POV the object of the exercise is to explain to a technical (but non-programmer) journalist the extent to which the RP2040+Picoprobe could be a gamechanger by making it far easier for lower-echelon developers to access a debugger on an embedded system. I've already gone to some amount of trouble to "educate" him regarding the roles of a traditional logic analyser and ICE although I haven't yet introduced him to the "shock hairstyle" that hooking up a target board often resembled.

For that reason, I've taken a fair amount of care to build a neat probe, with a ribbon cable for the SWD+power pins and a reversible three-way strip for the UART.

FPCUpdate and Lazarus acquit themselves honourably when it comes to building a .elf file for debugging.

But the description of starting OpenOCD at the bottom of https://wiki.freepascal.org/ARM_Embedded_Tutorial_-_Raspberry_Pi_Pico_Setting_up_for_Development is incomplete:

Code: [Select]
$ sudo /usr/local/share/fpcupdeluxed/ccr/develtools4fpc/bin/openocd-rp2040 -f board/pico.cfg
[sudo] password for markMLl:
Open On-Chip Debugger 0.10.0+dev-geb22ace (2021-03-09-20:09)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'swd'
Warn : Transport "swd" was already selected
/usr/local/share/fpcupdeluxed/ccr/develtools4fpc/bin/../share/openocd/scripts/board/pico.cfg:2: Error: Can't find target/RP2040.cfg
in procedure 'script'
at file "embedded:startup.tcl", line 26
at file "/usr/local/share/fpcupdeluxed/ccr/develtools4fpc/bin/../share/openocd/scripts/board/pico.cfg", line 2

...and while I'm sure I could work this out from the C stuff I was doing yesterday I thought it was better to raise this with the community.

So:

* What can be done to automate the startup of OpenOCD, since Visual Studio Code apparently does this?

* What can be done about automating the capture of UART output (USB or Serial, but in either case arriving on a /dev/ttyACM* device) to make Lazarus look better than Visual Studio Code?

* Once one has OpenOCD running and UART traffic captured (to a terminal emulator or, better, the console window) what is the crucial next step to load and start the binary?

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MiR

  • Full Member
  • ***
  • Posts: 246
Re: RP2040 with Picoprobe and FreePascal/Lazarus
« Reply #1 on: May 25, 2022, 01:38:40 pm »
The solution to your problem is pretty straightforward when I am correct, can you please try the following:

open

Code: Bash  [Select][+][-]
  1. /usr/local/share/fpcupdeluxed/ccr/develtools4fpc/share/openocd/scripts/board/pico.cfg

in an editor and change the line:

Code: Bash  [Select][+][-]
  1. source [find target/RP2040.cfg]  


to

Code: Bash  [Select][+][-]
  1. source [find target/rp2040.cfg]

I mainly tested on MacOSX which (as windows) by default has a non case-sensitive filesystem and that is the reason that this bug slipped through.

Let me know if changing this line fixed the issue, I will then release a new version of the develtools4fpc package.

Michael   

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: RP2040 with Picoprobe and FreePascal/Lazarus
« Reply #2 on: May 25, 2022, 02:32:36 pm »
That initially rewarded me with

Code: [Select]
$ sudo /usr/local/share/fpcupdeluxed/ccr/develtools4fpc/bin/openocd-rp2040 -f board/pico.cfg
[sudo] password for markMLl:
Open On-Chip Debugger 0.10.0+dev-geb22ace (2021-03-09-20:09)
...
Error: libusb_bulk_read error: LIBUSB_ERROR_IO
Info : DAP init failed
...

but unplugging and replugging the USB interface fixed it.

I note that the IDE thinks that the debugger backend is FpDebug, I presume it should be "GNU remote debugger (gdbserver)" with Debugger_Remote_Port changed from 2345 to 3333.

I'm carefully trying not to guess too much here so that we can change things from "Just about there" to "Very good indeed" :-)

If we could get things to the stage where I can load the program and run/step it, then I'll take a look to see whether a POSIX capability could be applied to openocd to avoid the need for sudo, and if it can be started from /etc/inetd.conf which would be a bit naughty but WTH. That would leave the only issue being that of starting a terminal emulator, or having some way of attaching the console window to a serial port.

Very slightly later: I tried guessing :-/

Setting backend to "GNU remote debugger (gdbserver)"  and naming the debugger "gdb-multiarch", with a port change to 3333, still doesn't allow me to set a breakpoint instead giving me a dialog(u)e "No debugger specified".

Lazarus 2.3.0 dated 24th May with FPC 3.3.1. Not sure whether there's an easy way to C&P the revision from the "About Lazarus" box.

MarkMLl
« Last Edit: May 25, 2022, 06:39:01 pm by MarkMLl »
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MiR

  • Full Member
  • ***
  • Posts: 246
Re: RP2040 with Picoprobe and FreePascal/Lazarus
« Reply #3 on: May 25, 2022, 02:57:14 pm »
Please follow/check the steps described on this page:
https://wiki.freepascal.org/ARM_Embedded_Tutorial_-_Raspberry_Pi_Pico_Debugging_the_onboard_LED

and ping back if following the steps worked.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: RP2040 with Picoprobe and FreePascal/Lazarus
« Reply #4 on: May 25, 2022, 03:10:51 pm »
Please follow/check the steps described on this page:
https://wiki.freepascal.org/ARM_Embedded_Tutorial_-_Raspberry_Pi_Pico_Debugging_the_onboard_LED

and ping back if following the steps worked.

The missing step was changing the original

/usr/local/share/fpcupdeluxed/fpcbootstrap/gdb/$(TargetCPU)-$(TargetOS)/gdb

to

/usr/local/share/fpcupdeluxed/ccr/develtools4fpc/bin/gdb-multiarch

I can now single-step etc. successfully :-)

I'll take a look at openocd startup, but possibly not until later in the day.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MiR

  • Full Member
  • ***
  • Posts: 246
Re: RP2040 with Picoprobe and FreePascal/Lazarus
« Reply #5 on: May 25, 2022, 03:11:49 pm »
Also found this article:
https://forgge.github.io/theCore/guides/running-openocd-without-sudo.html
if it works for you then please add the steps required to the Wiki (or tell me to do so...)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: RP2040 with Picoprobe and FreePascal/Lazarus
« Reply #6 on: May 25, 2022, 03:23:45 pm »
Thanks for that, it saves me from having to work out the "true name" of the interface being used.

That's almost certainly the "right" way to do it if the user has to start openocd manually, and is in line with what the Teensy (as one particular example) does. That type of hack isn't needed by things like Arduino, where the programming interface is actually a standard serial port (relying to DTR being ackled to force a reset, at which point the chip starts in bootloader mode).

Still leaves the issue of starting openocd though, it would be nice to be able to automate that.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MiR

  • Full Member
  • ***
  • Posts: 246
Re: RP2040 with Picoprobe and FreePascal/Lazarus
« Reply #7 on: May 25, 2022, 03:43:10 pm »
I had automatic starting enabled for other use-cases like jlink for arm, but in the end I did not go that way because it will then be necessary to have a tab with the output of the debug probe inside of lazarus to be able to debug issues that new users experience.

Michael

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: RP2040 with Picoprobe and FreePascal/Lazarus
« Reply #8 on: May 25, 2022, 03:58:15 pm »
It's doable, but like most daemon startup might be best used only by people who are confident in their overall configuration: I really don't know what had bombed/lockedup openocd this morning.

I think intercepting UART traffic is probably more important. I did some work on the console window a couple of years ago (different character representations etc.) but intercepting gdb output with uncertain coding got pretty hairy and I think Martin's disabled it as part of the transition to fpdebug.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MiR

  • Full Member
  • ***
  • Posts: 246
Re: RP2040 with Picoprobe and FreePascal/Lazarus
« Reply #9 on: May 25, 2022, 04:18:18 pm »
for automagically starting openocd you could perhaps use initexec_mode and initexec_remotetarget.

Seems that those two config entries allow a controlled start of preconditional apps, saw this page:

https://wiki.freepascal.org/Toro_Kernel

did not try it but shows promise.....


MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: RP2040 with Picoprobe and FreePascal/Lazarus
« Reply #10 on: May 25, 2022, 04:25:08 pm »
I anticipate a one-liner in /etc/inetd.conf, but the thing I need to be careful about is whether it reliably terminates when gdb drops out.

Anyway, right now I've got paperwork etc. to do. I'm even going to resist the temptation of CADing a matchbox for the probe... its simplicity might be better illustrated if the innards are visible.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: RP2040 with Picoprobe and FreePascal/Lazarus
« Reply #11 on: May 25, 2022, 06:51:41 pm »
On a Linux system, saving this file as /etc/udev/rules.d/50-rpi-picoprobe.rules and running the command at the top to tell the OS to notice the change will allow any user to start openocd without using sudo:

Code: [Select]
# Remember to  udevadm control --reload  after any changes.

# Assume that the CDC serial device (typically /dev/ttyACM0) has already been
# assigned to root:dialout on account of its class.

SUBSYSTEMS=="usb", ATTRS{idVendor}=="2e8a", ATTRS{idProduct}=="0004", ATTRS{product}=="Picoprobe", GROUP="plugdev", MODE="0660"

This is the same approach as is used by e.g. the Teensy, so I'm moderately confident that it is compatible with most current distreaux.

I notice that each Picoprobe appears to have a unique SerialNumber attribute. I suspect that if multiple openocd/gdb instances were being used to support several target systems simultaneously it would be possible to add that to the rules file.

Irrespective of any of the above, it is still necessary to start up openocd manually.

Somewhat later: I've drawn a blank trying to start openocd using inetd. The first thing that caused me grief was that it appears that (on Debian Linux) sending HUP to inetd doesn't force a restart reliably: one /has/ to use systemctl restart. Having got past that I was able to start the server on demand, but irrespective of whether I used the -p and/or wait/nowait options I couldn't get the protocol to run reliably: I recall that some daemons have a specific setting that allows them to run under inetd, and I suspect there's some fundamental incompatibility in the socket handling.

MarkMLl


Nerdnote: the combination that worked best was nowait in inetd.conf and both -p and -l on the openocd command line, but that was still a long way from working correctly. Looking at normal output suggests that the TCP connection is normally of short duration, and I suspect that this is fundamentally incompatible with having inetd waiting to reclaim the port.


« Last Edit: May 25, 2022, 09:38:43 pm by MarkMLl »
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: RP2040 with Picoprobe and FreePascal/Lazarus
« Reply #12 on: May 26, 2022, 11:18:05 am »
Under Linux, this is an adequate script to automatically start OpenOCD and a terminal emulator on completion of a compile or build. It behaves correctly if the project is rebuilt or the IDE is restarted.

Code: Text  [Select][+][-]
  1. #! /bin/sh
  2.  
  3. # This is a wrapper script to be run by the Lazarus IDE when interactively
  4. # debugging a Raspberry Pi Pico (RP2040 etc.) using a second Pico with the
  5. # Picoprobe firmware. It automatically starts a terminal emulator, plus a
  6. # copy of OpenOCD in the background typically listening for a gdb connection
  7. # on port 3333.
  8. #
  9. # To bring GNU Screen to the foreground use the  screen -r  command. To send
  10. # it to the background use <Ctrl>ad  To terminate it when used as a terminal
  11. # emulator use <Ctrl>ak and confirm the prompt.                 MarkMLl
  12.  
  13. #############################################################################
  14.  
  15. # Specify the serial port provided by the Picoprobe. This is likely to change
  16. # whenever it is removed and replaced, particularly if there are other USB
  17. # devices of the communications class.
  18.  
  19. UART=/dev/ttyACM0
  20.  
  21. # Specify the location of the OpenOCD binary, and command lines for the most
  22. # popular terminal emulators.
  23.  
  24. OPENOCD=/usr/local/share/fpcupdeluxed/ccr/develtools4fpc/bin/openocd-rp2040
  25. GTKTERM="gtkterm -p $UART -s 115200"
  26. MINICOM="minicom -D $UART -b 115200"
  27. SCREEN="screen $UART 115200"
  28.  
  29. # Specify which of the above terminal emulators is to be used.
  30.  
  31. TERMINALEMULATOR=$GTKTERM
  32.  
  33. # Start the terminal emulator and a copy of OpenOCD if not already running.
  34. # If one or the other has been terminated it will be necessary to clean up
  35. # manually (see note on using GNU Screen etc. at the start of this file).
  36.  
  37. if [ ! -d /proc/`cat $HOME/openocd.3333`/fd ] ; then
  38.   $TERMINALEMULATOR > /dev/null 2>&1 &
  39.   screen -d -m $OPENOCD -f board/pico.cfg
  40.   ps ax | grep pico.cfg | grep Ssl | cut -d ' ' -f 1 > $HOME/openocd.3333
  41.   echo -n 'OpenOCD started'
  42. else
  43.   echo -n 'OpenOCD already running'
  44. fi
  45. echo ", PID `cat $HOME/openocd.3333`"
  46.  

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: RP2040 with Picoprobe and FreePascal/Lazarus
« Reply #13 on: May 27, 2022, 01:08:00 pm »
Minor details in the spirit of constructive criticism.

The project options contain a ../units directory on the path which is in pico-fpcexamples (from Github?). This could usefully be something relative to the compiler or IDE location, so that it is valid for projects other than the supplied demo ones.

The user could usefully be given the option of saving the Pico settings as his default if it's not already done, since otherwise he will have to transcribe not only the path above when creating a new project but also the target details.

Copying the code from the UART demo and using it as the starting point of a new project, I get a dialogue "Project mydemo raised exception class 'External: 0'. In file 'arm/cortexm0p_start.inc' at line 63'

Code: [Select]
procedure Startup; assembler; nostackframe; [public, alias: '_START'];
asm
  ldr r1,.L_etext     <===== Line 63
  ldr r2,.L_data
  ldr r3,.L_edata   
...

but this doesn't appear to impact normal operation.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MiR

  • Full Member
  • ***
  • Posts: 246
Re: RP2040 with Picoprobe and FreePascal/Lazarus
« Reply #14 on: May 28, 2022, 10:36:04 am »
Keep your remarks coming, I am sure a number of things can be improved.

I tried to make the project as self-contained as possible, simply clone it, open a lpi in Lazarus an compile+deploy.
There is a script that allows you to add a new project genlpi.sh that adds a new subdir with proper configuration to the project.
Perhaps this part needs a little more explanation in the wiki.
Having a wizard for embedded in lazarus would be great but honestly I am more a command-line guy so my motivation on doing gui work is pretty low.

 

TinyPortal © 2005-2018