MCU unable to connect after mainboard flash

[potokslow]

Basic Information:

Printer Model: Flsun V400
MCU / Printerboard: MKS Nano V2.1 Clone GD32F303
Host / SBC: Flsun Speeder Pad
moonraker.log (22.2 KB)
klippy.log (42.9 KB)

Hello,

I recently got the Flsun V400 as faulty, and managed to bring it up after PSU replacement.

Earlier today I reconfigured the Speerder Pad to use official Klipper following the instructions from Guilouz and I was able to connect to the printer, it was reporting Klipper firmware v0.10.x.
I decided to update the mainboard firmware, which initially failed, probably since I was using 64 GB card.
Flash went seemingly OK once I switched to 4 GB card (I’m saying “seemingly” since the file name on the card was changed from Robin_nano35.bin to ROBIN_NANO35.CUR like it was supposed to), unfortunately Klipper is now unable to connect to the MCU.

I am using the same serial port as before the update and it matches what’s found in /dev/serial/by-id/
printer.cfg :

[mcu]
serial: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0
restart_method: command

/dev :

pi@speeder-pad:~$ ls -lah /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 60 Mar 26 20:26 .
drwxr-xr-x 4 root root 80 Mar 26 20:26 ..
lrwxrwxrwx 1 root root 13 Mar 26 20:26 usb-1a86_USB_Serial-if00-port0 → ../../ttyUSB0

I tried to build the firmware again paying close attention to the settings, even tried using the one published by Flsun, hoping I could at least get the old version running, but no such luck.
Each flashing seems to go through fine, the file name on the card changes, but the connection is still failing.
I’m starting to think that the board got somehow damaged during the flashing, the flash chip failed, or something similar.

Any suggestions on how to troubleshoot this further would be appreciated.

Thank you

Edit:
I have posted the same issue on the Klipper-Flsun-Speeder-Pad discussion board - MCU unable to connect after seemingly successful mainboard flash · Guilouz/Klipper-Flsun-Speeder-Pad · Discussion #209 · GitHub

[Sineos]

Try with Serial (on USART1 PA10/PA9)
Alternative also try the setting Disable SWD at startup (for GigaDevice stm32f103 clones) although it should not be needed for a GD32F303

[potokslow]

Thank you for the suggestion, unfortunately this didn’t work for me.
I tried flashing firmware using all USB and USART ports, with and without the Disable SWD at startup (for GigaDevice stm32f103 clones) selected, plus a few more variations.
After each flash, the name of the file on the card was correctly changed to .CUR, so it should have been correctly read and applied by the board, but Klipper was still unable to connect.
I did fully power off the printer and powered it back on after waiting a bit, just to be sure.
I also checked if the /dev/serial/by-id/ changed.

My printer board uses GD32F303 by GigaDevice, and I found some discussions regarding Ender 3 boards with the same MCU, where disabling SWD was necessary, so I tried all ports with this setting, but without any luck.

Here’s an example of the firmware creation process, just in case I’m missing something or doing something dumb…:

pi@speeder-pad:~$ cd ~/klipper
pi@speeder-pad:~/klipper$ make menuconfig

