Klipper wont connect to board after configuring UART

[Maxim]

I used the sd card method and i checked after flashing that the file is renamed to FIRMWARE.CUR

[mykepredko]

Okay, I wanted to try your process on the Mainsail rPi OS version on an rPi4

@Maxim

and i did all of these:

• Remove console=serial0,115200 in /boot/cmdline.txt
• Add dtoverlay=pi3-miniuart-bt at the end of file /boot/config.txt
• Modify the configuration of [mcu] in printer.cfg to serial: /dev/ttyAMA0 and enable restart_method: command by SSH
• added enable_uart=1 in /boot/config.txt

Now, when I do `sudo nano cmdline.txt’, I get:

No console=serial0,115200 at the start (or anywhere).

There is ttyAMA0, on boot up, however:

Is this what you’re seeing?

[Maxim]

Yes this is exactly what i get

[mykepredko]

If that’s the case, why did you put down that you did the process:

• Remove console=serial0,115200 in /boot/cmdline.txt
• Add dtoverlay=pi3-miniuart-bt at the end of file /boot/config.txt
• Modify the configuration of [mcu] in printer.cfg to serial: /dev/ttyAMA0 and enable restart_method: command by SSH
• added enable_uart=1 in /boot/config.txt

to get /dev/ttyAMA0?

[mykepredko]

Can you put a jumper between Pins 8 & 10 (UART0-TX and UART0-RX) of your Raspberry Pi and see if you can communicate between them with minicom?

To install:

sudo apt install minicom

To run (in this instance):

minicom -D /dev/ttyAMA0

That should show if the rPi’s serial port is working.

[Maxim]

After i run minicom -D /dev/ttyAMA0
it shows

Welcome to minicom 2.8

OPTIONS: I18n
Port /dev/ttyAMA0, 08:03:04

Press CTRL-A Z for help on special keys

but i cant type anything in minicom

[mykepredko]

Okay, let’s review:

1. You’re running the Mainsail OS on your Raspberry Pi 4B. Now, When I do this, I am running without doing any of the changes you outlined above.

2. I have my Raspberry Pi Pins 8 & 10 jumpered like this:

3. I’m running minicom using the statement minicom -D /dev/ttyAMA0 and when I enter text into the communications program, I see it echoed back like:

Are we talking about the same situation - is there anything different?

If you are set up the same way I am, then the serial port on your Raspberry Pi isn’t working.

[Maxim]

When im in minicom and i press STRG + A then Z and then E i get the same echo back like you have.

[mykepredko]

What is “STRG”?

[Maxim]

STRG is CTRL

[mykepredko]

Okay, let me find an Octopus Pro (I know I have at least one around), program it as you have and then wire it the way you have.

It will take a while - but I should have it done by the end of today.

[BevanWeiss]

When im in minicom and i press STRG + A then Z and then E i get the same echo back like you have.

That’s enabling ‘echo’ mode in minicom. NOT echoing back the OUTPUT signal.
With the echo you have turned on, you could literally be sending the data to /dev/null and it would ‘echo’ it back to you…
Which is NOT the test that @mykepredko wanted you to do.
He wanted you to test the electrical pathway through to the transmit pin on the board, and the return path from the receive pin back. It’s why he sent you the photo showing the loop back connection on the board.

[Maxim]

So it’s something with my rPi?

[mykepredko]

Can you show how you’re testing the rPi?

As @BevanWeiss asked, do you have a jumper like I have on my rPi?

[mykepredko]

Okay, Here’s what I did to test the serial connection.

1. I started with an Octopus Pro V1.01 - sorry, I don’t have an Octopus Pro V1.1 but based on your rPi problems, it shouldn’t matter.

2. I am using a Raspberry Pi 4B that was loaded with the Mainsail OS from the Raspberry Pi Imager. Before going forward, I did all the updates for Klipper/Moonraker/Mainsail/etc. from the Mainsail Web Page. I did NOT access or modify any files from SSH.

3. I checked to see if /dev/ttyAMA0 still exists (it does) and checked the serial loop back connection with minicom - things are still working.
   

   

4. I formatted a 4GB Micro SD Card using “SD Card Formatter” as specified by BTT in the user manual.

5. I created a Klipper image for USART2 on the Octopus Pro V1.01 using the MCU that’s on the board. I checked the settings against the user manual and the schematics:
   

   

6. I build the firmware and, using Notepad++, loaded klipper.bin onto my PC, renamed it to firmware.bin. Before programming, there was a flashing LED on the Octopus Pro and afterward it was constantly on. As well, the file on the SD Card changed to Firware.CUR as expected.

7. Using the pinout information in the user manual, I made up a 1x5 terminal block for connecting the five left pins of J26, the USART2 header:
   

8. On the other end of the cable, I put the three bottom ones (TX2, RX2, & GND) into a 1x3 connector and the two power lines to a separate 1x2 connector. I’ll discuss why below.
   

   

9. Next, I connected the two devices together - the bottom right three pins of the Octopus Pro J26 (USART2) connector, as discussed above to pins 6 (GND), 8 (USART0-TX) and 10 (USART0-RX) of the rPi. Note that the five pins connected to “5V” on the Octopus Pro are not connected. The rPi is connected to a Raspberry Pi Power Supply.
   

   

10. Moment of truth. To test the connection, I took my basic test printer.cfg (which tests the connection as well as display the MCU temperatures and allows me to access the LED built into the Octopus Pro), set the serial connection for /dev/ttyAMA0:

[include mainsail.cfg]

[virtual_sdcard]
path: /home/biqu/printer_data/gcodes
on_error_gcode: CANCEL_PRINT

[mcu]
serial: /dev/ttyAMA0
[temperature_sensor mcu_temp]
sensor_type: temperature_mcu

[temperature_sensor rpi]
sensor_type: temperature_host
min_temp: 10
max_temp: 100

[printer]
kinematics: none
max_velocity: 300
max_accel: 3000

[led work_led]
red_pin: PA13
#green_pin:
#blue_pin:
#white_pin:
#   The pin controlling the given LED color. At least one of the above
#   parameters must be provided.
cycle_time: 0.010
#   The amount of time (in seconds) per PWM cycle. It is recommended
#   this be 10 milliseconds or greater when using software based PWM.
#   The default is 0.010 seconds.
hardware_pwm: False
#   Enable this to use hardware PWM instead of software PWM. When
#   using hardware PWM the actual cycle time is constrained by the
#   implementation and may be significantly different than the
#   requested cycle_time. The default is False.
initial_RED: 0.05
#initial_GREEN: 0.00
#initial_BLUE: 0.0
#initial_WHITE: 0.0
#   Sets the initial LED color. Each value should be between 0.0 and
#   1.0. The default for each color is 0.

and clicked on SAVE & RESTART:

---

As one last point, I recommend that you power your rPi from your Octopus board. This is nicely set up by BTT at the USART2 connector (and its 5V Buck power supply can handle the current) - by connecting the 1x2 connector that was left over:

This is a much simpler and more elegant way to wire your Raspberry Pi to your Octopus Pro.

---

@Maxim,

I’m going to suggest that you follow the steps I’ve outlined above; start with a freshly programmed SD Card for your Raspberry Pi and proceed from there. I’m recommending that you start from the beginning as there is some confusion on how you’ve set up your Raspberry Pi - If you follow my steps above and there are any problems, we should be able to figure them out. If you deviate from the steps outlined above, document them for reporting back.

I would suggest that you create a new loopback cable and a new five conductor Octopus Pro to rPi cable as I’ve shown above. It’s always a good idea to colour code your wires to make them easier to keep track of.

Note that I’m working with an Octopus Pro V1.01 and not a V1.1 like you are. There should be no difference other than how you configure Klipper for it.

Based on what you’ve said, if there is a problem with the Raspberry Pi’s USART2 port, then it will show up in step 3.

Regardless, if at any point you get a different result from me then stop. Get a copy of the SSH terminal window, take a picture of your set up with the requirement that you provide as MUCH information as possible.

Let’s see how things work out for you.

[Maxim]

At step 3 i still get no echo back.

[mykepredko]

You started from scratch and you made up a loopback cable like mine?

Then I guess your rPi UART0 is bad.

Your options are:

1. Get another rPi
2. Enable UART5 (Pins 32/33)
3. Connect with USB

[Maxim]

I will just upgrade to a rPi 5 thanks for helping out

[BevanWeiss]

It is still possible that the serial port does work. But that you just have it configured ‘wrong’. I’m not the PI expert though, so I can’t say how to configure it correctly for serial port mode.
If you have an overlay active that is re-configuring those pins as GPIO (instead of USART)… that would do it… or if you’ve done other configuration which is resulting in the port already being allocated to something else… I had issues with brltty taking the klipper usb serial port under a recent Ubuntu install.

Lots of possible issues unfortunately, of which one is an electrical failure of the PI processor itself. If you’ve done weird things like hook these pins directly up to +5V / GND signals… failure is more likely, but only you’d know about that…

A methodical and systematic process of diagnosing is best though.
Try to confirm at the highest level first (i.e. that you can open the expected port), then that the expected output changes when you send something to that port… then when you loop it back that you can receive back what you have sent out… and then you can connect it to the other end…