RPi Pico Unique ID samle

[kicsoft]

Hi there,

I am trying to get the Unique ID to work on the RPi Pico but so far no luck.

I have created a new VisualGDB project using the wizard and I pick the “system\unique_board_id” sample project as the template and everything builds just fine.

However when I upload and run the project then the Pico seems to be crashing.

I also tried to add the sample code from the “blink” example right after the debug printout of the unique ID (so I can tell that the Pico is actually running without a SWD debugger) but I believe it never gets through the initialization code where the ID is read from the flash during boot.

Has anyone seen the same issue?

Cheers

[support]

Hi,

This looks like an possible bug in the the Raspberry Pi SDK or example library, rather than a VisualGDB-specific issue. Please feel free to post this on the Raspberry Pi forums – perhaps other Raspberry Pi users have encountered the same issue.

That said, if you can confirm that the project works as expected when built manually and doesn’t work when built with VisualGDB, we can gladly investigate this further and make sure VisualGDB produces the same results as the manual build.

[kicsoft]

Thanks for the quick reply!

I was thinking the same that I probably need to build the sample manually directly using the PicoSDK. However I am a bit hesitant to install the C/C++ PicoSDK development tools because I am worried it break my VisualGDB toolchain settings.

Are you aware of any know issues (with respect to already having a working VisualGDB setup) if I run the Windows PicoSDK toolchain installer from the Raspberry Pi Pico forum? It will afaik install Microsoft Code and the ARM compiler and possibly change environment variables.

[support]

Hi,

VisualGDB always sets the environment based on the project settings, so there no need to worry about installing more tools manually.

[kicsoft]

Hi again,

Today I installed the Pico SDK and development tool using the latest release of “Pico Setup for Windows” found here: GitHub – ndabas/pico-setup-windows: Quickly get started with Raspberry Pi Pico/RP2040 on Windows

I then followed the getting started guide and got VS Code loading the pico-examples and after a complete rebuild of all samples and the necessary tools, I then loaded the unique_board_id.uf2 onto my Pico and this worked out of the box. I could now see the Unique ID on the serial debug port.

However: when I compile and run the same example that was created using the VisualGDB Pico wizard then it still crashes.

So I have to conclude that something is wrong/missing in the VisualGDB project when I create it from the exact same sample in the PicoSDK.

I installed my Segger JLink and used the SWD debugger in Visual Studio 2019 with VisualGDB in order to find out what happened and I see that an “Received a SIGINT: Interrupt” is thrown when the initialization code tries to read the ID from the flash (when trying to set the CS low on the QSPI bus).

Here is the stack trace:

0xfffffffe
<signal handler called>
> hw_write_masked C++ (gdb)
flash_cs_force C++ (gdb)
flash_do_cmd C++ (gdb)
flash_get_unique_id C++ (gdb)
_retrieve_unique_id_on_boot C++ (gdb)
runtime_init C++ (gdb)
platform_entry C++ (gdb)

 

It looks to me like the _retrieve_unique_id_on_boot() function might be called too early before the QSPI GPIO configuration has been initialized or perhaps something else is missing!?

Cheers

[support]

No problem, we can investigate it further.

First of all, please try double-checking that uploading the .uf2 file generated by VisualGDB yields different results than uploading the .uf2 file generated manually. If not, the problem might be related to running the code under a debugger in general.

If the two .uf2 files behave differently, please double-check that they use the same version of the SDK. If not, the bug could be specific to the SDK version used by VisualGDB.

If the SDK is the same, please try extracting the configuration/build command lines used by VisualGDB (see this page) and comparing them with the CMake/Ninja command lines used when built manually. If there are any differences, please let us know and we will recheck it further.

You can also try comparing both ELF files (the one produced by VisualGDB and the one produced via manual build) via Memory Explorer, or simply attaching them here so that we could recheck for any clear differences.

[kicsoft]

Just now I tried to disconnect the Segger JLink and simply drag the uf2 output file from the VisualGDB output folder to the RPI-RP2 drive but it still crashes just like before with the debugger…

Both projects use the latest PicoSDK 1.1.2.

Please find attached the elf files from the two builds.

And I have tried to export the configuration and build commands from VisualGDB as well, but I am not sure how to get these from the PicoSDK Visual Code build system.

[kicsoft]

Looks like the attachments were rejected.

I renamed the commands to .txt to see whether that helps…

Attachments:

You must be logged in to view attached files.

[support]

Thanks, we have reproduced the problem and found the root cause. In order to improve debugging experience, VisualGDB configures the Pico SDK to completely disable optimization in debug builds by passing the PICO_DEOPTIMIZED_DEBUG=1 parameter to CMake.

This disables substitution of inline functions and triggers a bug in the Pico SDK.

We have created a Github issue describing the bug and a suggested fix here: https://github.com/raspberrypi/pico-sdk/issues/371. Feel free to upvote it.

As a workaround, please consider patching the address_mapped.h file per our description, or disabling the VisualGDB Project Properties -> Raspberry Pi Project -> Raspberry Pi SDK -> Disable optimization for debug builds setting.

[kicsoft]

Thank you for the quick help on this! I am impressed and very pleased with this high level of support.

I will patch the address_mapped.h for now like suggested in the PicoSDK bug report.

Cheers

[support]

No worries. As the problem did not happen when building the project manually per Pico SDK instructions, there was a chance that it could be a VisualGDB bug, so we investigated it further.

As the underlying bug ended up rather trivial and could affect other VisualGDB users (we still believe that disabling optimization for debug builds does more good than harm), we reported it to the Pico SDK maintainers.

[Author]

Posts