Loaded configuration '/home/pi/klipper/.config'
No changes to save (for '/home/pi/klipper/.config')
pi@speeder-pad:~/klipper$ make clean
pi@speeder-pad:~/klipper$ make
  Creating symbolic link out/board
  Building out/autoconf.h
  Compiling out/src/sched.o
  Compiling out/src/command.o
  Compiling out/src/basecmd.o
  Compiling out/src/debugcmds.o
  Compiling out/src/initial_pins.o
  Compiling out/src/gpiocmds.o
  Compiling out/src/stepper.o
  Compiling out/src/endstop.o
  Compiling out/src/trsync.o
  Compiling out/src/adccmds.o
  Compiling out/src/spicmds.o
  Compiling out/src/i2ccmds.o
  Compiling out/src/pwmcmds.o
  Compiling out/src/buttons.o
  Compiling out/src/tmcuart.o
  Compiling out/src/neopixel.o
  Compiling out/src/pulse_counter.o
  Compiling out/src/lcd_st7920.o
  Compiling out/src/lcd_hd44780.o
  Compiling out/src/spi_software.o
  Compiling out/src/i2c_software.o
  Compiling out/src/thermocouple.o
  Compiling out/src/sensor_adxl345.o
  Compiling out/src/sensor_lis2dw.o
  Compiling out/src/sensor_mpu9250.o
  Compiling out/src/sensor_icm20948.o
  Compiling out/src/sensor_hx71x.o
  Compiling out/src/sensor_ads1220.o
  Compiling out/src/sensor_ldc1612.o
  Compiling out/src/sensor_angle.o
  Compiling out/src/sensor_bulk.o
  Compiling out/src/stm32/watchdog.o
  Compiling out/src/stm32/gpio.o
  Compiling out/src/stm32/clockline.o
  Compiling out/src/stm32/dfu_reboot.o
  Compiling out/src/generic/crc16_ccitt.o
  Compiling out/src/generic/armcm_boot.o
  Compiling out/src/generic/armcm_irq.o
  Compiling out/src/generic/armcm_reset.o
  Compiling out/src/../lib/stm32f1/system_stm32f1xx.o
  Compiling out/src/stm32/adc.o
  Compiling out/src/stm32/stm32f1.o
  Compiling out/src/generic/armcm_timer.o
  Compiling out/src/stm32/i2c.o
  Compiling out/src/stm32/spi.o
  Compiling out/src/stm32/serial.o
  Compiling out/src/generic/serial_irq.o
  Compiling out/src/stm32/hard_pwm.o
  Building out/compile_time_request.o
Version: v0.12.0-467-g68dbbc8d4
  Preprocessing out/src/generic/armcm_link.ld
  Linking out/klipper.elf
  Creating hex file out/klipper.bin
pi@speeder-pad:~/klipper$ ./scripts/update_mks_robin.py out/klipper.bin out/Robin_nano35.bin

Once this is done, I copy the Robin_nano35.bin to microSD card, insert the card into the printer board, press reset button on the board, do restart / firmware restart on the Klipper host while staring at the LEDs, turn the printer off and back on.

I made one more observation - there are LEDs besides the USB/serial port, one I’m guessing is RX, the other should be TX.
Whenever I restart Klipper on Speeder Pad, I can see one of the LEDs blinking.
The other one never lights up.
If I remember correctly, both LEDs were blinking initially, before I attempted to flash the printer board.
Now, no matter which port I try to specify during firmware creation, the second LED never seems to light up.

I don’t have another printer board with LEDs by the serial port, but I’d assume that the board would try to transmit something on startup to announce itself, and maybe periodically.
Or does it only transmit when being queried?

Just in case, I have tried with different Klipper host device, but only with printer firmware set to use USART3 PB11/P10. This also didn’t work.

My current theory is that either the serial port failed since it never seems to be transmitting anything, or that maybe I have some unique board with different definitions of the serial ports.

Any other suggestions?

[Sineos]

@potokslow

Here’s an example of the firmware creation process, just in case I’m missing something or doing something dumb…:

I cannot really comment on this board in particular and if there is any difference between an “original” v2.1 board and one with the GD clone chip. For the original board your settings seem correct.

[potokslow]

That’s a fair statement, I understand.

Are you familiar with how printer boards flashed with Klipper behave from the serial port perspective?
Would the printer board try to send any data by itself, either during startup or periodically, or do they only respond to queries from outside and respond only when queried?

I’m trying to figure out if the lack of activity on the second USB/serial port LED can be understood as the board never attempting to send anything.

I was thinking about two other approaches:

