Forum Replies Created
-
Posts
-
And wouldn’t you know it. I post the message and go cut the grass. When I come back I immediately think of something new to try, which is to specify the complete path and filename as an “Additional linker input”. Now it works.
I can make progress now, but I’d still be interested in knowing why my original attempt failed?
And I can now confirm that the toolchain works for blinking an LED too, my usual next step after “Hello, World!”. FYI: note that the dev board mentioned above doesn’t seem to have a user programmable LED so I had to add one to a pin on connector J14. The Yocto build will determine which GPIOs are available at user level.
Hi, thanks for providing the customized toolchain, which I have confirmed works – at least to the extent of building an running a “Hello, World!” app from Visual Studio. I will be experimenting more over the coming days.
To clarify for future readers, you follow the Variscite instructions to create a Yocto build environment inside a Linux VM (they recommend Ubuntu, I used Debian because I prefer it, and it worked fine). You can then follow the instructions of Sysprogs “support” member above to create the toolchain.
Hi, thanks for the reply. I saw that you offered the toolchain building service, but ISTM that Variscite should be the ones paying for that service, it strikes me as inefficient for each small developer to duplicate that effort. But perhaps you could tell me if that service is expensive? I.e. is it pitched at small companies or at megacorps!
Thanks for the suggestions. I’ll wait until support for this newish CPU is more widespread. I just wanted to check that I wasn’t missing something.
Btw the Nucleo dev boards have a built in STLink USB debug interface, so using Segger j-link would be less convenient.
Thanks for the prompt response.
Strange, I could have sworn that I updated it just the other day, but it was actually in early March – and in any case I should have remembered that I was using a test build!
So I’m sorry about that, and I confirm that the problem does in fact go away when I install 5.6.1.4124.
I’m embarrassed to admit that I didn’t have much success with the beta. I went to File|New|Solution but couldn’t see a RPI Pico template, nor board, nor RP2040 processor. I must be missing a step.
Wow. I didn’t expect such a fast response on a Sunday! (*) Thanks for the info.
(*) Especially when I see I’d accidentally let my support period elapse. Fixed now.
Me too. I’d love to be able to use VisualGDB to develop for the RPi Pico. I’ve subscribed to this topic to keep myself informed.
It’s more the PIO feature that interests me, since otherwise I think the Teensy 4.x has a better spec – and I can already code for (but not debug) that using VisualGDB.
Hi. Thanks for the reply.
Optimization is indeed set to -O0 for debug builds, which this is.
None of the branches is empty – not sure what you mean there.
AFAICS this problem has nothing to do with the emitted code – the same code runs fine outside the debugger – the problem seems to be the debugger and how it handles breakpoints, though I’m open to being persuaded otherwise.
Thank you, that seems to have worked perfectly. As a bonus the “in editor” Debug|Compile feature now works for assembler modules too, which I didn’t realize could be hoped for.
The only minor mystery was why the code built and linked with no problem, other than being suspiciously small! 🙂 In hindsight I’m going to guess that since my startup code (with reset address) was in an assembly module, which was ignored and possibly replaced by some kind of default, that the rest of my program was unreferenced and removed by the linker.
Thanks again.
