Unable to program the board

[tiagooliveira95]

I just bought a brand new MKS Robin Nano V3.0 and I'm unable to program it.

My setup:

• Powering the board via an external source.
• The display is the 12864 v2.1
• USB power is set to off

My first try was to compile marlin, I moved the "Robin_nano_v3.bin" to a USB drive, but nothing happened and the display stays off.

I thought that maybe the board was missing the bootloader, so I copied all 3 files found here and moved them to the USB, waited ~10min nothing seemed to happen.

I retried to flash the "Robin_nano_v3.bin" thinking that now the bootloader was installed, but still, nothing happened.

These are my configurations:

Configuration.h https://drive.google.com/file/d/13tRBnM0FwDHqBN4e1VXrYYrDyE5L39co/view?usp=sharing

Configuration_adv.h https://drive.google.com/file/d/1hKFZP_6OM88yP9NnYohVIcnmq7zs6RAd/view?usp=sharing

[tiomel]

I think that you must use MicroSD instead USB.

[tiagooliveira95]

I tried again using a 32GB sd card (the lowest capacity I have) formatted in fat32 but sadly it didn't work

[tiomel]

Try with smaller one.

[tiomel]

8GB or 4GB

[tiagooliveira95]

@tiomel I was not able to find an 8GB sd card, I bought a 16GB one but it still doesn't work, however, I have seen in other issues where people confirmed that 32GB card works with mks robin. I don't know why it's not working.

I found out the files should be changing to .cur but that doesn't happen

[tiagooliveira95]

Is there any way to debug the board? like a verbose console log via the SWD or uart? With a black screen is really hard to tell if anything is happening

[tiagooliveira95]

@mks-viva any idea on how to fix this?

[mks-viva]

You can try to download mks path Robin_nano_35.bin file and update it, confirm whether it is a 32gb card problem.

[tiagooliveira95]

@mks-viva thanks for the reply!

I'm not sure where to find the Robin _nano_35.bin.

However I have made some progress, I was able to read some sectors from the internal memory via swd and found that the bootloader sector is completely field with 0xFF The firmware section 0x800C000 contains the binary data of marlin, I didn't confirmed if the marlin on the board matches the one that I tried to program but the first bytes match exactly.

I'm not sure what can cause a bootloader to be completely wiped out while maintaining marlin intact

I did try to update the bootloader, but I left the board powered on for 10min because I wanted to make sure not to turn the board off while the bootloader was being written, I think this is enough time to program the bootloader without issues 🤔

Tomorrow I will try to program the bootloader via swd, I don't think I can do it via the SD card or USB without a functioning bootloader present on the cpu

[tiagooliveira95]

I did it!!!!! It was a wild ride, I spent 3 full days on this and finally, I made it work.

I was able to program the bootloader via the SWD port, after a successful flash, programming the marlin firmware was super easy, I just plugged my pen drive into the board, after 15sec the HE1 light came on :smiley:

Everything is working now!

I will explain what I did for anyone who may face the same issue.

I used my Raspberry Pi 4, however, this should also work if you have an ST-Link

1. Install OpenOCD

2. (ONLY FOR PI 4) make sure you have these settings in the raspberrypi2-native.cfg found here /usr/local/share/openocd/scripts/interface

bcm2835gpio_peripheral_base 0xFE000000
bcm2835gpio_speed_coeffs 236181 60

3. Create a folder, inside that folder run nano openocd.cfg and paste:

   
   source [find interface/raspberrypi2-native.cfg] # if you are not using a PI change this to the correct interface
   transport select swd

set CHIPNAME stm32f4 source [find target/stm32f4x.cfg]

reset_config srst_nogate

adapter_nsrst_delay 100 adapter_nsrst_assert_width 100

init targets reset halt

4. Run `sudo openocd`
5. Open a new terminal window and run `telnet localhost 4444`
6. Prepare the flash memory by running `flash erase_sector 0 0 11` in the telnet terminal
7. Now you can write the bootloader with `flash write_bank 0 nano_v3_bootloader.bin 0`

DONE.

Side notes: 
- If you encounter the message `Target not halted` run `reset halt`
- You can choose your pinouts for the DIO and CLK on the raspberry pi by editing the `raspberrypi2-native.cfg` file, don't forget the reset pin, follow the tutorial on the link above for more information

After this you will be able to program marlin via USB or the SD card :+1: 

[just-trey]

@tiagooliveira95 I have followed your instructions on this and am wondering if I am missing something. I compiled openocd from source as suggested and I can telnet to 4444 with no issues or warnings. The problem I am having is when I issue the commands I get output that shows the command line usage for flash erase_sector and flash write_bank and neither of those parameters appear to exist. Looking at openocd documentation they still do seem to be supported. Any suggestions?

[tiagooliveira95]

@just-trey I'm not entirely sure, this may be a stupid question but you are running these commands in the telnet window right?

Can you share some screenshots?

[Kozzilla]

@tiagooliveira95, your solution seems perfect but didn't work for me. I put the bin file some folder and gave its address while uploading. however board is still stuck and do not apply anything from sd card or usb. Is there a way to make a complete reset and install everything through st-link?

[hewasajumperboy]

Hello from the future!

I don't usually revive dead threads but this was finally the silver bullet for me. I recently came into possession of a bricked Robin Nano V3.1 and this procedure worked... with modifications. Things have changed slightly, see below.

Step(s) 0:

• I installed vanilla raspberry pi os lite (since this is just a network connected debugger, I performed all steps over SSH). I configured the install with username: user, ssh public key auth, and wifi network.
• Once booted, login over SSH and update the image sudo apt update && sudo apt upgrade -y
• Install useful utilities, I use screen for multiple consoles, oh-my-zsh, you'll need git and telnet later as well.

Firstly, compile OpenOCD like normal but don't wire your pi to your board according to Adafruit's guide, it's almost 8 years out of date at the time of this writing and it doesn't work anymore (more on what to do later)!

Now we need to setup our environment, I don't like making changes to base configs so I created a folder ~/mks_robin_nano/ where I created openocd.cfg. The latest rev of OpenOCD now has a unified raspberry pi configuration file so changes to openocd.cfg are below:

# TODO: change SWD pins to correct jumpers
source [find interface/raspberrypi-native.cfg] 
# if you are not using a PI change this to the correct interface
transport select swd

set CHIPNAME stm32f4
source [find target/stm32f4x.cfg]

reset_config  srst_nogate

adapter_nsrst_delay 100
adapter_nsrst_assert_width 100

init
targets
reset halt

Then, I needed to modify /usr/local/share/openocd/scripts/interface/raspberrypi-gpio-connector.cfg to enable the srst pin:

# SPDX-License-Identifier: GPL-2.0-or-later

#
# Config for Raspberry Pi GPIO header
#
# This is best used with a fast enough buffer but also
# is suitable for direct connection if the target voltage
# matches RPi's 3.3V and the cable is short enough.
#
# Do not forget the GND connection, e.g. pin 20 of the GPIO header.
#

# GPIO 25 (pin 22) previously used for TMS/SWDIO is pulled-down by default.
# The JTAG/SWD specification requires pull-up at the target board
# for either signal. Connecting the signal pulled-up on the target
# to the pull-down on the adapter is not a good idea.
# GPIO 8 is pulled-up by default.
echo "Warn : TMS/SWDIO moved to GPIO 8 (pin 24). Check the wiring please!"

# Each of the JTAG lines need a gpio number set: tck tms tdi tdo
# Header pin numbers: 23 24 19 21
adapter gpio tck -chip 0 11
adapter gpio tms -chip 0 8
adapter gpio tdi -chip 0 10
adapter gpio tdo -chip 0 9

# Each of the SWD lines need a gpio number set: swclk swdio
# Header pin numbers: 23 24
adapter gpio swclk -chip 0 11
adapter gpio swdio -chip 0 8

# If you define trst or srst, use appropriate reset_config
# Header pin numbers: TRST - 26, SRST - 18

# adapter gpio trst -chip 0 7
# reset_config trst_only

adapter gpio srst -chip 0 24
reset_config srst_only srst_push_pull

# or if you have both connected,
# reset_config trst_and_srst srst_push_pull

Finally, with the Robin Nano powered off wire up your interface according to the NEW pinouts in the GPIO file above. Start with ground! Don't wire 3V3, the PI can't handle the current load (at least, my pi3 couldn't).

Transfer the latest bootloader to the working folder of the pi (I used the no-beep version since someone somewhere else said it had sd AND usb flash drive support): rsync -av nano_v3_bootloader.bin user@raspberrypi.lan:/home/user/mks_robin_nano

Now you're ready to launch OpenOCD on the pi: sudo -E openocd -f openocd.cfg

Open a new terminal (I use screen, ctrl+a, c) and telent into openocd's server (I also had to install telnet from apt): telnet localhost 4444

Depending on your board revision (the stm32 cpu model, specifically), the erase flash stage needs different parameters:

• V3 with 1024K flash:

flash erase_sector 0 0 11

• V3.1 with 512K flash:

flash erase_sector 0 0 7

Now flash the bootloader! As an additional step, I verified it wrote the same number of bytes as the bootloader file in the working dir. flash write_bank 0 nano_v3_bootloader.bin 0

After this, I plugged in a USB drive formatted as fat32 with my custom Marlin firmware build in the root directory, issued a reset and the activity light started going wild on the USB drive! For me, the flash procedure took 15-30 seconds. After the USB drive went idle, I waited ~1 minute before doing another reset. Then to my absolute delight, the usb serial port came to life on my computer. Bus 003 Device 093: ID 0483:5740 STMicroelectronics Virtual COM Port

I verified the firmware in two ways:

1. My version of Marlin routed the USB drive through the USB port to my computer, I mounted the volume and the firmware file now read: ROBIN_NANO_V3.CUR meaning it's the CURrently running version.
2. Connected to the board through pronterface, connected to the board, and issued M115: Firmware Info. Firmware_Name contained the marlin branch I forked and build date. Firmware_Type contained my custom machine name.

A similar procedure should work with an ST-Link debugger... I believe the program is STCubeProgrammer, but I don't have one of those (yet). If you do have one, it should be easier than spinning up a Raspberry Pi debugger.

Looks like my board is back from the dead! I hope this helps some wayward traveler.

[hewasajumperboy]

As an update to my previous comment, I acquired a ST-Link v2, literally the cheapest one on eBay (from a domestic reseller). I hooked up Clock, DIO, RST, and GND and fired up STCubeProgrammer. I input the bootloader and meant to hit "verify" but accidentally hit "download" and I flashed my bootloader (again). It worked first try without issue and upon reset my firmware was still running. I couldn't hook up 3.3V because my USB port on my laptop couldn't handle it the combined current but USB power from a wall wart did the trick to power on the Robin Nano for flashing (and eventual verifying).

If you want to throw money at the problem, this was MUCH easier than using a Pi and I recommend this recovery method.