Issue with pico_unique_id

[smithps]

Hi all,
I believe I have discovered some issue with pico_unique_id example, but can't for the life of me figure out how to find out what it is....

Firstly, in it's existing form, I feel the example program is not much use to a beginner as it sends the ID out through the UART.....most people won't have a USB serial port plugged into GPIO0 and GPIO1, so I thought I'd build it to use USB for stdout. In my mind most people will have purchased a single Pico to play with and would expect the example to work without having to purhase any additional bits.

As it happens, I do have a 3.3v serial port adapter and when the example is built, running with my external USB-Serial adapter connected, the example runs and emits the expected uniqe serial number string. Great!

When compiled to use USB for stdout, I get nothing and the USB doesn't even initialise properly....so more investigation required.;

Ok, I think to myself, lets run the standard example code under OpenOCD and find out what's going on as I happen to have a spare Pico too !

Here's where it gets interesting....

The standard pico_unique_id example which runs quite happily without the debugger won't run under the debugger using OpenOCD and causes a SIGINT on the line:

inline static void hw_write_masked(io_rw_32 *addr, uint32_t values, uint32_t write_mask) {

which in turn is called from flash_cs_force

The best I can figure out at the moment is that it's something going wrong in the constructor code that's run from the runtime_init.

So I have two (related?) problems with this example, and one request

1. I can't debug the standard example using openOCD debugger.
2. When it is built to use USB for stdout it crashes and I can't find out why because I can't debug it (Crashes at the same point with the same fault)

The request is "Can this example be made to work without the need for an external serial port?"

[lurch]

When compiled to use USB for stdout, I get nothing and the USB doesn't even initialise properly

That's because the Pico initialises it's USB connection, prints out the unique-id and then "exits" (because there's no infinite-loop running), at which point the USB connection on the Pico "disappears". However this all happens so fast that your PC doesn't have time to enumerate the USB-connection before the Pico stops running. (which is why it appears that "the USB doesn't even initialise properly").
See also #60 and raspberrypi/pico-sdk#333

won't run under the debugger using OpenOCD and causes a SIGINT on the line:

That's something for @kilograham to look at, but if you're single-stepping through code under the debugger, maybe there's some timing-sensitive part of code that you're upsetting? 🤷

[smithps]

Hi @lurch,
thanks for spotting the schoolboy error in my not noticing that main() didn't have an infinite loop. I completely understand what you're saying. After posting my message I also saw that @giripriyadarshan has suggested a change (#60). I think this is a good change to merge in.

As for the crash I'm experiencing I am beginning to think this might be related to my build environment - If I build under Visual Studio command prompt with an nmake, and drop the UF2 file onto the drive it runs perfectly well over USB.

If I build/run using VisualGDB & VS2017 then it just doesn't run at all (under debug environment or not). I might pass this over to the guys at VisualGDB and see if they can reproduce for me, or suggest what the cause would be.

Will update all as to my investigations.

Thanks.

More investigation my end will be made.

[lurch]

This may or may not be related to your problem, but in other issues we've seen that the ARM compiler/linker included with VS2017 isn't able to successfully generate binaries for the Pico, and you instead need to configure it to use the compiler downloaded from https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads

[smithps]

Hi @lurch,
in this case I don't think it's relevant as I've been building all the examples and some of my own ported code using this setup. I'm currently in the process of setting up a "fresh" install on a Virtual Machine to see what happens.

[kilograham]

Note w.r.t. running under debug, you may have an issue if you have also set PICO_DEOPTIMIZED_DEBUG=1 (raspberrypi/pico-sdk#371)

@lurch - i think i've seen a bunch of issues with VS Code debug; i thought this had been fixed in the docs, but I believe there is a missing "monitor reset init" before the gdb program load?

[smithps]

@lurch, @kilograham

I just checked with picotool, and although the build was not reported as "All optimization disabled" , the addition of attribute((always_inline)) to the calls of hw_write_masked() and hw_xor_bits() does fix the issue in this instance.

I see that @kilograham's merged changes use __force_inline instead of attribute((always_inline)) .... is this essentially the same?

P.S. I note that @kilograham's code change uses the keyword __force_inline (with an underscore), but that GCC documentation says __forceinline (without the '_').

[kilograham]

it is merged into develop current; and __force_inline is a #define in platform.h

[lurch]

@lurch - i think i've seen a bunch of issues with VS Code debug; i thought this had been fixed in the docs, but I believe there is a missing "monitor reset init" before the gdb program load?

Yes, you've assigned raspberrypi/pico-feedback#153 to me, but I'm afraid that's not bubbled up to the top of my priority-list yet.

[smithps]

@lurch - i think i've seen a bunch of issues with VS Code debug; i thought this had been fixed in the docs, but I believe there is a missing "monitor reset init" before the gdb program load?

For info - I'm using Visual Studio, not VSCode - I haven't come across this particular issue.