RP2040 PIO/SPI MORE THAN 32 BITS

Yes, you can write a PIO routine to output n-bit SPI. Are you using this PIO routine: https://github.com/raspberrypi/picoprobe/blob/master/src/probe.pio 

It gets complicated having to reload the OSR every 32-bits.  You could use the autopull feature, but then it gets complicated syncronizing on the first FIFO write which sets the bit count.

If you only need n-bit SPI to clock 0's, you could just write another pio routine clock out N zeros.

Thanks for your answer, Yes I am having some issues reloading the OSR and sincronizing it.

that is the PIO file I am using, I am trying to emulate the SWD init sequence, I think that the main problem I don't get any response from the other rp2040 is because of the delay on data every 32btis, I don't know if that makes sense to any of you ?

Thanks again.

Hi,

Regarding: "I think that the main problem I don't get any response from the other rp2040"

I'm confused - the PicoProbe code is already designed to work with RP2040, and has been used in that way by hundreds/thousands of people surely? Does it not already use the SWD sequence you are attempting, or am I misunderstanding it?

Yes, but I am trying to move a data that is already stored on another flash address from rp2040_1 to the SWD pins from rp2040_2, I don't use the USB to download the data to rp2040_2 and letting it do all the syncronization that way (on my board I don't have access to those pins, is not a raspberry pi pico board is my own board).

So, I am having problems trying to get the SWD init, I think that even with the delay between spi frames it should work as PICOPROBE seems to make it work that way already.

That is how it has to work for the hardware I already have on the boards, does it make any sense to you?

I had checked so much info about the sequence to init SWD that I don't that I am sending wrong bits.

Hi,

The PicoProbe USB code portion is likely decoupled from the SWD code (I've not checked, but it should be), so if you're not using USB in your version of code, it should make no difference.

As you yourself say, since PicoProbe already functions on the SWD interface side, then it should work with your version of code. The delay may be a red herring, you can prove it to yourself by examining with a 'scope if possible (or a logic analyzer), and comparing the normal PicoProbe with your version, to see where the discrepancy is, if source code examination isn't helping so far.

It makes no sense that it would not work in your code if the normal PicoProbe works (have you tested the normal PicoProbe code with a normal Pi Pico with your RP2040 target, just to be 1000% sure that you don't have an issue elsewhere in the system?).

Hi,

The PicoProbe USB code portion is likely decoupled from the SWD code (I've not checked, but it should be), so if you're not using USB in your version of code, it should make no difference.

As you yourself say, since PicoProbe already functions on the SWD interface side, then it should work with your version of code. The delay may be a red herring, you can prove it to yourself by examining with a 'scope if possible (or a logic analyzer), and comparing the normal PicoProbe with your version, to see where the discrepancy is, if source code examination isn't helping so far.

It makes no sense that it would not work in your code if the normal PicoProbe works (have you tested the normal PicoProbe code with a normal Pi Pico with your RP2040 target, just to be 1000% sure that you don't have an issue elsewhere in the system?).