• Plug in directly to USART1 PA10/PA9 (while using updated firmware), which seem to be exposed via the WiFi header, but I’d need to find a USB-serial adapter;
• Get a ST-LINK and try to flash the board via the debug port;

Debugging anything via ST-LINK is beyond me, but I think I should be able to install firmware that way, just to rule out the microSD.

[potokslow]

I decided to hook up a logic analyzer to the USART pins and check the behavior when starting or resetting the board - I didn’t see any traffic.
I tried with USART1 PA10/PA9 and USART3 PD9/PD8 with matching firmware flashed each time - no traffic on the RX/TX pins whatsoever.

For comparison, I pulled out a BTT SKR Pico configured to use serial port - the board was sending serial communication on start and periodically, even if not connected to any host.

It seems to me that something is seriously wrong with my NANO V2.1 clone, or I’m flashing it wrongly.
Even the original firmware from Flsun didn’t work, so I’m quite lost right now.

My last idea is to get a ST-LINK device and try to reflash the board via debug port, but I’m not sure what are the chances of this working any better…

[koconnor]

Klipper does send out serial traffic periodically - a statistics message every 5 seconds. However, it’s a short message and I’m not sure you’d see it by watching LEDs.

If you are successfully flashing the code to the micro-controller, but not getting any traffic at all on the serial port, it generally indicates an incorrect setting in “make menuconfig”. Unfortunately, I don’t know what your settings should be set to.

If possible, see if you can find the schematics for your printerboard. Then look to get a high resolution picture of the chip on your actual board (or at least be sure you can read out the chip identification information on your actual board). Make sure the chip matches your schematic. This can help verify your “Processor model” in make menuconfig.

You could also try tracing the UART Rx/Tx pins from the mcu to the usb-to-serial chip on the board. It is possible to use a multimeter in “connectivity check mode” to verify connectivity between mcu pin and usb chip pins. This is tedius (and be sure to do it with the power off), but it may help verify the “communication interface” settings.

If the bootloader is functional enough to rename the file to “ROBIN_NANO35.CUR”, and if your host computer is recognizing the usb-to-serial adapter chip on the device, then it does seem surprising that you can’t get any UART messages.

-Kevin

[potokslow]

Thank you for the comments and suggestions.

I got the settings to use with make menuconfig from an article about flashing supposedly identical board.
I also tried the official firmware published by Flsun on their GitHub, with the same results.
I have physically confirmed the markings on the printer MCU, so it seems to at least be the correct processor.

As for the board schematics, the only ones I could find were the ones for the original MKS Robin Nano v2.x.
I’m not sure how different is the Flsun clone besides the EXP ports being used differently.
I’ll try tracing the pins tomorrow, I should at least be able to check if the pins USART 1 and 3 lead to the expected locations.

[potokslow]

I did some tracing with a multimeter, but what I found out seems really weird…

The V400 board, NANO V2.1 clone, has a GD32F303 VET6 chip, 100 pin package.
It also has CH340C USB-to-serial chip.

EDIT: The tracing results below are wrong as I had a wrong location of the PIN 1. The MCU in this case is rotated 90 degrees counter-clockwise, so the connecting pin numbers should be lowered by 25 (i.e. PIN 73 is actually PIN 48).

#1
I traced the CH340C pins / USART3 PB11/P10 and found out that:

• PIN 2, TX, connects though a resistor to PIN 73 of the MCU;
• PIN 3, RX, connects though a resistor to PIN 72 of the MCU;

According to the GD32F303 datasheet:

• PIN 73 should be NC;
• PIN 72 should be PA 13 / JTMS, SWDIO;

According the the MKS Robin Nano V2.0 schematics:

• CH340C PIN 2 (TX) should be connected to MCU PIN 48 (RXD0 / PB11);
• CH340C PIN 3 (RX) should be connected to MCU PIN 47 (TXD0 / PB10);
• MCU PIN 73 should be NC;
• MCU PIN 72 should be SW_DIO / PA13;

