Skip to content

New compile failure after changing picoprobe to debugprobe #44

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dshadoff opened this issue Sep 15, 2024 · 9 comments · May be fixed by #47
Open

New compile failure after changing picoprobe to debugprobe #44

dshadoff opened this issue Sep 15, 2024 · 9 comments · May be fixed by #47

Comments

@dshadoff
Copy link

Note: I did not see this last month prior to the commit of #31 ,
Today, I tried a new, fresh clone of pico-setup, and got an error which wasn't previously occurring. It is within the debugprobe clone repo, apparently due to an error with a module reference to CMSIS_5.
Not the debugprobe -> CMSIS_5 reference; that appears to be OK.
Instead there appears to be a different reference in the chain debugprobe -> freertos -> CMSIS_5 (this is getting complicated).

Maybe this issue should be logged in the debugprobe repository, but I really won't be able to spend time on managing that issue (aside from maybe re-attempting a compile) as I am not at all familiar with that module; I merely wanted a minimal instance of the SDK and dependencies.

For now, I have removed 'debugprobe' from the script's "for REPO in debugprobe picotool" line in order to complete the install.

Here is the error output:

Cloning into 'debugprobe'...
remote: Enumerating objects: 526, done.
remote: Counting objects: 100% (526/526), done.
remote: Compressing objects: 100% (272/272), done.
remote: Total 526 (delta 385), reused 296 (delta 249), pack-reused 0 (from 0)
Receiving objects: 100% (526/526), 112.40 KiB | 1.46 MiB/s, done.
Resolving deltas: 100% (385/385), done.
Submodule 'CMSIS_5' (https://github.com/ARM-software/CMSIS_5) registered for path 'CMSIS_5'
Submodule 'freertos' (https://github.com/raspberrypi/FreeRTOS-Kernel) registered for path 'freertos'
Cloning into '/home/dshadoff/devel/pico/pico-setup/pico/debugprobe/CMSIS_5'...
Cloning into '/home/dshadoff/devel/pico/pico-setup/pico/debugprobe/freertos'...
git-lfs filter-process: 1: git-lfs: not found
fatal: the remote end hung up unexpectedly
fatal: Unable to checkout 'a65b7c9a3e6502127fdb80eb288d8cbdf251a6f4' in submodule path 'CMSIS_5'
dshadoff@raspi5-4gb:~/devel/pico/pico-setup $ 

Note that this was attempted on a recent install of of the Raspberry Pi OS on a RPi5:

uname -a
Linux raspi5-4gb 6.6.31+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.31-1+rpt1 (2024-05-29) aarch64 GNU/Linux

@lurch
Copy link
Contributor

lurch commented Feb 10, 2025

I just ran the pico_setup.sh script myself on a Raspberry Pi 500, and it ran okay to completion with no errors.

git-lfs filter-process: 1: git-lfs: not found

That seems to be your problem? Does it work okay if you sudo apt install git-lfs first?
I dunno why git-lfs was needed for you though and not for me - I don't have it installed 😕 @will-v-pi Should we add git-lfs to https://github.com/raspberrypi/pico-setup/blob/master/pico_setup.sh#L20 just to be on the safe side?
Ahh, and see also raspberrypi/debugprobe#64

@will-v-pi
Copy link
Contributor

Should we add git-lfs to https://github.com/raspberrypi/pico-setup/blob/master/pico_setup.sh#L20 just to be on the safe side?

Yeah, that sounds like a sensible fix to me - at a guess I'd say different versions of git might not include git-lfs or something, or maybe a difference between Lite OS and Full OS?

lurch added a commit that referenced this issue Feb 10, 2025
@lurch lurch linked a pull request Feb 10, 2025 that will close this issue
@dshadoff
Copy link
Author

I just ran the pico_setup.sh script myself on a Raspberry Pi 500, and it ran okay to completion with no errors.

git-lfs filter-process: 1: git-lfs: not found

That seems to be your problem? Does it work okay if you sudo apt install git-lfs first? I dunno why git-lfs was needed for you though and not for me - I don't have it installed 😕 @will-v-pi Should we add git-lfs to https://github.com/raspberrypi/pico-setup/blob/master/pico_setup.sh#L20 just to be on the safe side? Ahh, and see also raspberrypi/debugprobe#64

I would love to be able to answer this question, but now I'm unable to get even this far in the build.

Since the original issue was opened 5 months ago, I have now performed all of the linux upgrade instructions (sudo apt update, sudo apt full-upgrade etc.) in order to try to approximate a similar build environment to you, and I have removed the prior pico-setup clone repo from the system.

The new issue appears to be the same as raspberrypi/pico-sdk#1990 , claiming: "Incompatible picotool installation found: Requires version 2.1.0, you have version 2.0.0" , even though I have completely removed all of the prior clones of raspberrypi pico-related repositories, and cleaned picotool out from the /usr/local/bin directory. I have no idea where it thinks it's finding it, and there doesn't seem to be a message indicating where.

I'm not sure where I am expected to "set PICOTOOL_FORCE_FETCH_FROM GIT", as performing an "export PICOTOOL_FORCE_FETCH_FROM_GIT=1" was ineffectual at resolving this.

I thought pico-setup was supposed to be the easiest/fastest way to install the SDK ?

@lurch
Copy link
Contributor

lurch commented Feb 10, 2025

I thought pico-setup was supposed to be the easiest/fastest way to install the SDK ?

It is, on a clean Raspberry Pi OS installation; but it doesn't work properly if it's run multiple times - see #10

You might also want to look at https://github.com/raspberrypi/pico-vscode which might be more robust / self-contained?

@dshadoff
Copy link
Author

dshadoff commented Feb 10, 2025

I thought pico-setup was supposed to be the easiest/fastest way to install the SDK ?

It is, on a clean Raspberry Pi OS installation; but it doesn't work properly if it's run multiple times - see #10

This is unrelated; Each time I try to rerun, I nuke the cloned repo, and re-clone from first principles.

This worked great for each of the SDK 1.x versions, but I've never had a single successful build from a SDK 2.x instance.
I'm only re-running because of all the failures; a full reinstall of the OS each time seems senseless.

@dshadoff
Copy link
Author

Update:

  1. Since the build was failing during the build of 'pico' in pico-examples, I moved the step of building picotool to immediately prior to this, and picotool was built properly and installed into /usr/local/bin as expected.

However, during the step where it builds 'pico' in pico-examples, it failed again, claiming that my picotool was version 2.0.0 even though the only executable I can find (and the one in the execution path) is the one just built, which is 2.1.0 .

  1. Since the major step for building picotool originally also built debugprobe, I decide to arrange the script so that the loop to build both debugprobe and picotool executes immediately prior to the 'pico' in pico-examples.

In answer to your question from earlier today, yes, the git-lfs issue reappeared during the build of debugprobe.
Performing the sudo apt install git-lfs was successful in getting past that step in debugprobe, but again it dies, based on thinking that I have a v2.0.0 picotool in an undisclosed location.

So, ultimately, some progress, but another issue uncovered.

@dshadoff
Copy link
Author

Second update:

I now have the build working, with no fewer than three fixes required:

  1. Since this should be equally useful as an upgrade as it is for a new installation, and since debugprobe and pico-examples both have a dependency on a current version of picotool, the build sequence needs to be changed to: a) picotool, b) debugprobe, c) examples (not examples, debugprobe, picotool as it is in the master branch).

  2. It is not sufficient to copy the 'picotool' executable to "/usr/local/bin/picotool" as this script currently does; this must be changed to "sudo make install" in order to update hidden pointers.

  3. As previously identified, the git-lfs dependency, for which lurch already has a pull request.

@will-v-pi
Copy link
Contributor

1 & 2 will be fixed by #43 once that’s merged

@dshadoff
Copy link
Author

Would it be possible to expedite these updates ?
The script in the repository hasn't been updated in 6 months, since before SDK 2.1 (and it doesn't seem to be locked to a release cycle).

That pull request seems to be outstanding for about the same amount of time, while people continue to use this script and trip over the same issues. (for example, https://forums.raspberrypi.com/viewtopic.php?t=383765 )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants