Pico Debug SDK: What are the differences between official SDK and Pico Debug SDK?
Closed this issue · 9 comments
Hello majbthrd,
I like your work very much and used it for effective debugging of my projects :)
I'm always looking for ways to simplify things, and working from within an IDE, it would be good to use only one SDK. When I compile my projects with the official SDK, I can not debug them with GDB: It loads, and when I step into a program, it terminated.
Can you explain what changes you made to the official SDK?
Believe me when I say that I have no desire to provide a different pico-sdk.
The difference is just a simple bug fix. I offered the changes to raspberrypi back on 10 Feb 2021, but they have demurred on incorporating the change:
move PLL reset code from clocks driver to pll driver
raspberrypi/pico-sdk#110
The executive summary of the change is:
- They've incorrectly put the PLL reset code in clocks.c, not the PLL driver
This has two negative consequences: it is inconsistent with the conventions of all the other drivers (which put the reset in the driver init code), and it means that anyone that calls the pll_init code will not get the needed reset for the PLL initialization to work.
- They needlessly tear down and then re-initialize the PLL (PLL_USB) even if it is already working in the desired configuration
pico-sdk sets PLL_USB to 48 MHz. That's the only frequency that the datasheet allows (because both the USB and ADC peripherals need 48MHz).
The problem is that because of (1) and (2), pico-sdk needlessly switches PLL_USB off and on again. Since pico-debug is actively running on the second CPU off PLL_USB and it is talking to the PC using the USB peripheral which is running on PLL_USB, pico-sdk is crashing the second CPU.
- They needlessly reset the SYSCFG peripheral in clocks.c
The SYSCFG peripheral has the DBGFORCE registers, and this is the hardware feature that makes it possible for the second CPU to debug the first CPU without having to jumper wires on the board.
The only reason I have a different pico-sdk is because raspberrypi won't entertain the notion of fixing/improving their code.
If you like pico-debug, please consider giving it a star on github. It shows that people like the project and use it, and perhaps that will encourage raspberrypi to change pico-sdk so that a different version isn't needed.
In addition to starring pico-debug, supporters could also comment on raspberrypi/pico-sdk#110 requesting that it be merged. (It needs to be rebased again, though, as there is a conflict.)
Thanks @flit! I just did a rebase on the pico-sdk PR; the conflict appeared because raspberrypi changed the pll_init declaration from using the standard uint32_t type to their "uint" type.
Thanks!
from using the standard uint32_t type to their "uint" type.
😢 (Another case of them deciding they needed to reinvent the wheel.)
@majbthrd to get your PR through, it may be helpful to mark the requested changes as "done" or something. I see you've addressed the remarks, but it looks like it's not marked as such. Because of this, in the list of open PRs it's marked as "changes requested". Perhaps that causes the people in power to just skip that merge request - from their point of view, you still need to address those changes.
Thx for the explanation, I hope that the SDK MR gets accepted soon.
Has this been fixed now? It seems the merge was done. Does this mean we can use the official SDK?
Has this been fixed now? It seems the merge was done. Does this mean we can use the official SDK?
Alas, no. They merged it into their "develop" branch, rather than their "master" branch.
We're still at their mercy until the changes in the develop branch are then merged into the "master" branch, such as when they did a "1.1.2" tag release on the 7th of April.
Hooray! As of SDK v1.2.0, the official Rasbperry Pi pico-sdk has the bug fixes to allow pico-debug.
The pico-debug variant of pico-sdk is no longer needed and I will be deleting it shortly... thank goodness.
Please download the newer pico-sdk and make sure that your PICO_SDK_PATH environmental variable points to this new download.