Unfortunately, I couldn’t find schematics for NANO V2.1 anywhere.

#2
The other thing I tried tracing was the USART1 PA10/PA9, used for optional WIFI module:

• PIN labeled RX1 / RX-PA10 connects to MCU PIN 94;
• PIN labeled TX1 / TX-PA9 connects to MCU PIN 93;

According to the GD32F303 datasheet:

• MCU PIN 94 should be BOOT0;
• MCU PIN 93 should be PB7 / Alternate: I2C0_SDA, TIMER3_CH1, EXMC_NADV / Remap: USART0_RX, SPI0_IO3;

According to the Nano V2.0 schematics:

• RX1 / RX-PA10 should be connected to MCU PIN 68 (RXD1 / PA10);
• TX1 / TX-PA9 should be connected to MCU PIN 69 (TXD1 / PA9);
• MCU PIN 94 should be BOOT0;
• MCU PIN 93 should be I2C_SDA / PB7;

#3
To cross-check the pinout from the GD32F303 datasheet, I checked the power pins on the MCU:

• MCU PIN 50 (VDD_1) connects to 3.3V, not shorted with MCU PIN 75 or 100;
• MCU PIN 75 (VDD_2) connects to 3.3V, seems to be shorted with MCU PIN 100;
• MCU PIN 100 (VDD_3) connects to 3.3V, seems to be shorted with MCU PIN 75;
• MCU PIN 49 (VSS_1) does not connect to GND
• MCU PIN 74 (VSS_2) connects to GND;
• MCU PIN 99 (VSS_3) connects to GND;
  The above pin numbers match the Nano V2.0 schematics, but according to them, all VDD pins should be shorted, and all VSS pins should be shorted.

My conclusion is that this MCU is not GD32F303 and the board does not quite follow the schematics for MKS Robin Nano V2.0.

Here’s a photo of the board, in case anyone would be familiar with this:

Any suggestion on how to figure out what we’re actually dealing with?

[potokslow]

@Sineos

“original” v2.1 board

I’ve been looking around for the V2.1 schematics while tracing the connections between MCU and serial ports, but I could only find V2.0, which don’t quite match my board.

Do you maybe have access to schematics for V2.1 or could point me in the right direction?

[cgbab]

I just noticed in the menuconfig

There is a line "Disable SWD at startup ( for clones) which the 2.1 supposedly is.

I don’t know how much that matters, but if you did not check that, it might be worth a shot.

Sorry, I just noticed somebody already suggested that.

Have you tried connecting the USB to your computer to see if it works from there, just to eliminate a speederpad issue ?

[potokslow]

Thank you for the suggestions, but I already tried those - unfortunately no luck…

I tried different serial and USB combinations with and without the Disable SWD option, and also tried connecting the NANO V2.1 board to a known-good Klipper host.

[Sineos]

@potokslow

Do you maybe have access to schematics for V2.1 or could point me in the right direction?

Unfortunately not. I also took a look at the Marlin configurations, but here as well, only the STM chips are mentioned and not the GD variant (if there is a difference). Quite odd.

[koconnor]

@potokslow

MCU PIN 49 (VSS_1) does not connect to GND

Did you perhaps not align the “dot” with the spec? In the spec, the “dot” is on the upper left, while in your picture, the “dot” seems to be in the lower left. The pins should be relative to the “dot” and are not relative to the writing on the chip.

If you were rotated then what you described as “pin 73/72” would be 48/47 which would be PB11/PB10 and “pin 94/95” would be 69/68 which is PA10/PA9.

Another thing you can try is to set the “clock reference” to “internal clock” for testing (it can help confirm if you have the right crystal defined).

Remind me, have you tried connecting to PA10/PA9 with a 3.3v TTL uart type of device?

-Kevin

[potokslow]

@koconnor

