but nothing was working … upon investigation, it seems Rev 3 does not tie the D0+D1 UART to the RP2040 via jumpers. Instead UART_Tx and UART_Rx nets from the RP2040 go into the crosspoint switches. If this is the case, is it no longer possible to have a nano board wire the Jumperless itself without custom firmware?
It should be able to do this, but I’ve written a lot of firmware since then and may have broke that feature without noticing.
The jumpers from that other post were just current limiting resistors that were a bit too high of a value to let a 3.3V part talk to a 5V part. If you got your Jumperless anytime in 2024, those will already be replaced with 0 ohm resistors from the factory. So you shouldn’t have to worry about that.
And yes, the UART lines and D0/D1 all go into the crosspoint switches, so when you control the Jumperless over UART, you have to tell it to also make the connections to UART by including
116-70, 117-71,
with the other connections you send.
Let me take a look and see what I did and hopefully get that fixed tonight or tomorrow.
Oh okay, it does actually still work, but the instructions are outdated.
Here’s how you do that now:
Some general info:
First off, I took out the firmware to flash the Nano from a single USB cable, so to flash the Nano, you’ll just need to plug it in with a second cable.
And when the Jumperless has the UART lines hooked up to the RP2040, it won’t be able to flash even from a second cable. The easy way to disconnect everything for flashing is to just send an ‘f’ in the menu.
^ Ignore this, you actually only need to do this the first time. When the Jumperless gets a valid command over UART, it automatically adds these connections for the next time.
Here’s what you do:
This is the test sketch for the Nano
void setup() {
pinMode(LED_BUILTIN, OUTPUT);
delay(3500);
Serial.begin(115200);
delay(1500);
}
int count = 1;
void loop() {
digitalWrite(LED_BUILTIN, HIGH);
delay(250); //if it sends commands too fast, the Jumperless can drop connections
digitalWrite(LED_BUILTIN, LOW);
delay(30);
Serial.write("f 1-");
Serial.print(count);
Serial.write(", "); //these 2 connections reconnect the UART lines so it's ready to send the next connection
count++;
if (count >= 60) {
count = 3;
}
}
Load that onto your Nano, it’s fine if it’s plugged into the Jumperless while you flash it, just send ‘f’ before you hit Upload to clear the UART connections.
So the Arduino should be flashing its LEDs showing that it’s sending stuff, but the Jumperless doesn’t know that it’s trying to send it commands because their UART lines aren’t connected to each other.
You’ll first need to tell the Jumperless the baud rate. So in the Menu, enter
Tried again tonight and I was able to get it working. I moved on to a related setup and found a bit of a hiccup.
I’m using the following node file command to establish the connection to a peripheral:
f 3V3-1,D6-2,D5-3,D4-4,D7-5,GND-6,UART_TX-D0,UART_RX-D1,
I’ve found the ground connection doesn’t go through. If I permute the order of connections, whatever is beyond the 5th one only works about 1 in 10-20 times (resetting the MCU which sends this sequence at init time).
The code in savePreformattedNodeFile looks it has some timing dependencies that make it fragile. What is the serial RX buffer length in this implementation? At 115200 bps, a 10-bit symbol including start/stop bits takes 87 µs, so delaying 800 µs per read means 9 characters are buffered for every one that is read. I’m wondering if this is the cause of the flakiness I’m seeing.
If I wanted to bootstrap the UART connection, do I need to make my own firmware build? I’d like to have it wire the breadboard completely on its own once the power is connected.
That may actually be it, or at least some sort of timing issue like that. Especially because it reads in UART from the second core (on a much tighter loop) and then handles it on the first core, it might just need a “wait until it’s finished reading in data before handling it” kinda thing. Maybe if I put in some end sequence this would be less timing-dependent.
I didn’t spend that much time getting this feature to be rock-solid, so maybe I’ll take another look at it.
Or you can play around with the code and submit a PR. Let me know if you need any help getting that set up.
Also, possibly related but probably not,
This doesn’t look like it’s the cause of the issue, but scoot whatever you’re connecting one row over on the breadboard, row 1 (and the other 3 corners) can have issues with 3V3 and GND with other stuff connected.
f 3V3-2,D6-3,D5-4,D4-5,D7-6,GND-7,UART_TX-D0,UART_RX-D1,
This brings up another question. Suppose I want to do some reverse engineering on a device and I want to do it over a network. I’ve attached (say) 8 pins to a device, and also attached one or two devices like a Tigard, and a device that iD’s pin functions (e.g. JTAGulator). I (1) scan the pins to identify the function, and then I want to (2) connect the device to the proper pins on a Tigard to do a UART/JTAG/I2C/SPI interface. Normally I’d have to disconnect one device and re-wire the second device to a breadboard. Could I do this all remotely with a Jumperless in the middle?
Hey Bruce,
Yeah, you can totally do that. That’s kind of this thing’s bread-and-butter as far as use cases go.
There are a bunch of ways to go about that. Here are the ones that come to mind right now.
The simplest might be something like having the app running on the remote machine, give it a Wokwi project link, and then go to that link on your machine and edit the project. But that’s not really “automated.”
If you know what the possible arrangements are, you can save each setup in its own slot and just cycle between them by sending ‘x’ or ‘z’ to the Jumperless.
Or write a little program for either an Arduino Nano (or maybe even the JTAGulator itself if it has exposed UART) to figure out where the connections need to go and then send that to the Jumperless in a string like above.
If you give me a more details about your setup and what you’re going for, I can probably give you a “best” way to pull that off.
Like would it be physically remote? or just in another room.