Did you perhaps not align the “dot” with the spec? In the spec, the “dot” is on the upper left, while in your picture, the “dot” seems to be in the lower left. The pins should be relative to the “dot” and are not relative to the writing on the chip.

Yes, I’m an idiot, that’s exactly what I was missing…
I saw four “dots” / “dimples” on the chip, while there was supposed to be one, so I assumed that the pin numbers of the chip would match the alignment in the data sheet if I followed the direction of writing on the chip.
As it turns out, one of the “dots” is deeper and that one actually marks the pin 1.
I really need to get myself some glasses
Now that the chip orientation is clear, I’ll need to probe the pins again to confirm the connections against the V2.0 schematics…

@koconnor

Another thing you can try is to set the “clock reference” to “internal clock” for testing

The clock chip on the board is marked as “8.000”, so I’m guessing it’s 8 MHz, but I’ll try with internal reference, thanks for the suggestion.

@koconnor

have you tried connecting to PA10/PA9 with a 3.3v TTL uart

I have tried PA9/PA10 with a logic analyzer, but didn’t see anything coming out from the MCU.
I’m not completely sure if my capture triggers were configured correctly, I may have simply missed the traffic.

I need more structured approach and redo the tests while taking better notes or this won’t get anywhere.
I tried so many things that I’m getting lost…

[potokslow]

I retraced the connections for USART1 PA10/PA9 and USART3 PB11/PB10, their connections to the MCU match the schematics for MKS Robin Nano V2.0, so at least this portion is confirmed.

I took out an old oscilloscope to check the data coming out from MCU - there was nothing on USART1 or USART3.

I tested the following flash parameter combinations:

Communication interface	Disable SWD	Clock	Optimize stepper code
USART1 PA10/PA9	NO	8 MHz	YES
USART1 PA10/PA9	YES	8 MHz	YES
USART1 PA10/PA9	YES	Internal	YES
USART1 PA10/PA9	NO	Internal	YES
USART1 PA10/PA9	NO	8 MHz	NO
USART1 PA10/PA9	YES	8 MHz	NO
USART1 PA10/PA9	YES	Internal	NO
USART1 PA10/PA9	NO	8 MHz	NO
USART3 PB11/PB10	YES	8 MHz	NO
USART3 PB11/PB10	YES	Internal	NO
USART3 PB11/PB10	NO	Internal	NO
USART3 PB11/PB10	NO	8 MHz	NO

For USART1, I was checking PA10/PA9 on the oscilloscope - nothing.
For USART3, I checked on the CH340 chip as well as on the resistors between this chip and MCU - I can see USB data coming in, being then converted to serial and sent to the MCU, but nothing is coming out of the MCU towards CH340.

It looks like the MCU bootloader is working OK, since it accepts the firmware on the microSD card and renames the file.
The next part is confusing, it’s like either the code is not written correctly, or it’s not starter.

I’m not sure what I could try next…

[Sineos]

Usually, the only thing that is important is to get the make menuconfig settings correct. If they are OK, the usual suspects are:

• The SD card used for flashing.
• The USB cable for connection. I’ve seen users who needed to try five different cables until one worked. No idea what kind of cables folks have lying around.

You can also try installing the Katapult bootloader. This will allow flashing via the command line, which offers more control and feedback on whether the process succeeded.

Finally, the board might simply be defective.

[potokslow]

@Sineos

The SD card used for flashing.

It was indeed the SD card

Since I had no issues with read or write on PC, and the firmware file was correctly renamed by the printer board after the seemingly successful flash, I assumed that the card was good and went around chasing other leads…
Apparently, firmware file name change is not a definitive indicator of a successful flashing…

I took another card, this time 16GB, recreated the firmware file using the standard settings for this board, plugged in the card and turned on the printer.
After a few seconds I was able to see TX LED blinking, the board was alive!
A bit later, once the Speeder Pad finished booting, the RX LED started blinking too.
Klipper connection is working once again.

Thank you very much @Sineos , you’re a lifesaver