Panucatt Re-Arm Board Issue After Compiling

[dcwalmsley]

Hardware background: I purchased through Kickstarter a couple years ago what is now the Panucatt RE-ARM board with LPC1768 ARM-Cortex M3 processor. I also plan to mate it up with a RAMPS 1.4 board and a LCD display later (undecided on displays at this time).

Installed PlatformIO software and downloaded Marlin bugfix-2.0 onto my Windows10 laptop. I also have installed or are listed the following: .piolibdeps: TMCStepper, U8Glib-HAL-ID1932, LiquidCrystal_ID136, and Servo_ID883 .pioenvs: LPC1768

In the platformIO.ini file I edited the following: [platformio] src_dir = Marlin build_dir = .pioenvs lib_dir = .piolib libdeps_dir = .piolibdeps boards_dir = buildroot/share/PlatformIO/boards env_default = LPC1768

Also edited by adding "upload_port = COM[6]" to the [env:LPC1768] section of NXP LPC176x ARM Cortex-M3.

NXP LPC176x ARM Cortex-M3

[env:LPC1768] platform = https://github.com/p3p/pio-nxplpc-arduino-lpc176x/archive/master.zip framework = arduino board = nxp_lpc1768 upload_port = COM[6] build_flags = -DTARGET_LPC1768 -DU8G_HAL_LINKS -IMarlin/src/HAL/HAL_LPC1768/include -IMarlin/src/HAL/HAL_LPC1768/u8g ${common.build_flags} debug options for backtrace -funwind-tables -mpoke-function-name lib_ldf_mode = off lib_compat_mode = strict extra_scripts = Marlin/src/HAL/HAL_LPC1768/upload_extra_script.py src_filter = ${common.default_src_filter} +<src/HAL/HAL_LPC1768> monitor_speed = 250000 lib_deps = Servo LiquidCrystal https://github.com/MarlinFirmware/U8glib-HAL/archive/dev.zip https://github.com/teemuatlut/TMCStepper.git

I also added under Configuration.h for my Re-Arm board "#define MOTHERBOARD BOARD_RAMPS_14_RE_ARM_EFB" and ensured #define SERIAL_PORT -1 was set.

PlatformIO successfully compiled the code and I was able to see it as "Firmware.bin" on the FAT32 formatted memory card installed on the RE-ARM, but this is where I was unable to go any further. According to the website for Installing Marlin 2.0 with PlatformIO I should see both the FIRMWARE.CUR and EEPROM.DAT files. In fact the first one did appear after pressing reset button on the board, no EEPROM.DAT file was listed. Further more, I have tried numerous cold restarts and attempted to connect Ponterface via COM6 to the board but I'm stuck at "Connecting" message on Ponterface.

So I feel at this point that I'm either missing something or the website needs another review/update, OR my board is defective. Looking for guidance on the next step to getting firmware to function on this board.

[p3p]

You do need to reset the board to write the firmware after it is moved onto the sdcard, the fact it turned into firmware.cur means that the firmware was written successful, upload_port does not need set, the firmware is written directly to the sdcard not through the serial port, by default we do not write the EEPROM data to the sdcard anymore unless that mode is selected, it is written to internal flash instead.

Can you tell me what the status LED does during the boot up of the board, and are you sure it is COM6 it is connected to.

[p3p]

Always supply your configs as requested in the issue template.

[dcwalmsley]

@p3p, Only LED indicator is a steady power (red) light. At no time during upload or after reboot did I observe any other light activity indications.

I verified COM6 is the correct port for the board through Device Manager as well as pulling the USB plug and noting the loss of the COM6 in the device list.

Ive attached the two config files for you review. Do you need any other file/s Config.zip

[p3p]

You mention setting SERIAL_PORT to -1 but that is not the case in the configs it's still 0, I missed that you hadn't yet connected to the ramps board so the status LED (pin 13) won't be visible.

[dcwalmsley]

As per the instructions on the website, I did not mate the Ramps board to the REARM during the building/compiling process.

I also tried 0 and - 1 for SERIAL_PORT with no luck.

Do I need to swap jumper from USB to INT and provide external power?

I could mate RAMPS board and test using external power.

On November 13, 2018 23:35:02 Chris Pepper notifications@github.com wrote:

You mention setting SERIAL_PORT to -1 but that is not the case in the configs it's still 0, I missed that you hadn't yet connected to the ramps board so the status LED (pin 13) won't be visible. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[p3p]

Do I need to swap jumper from USB to INT and provide external power?

Will be fine with USB power for testing but if you draw more current, for a backlit display etc, you may need an external supply.

SERIAL_PORT does need to be -1 for the USB Serial so that was correct

Without the status LED it's hard to determine what is wrong, it seems to have flashed correctly, is the board showing up as Marlin USB Device on your computer?

[dcwalmsley]

Yes. I can use my file explorer to go to D: drive and see the memory card and FIRMWARE.CUR file.

On November 14, 2018 10:16:36 Chris Pepper notifications@github.com wrote:

Do I need to swap jumper from USB to INT and provide external power? Will be fine with USB power for testing but if you draw more current, for a backlit display etc, you may need an external supply. SERIAL_PORT does need to be -1 for the USB Serial so that was correct Without the status LED it's hard to determine what is wrong, it seems to have flashed correctly, is the board showing up as Marlin USB Device on your computer? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[stefan85]

I think I have the same issue. I made a board with a LPC1769 and programming of the MCU seems to be ok, because the file is being renamed to FIRMWARE.CUR.

When I connect the board to the PC, I see a new serial port (COM 14). Then the SD card is being mounted showing the FIRMWARE.CUR. A few seconds later the SD card is unmounted and the serial port is also gone. After that I see a device "smoothie". But I don't know what to do with this.

Do you have the same issue?

[ant0nyk1ng]

Upload port is the volume or usb card on the re-arm

[platformio] src_dir = Marlin build_dir = .pioenvs lib_dir = .piolib libdeps_dir = .piolibdeps boards_dir = buildroot/share/PlatformIO/boards env_default = LPC1768 upload_port = /Volumes/REARM

This is how I have been doing it. I name the Mini USB REARM and copy the firmware.bin then I start Atom plugin the USB to Re-arm board and comple/upload

Some Info form here http://marlinfw.org/docs/basics/install_platformio.html I thought there was a more detailed or different how to but I can't find it now.

[gloomyandy]

@stefan85 it sounds like you have a different problem. That behaviour indicates that Marlin is crashing or triggering the watchdog timer shortly after it boots. Are you sure that whatever hardware you are using matches the configuration you are using to build Marlin with?

@dcwalmsley if you can see the SD card as a USB device then that shows that Marlin is running on the Re-Arm. I'm surprised that you are not able to connect to it. When you attempt to connect from pronterface does the USB drive continue to be available on your PC? If it disappears then this probably means Marlin has crashed for some reason. You might want to try using something like repetier host or perhaps just a simple terminal emulator like putty to connect rather than pronterface.

[dcwalmsley]

@gloomyandy. I will give that a try when I get home this afternoon.

[sl1pkn07]

Hi

El puerto de carga es el volumen o la tarjeta USB en el rearme

[platformio] src_dir = Marlin build_dir = .pioenvs lib_dir = .piolib libdeps_dir = .piolibdeps boards_dir = buildroot / share / PlatformIO / boards env_default = LPC1768 upload_port = / Volumes / REARM

this not work for me. show "Warnming: ignore upload_port option in [platformio] section" or something

in my case, my environmet is linux, and set the upload_port to /run/media/>user</REARM

upload_port = /run/media/sl1pkn07/REARM

move to [env:LPC1768] section fails because alwais search /media path, set in here https://github.com/MarlinFirmware/Marlin/blob/2d92f333f5f3f004c9007e2428c2877087797512/Marlin/src/HAL/HAL_LPC1768/upload_extra_script.py#L72-L110

creating /media symlinks pointed to the real path not work

any hit?

greetings

[sl1pkn07]

ok.

i made some progress. seems the upload_extra_script.py fails if the hardcoded /media path not exist.

creating the path /media by hand works showing :"Unable to find destination disk. File must be copied manually", but continue the build and upload automatic into the path set in the upload_port option in [env: LPC1768] section . but this is a mess, because all (or almost all) modern system uses UDISKS2 for manage the removable media, and this set the path in /run/media/<user>. /media/ is , in some systems, deprecated

anyone can fix this without creating the path by hand?

greetings

[p3p]

I was concerned when the auto detect script was added that it would cause issues as making it work on all platforms in all configurations would be practically impossible, As far as I'm aware the /media folder is still generally the most common auto mount folder across linux users though.

When your distribution causes issue with the script it's easiest to just disable the autodetect script and set the upload drive manually.

#extra_scripts     = Marlin/src/HAL/HAL_LPC1768/upload_extra_script.py
upload_port = /run/media/sl1pkn07/REARM

We can't test on all OSs never mind all distributions so if you can think of a more robust solution for auto-detection the patch would be welcomed.

edit: of course it would also help if we caught all the possible exceptions from file operations, at least then it would build

[dcwalmsley]

@p3p,

This afternoon I discovered the problem was with the REARM board itself. I have a spare board and I transferred the memory card to it and pinned the USB jumper. When I plugged the USB cable in and noted it was assigned to COM12, I opened Ponterface and successfully connected to it. So I swapped boards again and noted COM6 for the now defective board would not connect via Ponterface or with Simplify3D.

So I wonder if there is a way to save the defective board so it can be made useful? Could the problem be a bad bootloader? If so , what process would I need to take to see if that is the issue?

[sl1pkn07]

done on my side. thanks @p3p

greetings

[dcwalmsley]

This last weekend I decided to troubleshoot further the issue with the boards working on moment and not the next.

I have three brand new REARM boards and after reporting last week that the initial board was defective, I've since decided it may not be defective. The reason, The second board which appeared to work when swapping the memory card showed that I could in fact connect to it and received a "Ok" status. What happened next baffled me.

I decided to mate the RAMPS board onto it and still received an "OK" even through the board is not populated which I felt made no difference at this point. So far so good.

So I decided to reflash the memory card on this board with the RAMPS mated to it and everything appeared good. I was able to elxplorer to the REARM memory card and see the FIRMWARE.BIN existed. I then pressed reset. So this is where things went weird. The RAMPS LED flashed twice then three times before going steady. This seems to be normal process. I then reconnected the USB cable to the port but at this time I received a message from Windows that there was something wrong with the USB port and I could no longer explore to it. I tried using numerous software to access it via USB with no luck.

So I pulled card and but it directly into PC USB and noted I could read and see the FIRMWARE.CUR file. I pulled it and placed in the third REARM board and was able to connect to is via Ponterface or Simplify3D via USB connection. Note, no RAMPS on this board.

I then recompilied and uploaded the firmware and again same result. I could explore to memory card via windows but as soon as I pressed the reset and waited 30 seconds or more pulled USB and reconnected I noted Windows could no longer detect USB port nor could I access the memory card.

I'm seeing an issue with the bin file. Once the conversion on the board is complete and file has been changes to CUR something is happening that causes the USB interface to become unavailable or garbled to Windows.

So now you know what I know. Hmmmm.....

[gloomyandy]

It is not unusual to receive a message from windows to say that something is wrong with the device when you flash new firmware. This is caused by the transition from the boot loader USB interface to the Marlin one midway during the USB initialisation. More often than not the Marlin USB device is actually fine at this point, but occasionally you will need a 2nd reboot after you install a new firmware.bin file.

Are you saying that after you install new firmware it never works. even after a 2nd reset?

[dcwalmsley]

Feeling confused and a bit stupid. I owe an apology. One board is bad... It won't connect to computer USB no matter what I do with it. The other two boards can read the memory card with the FIRMWARE.CUR listed on it AND I did get both boards to connect to the Ponterface software with this message "Connecting... Printer is now online. Using tool 0."

But as soon as either of my RAMP 1.4 boards are mated and power is applied, I get nothing. What is needed to make the RAMPS board not interfere with the REARM board and allow me to start populating the drivers and other connections?

[amigoloko]

brand new re-arm board, comes uploaded with Smoothieware firmware, no SD card (where is the firmware, does it write it down to chip? is not supposed to work from sd?) (board connected to repetier host, trough com 27, welcome message states smoothieware). compile marlin 2.0, using platform io and vscode, manage basic config settings, got the .pioenvs/LPC1768/firmware.bin copy to sd (fat 32) (4GB) (centon): reset, no firmware.cur (or anything different from original .bin file) unplug (30 sec) plugin, no firmware.cur (nothing dif from og) afterwards, connect to repetier host, still smoothieware

any clues?

[gloomyandy]

The smoothieware bootloader copies the firmware from the SD card firmware.bin file into the chips flash memory and then renames the file as firmware.cur. If the file is not being renamed then there is either something wrong with the bootloader (maybe there isn't one) or there is something wrong with the SD card or the file you have copied to it. In all of these cases this is probably not a Marlin problem. If you allow your board to boot smoothieware can you see the SD card via USB on your PC (you should be able to), if not then there is probably some sort of problem with the card, or the way it has been formatted.

You may want to check out some of the smotthieware forums as they may have advice on the best way to format an SD card using whatever sort of PC you have (it is almost certainly different for Windows/Mac/Linux).

[amigoloko]

The smoothieware bootloader copies the firmware from the SD card firmware.bin file into the chips flash memory and then renames the file as firmware.cur. If the file is not being renamed then there is either something wrong with the bootloader (maybe there isn't one) or there is something wrong with the SD card or the file you have copied to it. In all of these cases this is probably not a Marlin problem. If you allow your board to boot smoothieware can you see the SD card via USB on your PC (you should be able to), if not then there is probably some sort of problem with the card, or the way it has been formatted.

You may want to check out some of the smotthieware forums as they may have advice on the best way to format an SD card using whatever sort of PC you have (it is almost certainly different for Windows/Mac/Linux).

Yes, sd card is available when plugging in the board to PC Windows 10. I have tried, uploading automatically from VScode, .bin file is been written on sd, and manually copying .bin file to sd. neither case worked. I will look for smoothieware forums to see is any hints there... if someone with the same issue, raise a hand ...

[amigoloko]

Yes, sd card is available when plugging in the board to PC Windows 10. I have tried, uploading automatically from VScode, .bin file is been written on sd, and manually copying .bin file to sd. neither case worked. I will look for smoothieware forums to see is any hints there... if someone with the same issue, raise a hand ...

Got news! tried a SanDisk 1GB micro SD, formatted as FAT, and worked (mega old sd card) originally tried with Centon 4.0 microSD HC 4, formatted FAT32, fail formatted FAT, fail

I got marlin up and running, I will try to define what is wrong with those type of SDs

[amigoloko]

Got news! tried a SanDisk 1GB micro SD, formatted as FAT, and worked (mega old sd card) originally tried with Centon 4.0 microSD HC 4, formatted FAT32, fail formatted FAT, fail

I got marlin up and running, I will try to define what is wrong with those type of SDs

got it, set the partition to primary instead of logical!

[p3p]

It's usually best to format SD cards that are going to be used in stand alone devices, rather than a computer, with the official SD card formatter tool (https://www.sdcard.org/downloads/formatter_4/) as they tend to be very limited with the configuration supported to save memory.

Although I've always used the default options on the built in OS formatters and not had an issue.

[dcwalmsley]

Hoping everyone had a good Thanksgiving.

So I have to say that this process of flashing and testing Marlin 2.0 has me both frustrated and annoyed.

I now have 3x RE-ARM Panucatt boards that cannot be seen via Serial or Logical Device via Windows Explorer.

Started with reformatting the 32Gb card ensuring it was using Fat32 and volume name (lower case) rearm. I then decided to forego using VSCode application and installed Atom with CLANG and all Atom patches. This was done to both my upstairs laptop and my workbench workstation both with Windows 10 on them.

Followed the online instructions and the guy's video (https://www.youtube.com/watch?v=H-c8UTg-EMU&t=632s) and I downloaded the latest Marlin bugfix2.0 and set "#define SERIAL_PORT -1" as well as renaming board to "#define MOTHERBOARD BOARD_RAMPS_14_RE_ARM_EFB" then successfully compiled and uploaded to the memory card.

I then proceeded to successfully get a "Printer Online" message when connecting to Ponterface. I even performed a M114 and M119 and noted the XYZ position and Endstop "Triggered" messages. All is good, so I decided to go further and modified more firmware code in both the Configuration.h and Configuration_adv.h files (See attached).

When I compiled and uploaded the firmware.bin file and reset the REARM I lost connection to the board and I was no longer able to reconnect via Serial or Logical means.

I pulled the memory card and plugged into the PC and noted the firmware.CUR exists on the card so I know it converted when reset was initiated. I pulled memory card and plugged into another REARM board and was not able to connect to it. Pulled that card and did the same on third board with same result.

At this time, I reformatted the card and attempted to recompile and upload and noted that Atom was not able to see the REARM board with memory card installed. I double checked that Windows Explorer also wasn't able to see and that is when I noticed that Explorer was not allowing me to see any of my logical devices but as soon as I unplugged the REARM board, all logical devices popped back in.

So at this time, I believe that all three REARM boards are now bricked. I've eliminated the memory card or the formatting as the problem. I also eliminated VSCode or Atom applications or the instructions online as the problem as well.

So my conclusion is that the Panucatt's REARM board has issues with the firmware code.

Ive attached the files to show what was setup on them for future installation into my Delta printer albeit not completely configured and I would like to snail mail both RAMPS boards, all three REARM boards and my 32 Gb memory card and see if you can identify issues I'm not seeing.

DCW_Delta_MarlinFirmware.zip

Please let me know what steps I should take next. Thanks.

[p3p]

So at this time, I believe that all three REARM boards are now bricked

It's very unlikely that they are bricked we don't change the boot-loader and it can't overwrite itself, I'm sure if you put firmware on the sd card then plug it in to the Re-ARM it will flash it (you could try putting smoothieware back on it), as for why you are having so much trouble I don't know Re-ARMs have been used for a while by a few people but I'l look into it.

If Marlin isn't booting, or if Marlin does boot but mounts the sd card to access gcode the USB storage device will not show up in Windows.

[gloomyandy]

As above it is very unlikely that the board is bricked. It sounds like you need to revert things back to your original working configuration and then copy the firmware.bin file over to your SD card on your PC (manually if the platformio build is not able to locate the card), if you then pop the card into the re-arm and reboot (possibly twice) you should then have a working board. Once you get into that state you will probably need to make your changes one at a time and test each change in turn. Tedious I know but remember that much of the 2.0.x codebase is new (and changing) and that it is still relatively early days for Marlin on 32 bit boards. It looks like some part of your configuration is causing Marlin to crash which is then leaving your board in the unresponsive state.

Why did you decide to switch from vscode to atom by the way? In general I've found vscode to be much faster and more reliable than atom when using platformio.

[p3p]

Using Marlin built with your configs on my Re-ARM results in a fatal error when it can't initialise the TMC2130 drivers which halts the MCU for safety.

echo:LPC1768 (100Mhz) Initialized
start
echo:PowerUp
Marlin bugfix-2.0.x

echo: Last Updated: 2018-01-20 | Author: (none, default config)
echo:Compiled: Nov 26 2018
echo: Free Memory: 20503  PlannerBufferBytes: 1344
echo:EEPROM version mismatch (EEPROM=V61 Marlin=V63)
echo:Hardcoded Default Settings Loaded

X driver error detected:
overtemperature
short to ground (coil A)
short to ground (coil B)
XYZE
Enabledfalsefalsefalsefalse
Set current800800800800
RMS current795795795795
MAX current1121112111211121
Run current25/3125/3125/3125/31
Hold current12/3112/3112/3112/31
CS actual31/3131/3131/3131/31
PWM scale255255255255
vsense1=.181=.181=.181=.18
stealthChoptruetruetruetrue
msteps0000
tstep4294967295429496729542949672954294967295
pwm
threshold0000
[mm/s]----
OT prewarntruetruetruetrue
OT prewarn has
been triggeredfalsefalsefalsefalse
off time15151515
blank time54545454
hysteresis
-end12121212
-start8888
Stallguard thrs8800
DRVSTATUSXYZE
stallguardXXXX
sg_result1023102310231023
fsactiveXXXX
ststXXXX
olbXXXX
olaXXXX
s2gbXXXX
s2gaXXXX
otpwXXXX
otXXXX
Driver registers:
X0xFF:FF:FF:FF
Y0xFF:FF:FF:FF
Z0xFF:FF:FF:FF
E0xFF:FF:FF:FF

Error:Printer halted. kill() called!

[gloomyandy]

@p3p how do you get that output? Did you need to configure a serial port other then USB?

[p3p]

Indeed Hardware Serial is the only way to get startup information, USB takes too long to initialise and connect.

[dcwalmsley]

@gloomyandy,

Success with flashing Smoothieware onto all three boards. I also mated RAMP1.4 board to the REARM and was able to get a "printer online" message on Ponterface for all three boards as well. Windows Explorer showed memory card as well. Performed M114 to verify it read "SENDING:M114", "ok C: X:0.0000 Y:0.0000 Z:0.0000:.

So boards are functional with Smoothieware flashed to them. Note: I downloaded a sterile copy of their firmware and made no modifications to it prior to compiling it.

[dcwalmsley]

@gloomyandy,

So I switched to ATOM for testing purposes. VSCode works just fine and I received the same issue on Marlin 2.0 using either compiling software. At this point either software is just fine to use.

My next step will be to go back to a sterile copy of bugfix version, compile and upload with the RAMPS mated to the REARM board. There should be no reason not to do this as in the end, no one would be tearing apart there printers boards in order to flash upgrades or mods to the firmware. That does not make sense to me and I hope to you all. I will start with serial port -1 and #define MOTHERBOARD BOARD_RAMPS_14_RE_ARM_EFB. I will also revert drivers to DRV8825 as I have these ready to install onto RAMPS1.4. This is not my end goal for these drivers as I will install the TMC2130 drivers once I modify them for RAMPS use.

More to follow.

[dcwalmsley]

Latest test results.

Here are the steps I took. Note that I have had positive results in slowly building up the configuration with the following tests.

Marlin 2.0 latest bugfix (as of 11/27) I downloaded. RE-ARM mated with RAMPS 1.4 board.

Test #1
Configuration.h Serial 0 set to -1 Motherboard set to BOARD_RAMPS_14_RE_ARM_EFB RESULT: Successful compile. I was able to see firmware.bin convert to firmware.cur after reset and Ponterface was able to connect to is.

Test #2
Configuration.h Added:

define DEFAULT_NOMINAL_FILAMENT_DIA 1.75

define TEMP_SENSOR 999 (to see if Ponterface measured 100c)

define TEMP_SENSOR 998 (to see if Ponterface measured 25c)

define X_DRIVER_TYPE DRV8825

define Y_DRIVER_TYPE DRV8825

define Z_DRIVER_TYPE DRV8825

define E0_DRIVER_TYPE DRV8825

RESULT: Successful compile. Ponterface showed correct dummy temperatures

Test #3
Configuration.h Added:

define X_MIN_ENDSTOP_INVERTING true

define Y_MIN_ENDSTOP_INVERTING true

define Z_MIN_ENDSTOP_INVERTING true

define Z_MIN_PROBE_ENDSTOP_INVERTING true

define FIX_MOUNTED_PROBE

define AUTO_BED_LEVELING_BILINEAR

define EEPROM_SETTINGS

RESULT: Successful compile except that I never saw eeprom.dat on memory card after setting M851 to Z-1.0 and then executing M500.

Test #4
Configuration.h Added:

define SDSUPPORT

define SPEAKER

define LCD_FEEDBACK_FREQUENCY_DURATION_MS 2

define LCD_FEEDBACK_FREQUENCY_HZ 5000

define REPRAP_DISCOUNT_FULL_GRAPHICS_SMART_CONTROLLER

RESULT: Successful compile except that LCD only shows blue screen with no information on it.

Test #5
Configuration.h Changed:

define X_DRIVER_TYPE TMC2130

define Y_DRIVER_TYPE TMC2130

define Z_DRIVER_TYPE TMC2130

define E0_DRIVER_TYPE TMC2130

Configuration_adv.h
Added:

define TMC_USE_SW_SPI

define MINIMUM_STEPPER_DIR_DELAY 20

define MINIMUM_STEPPER_DIR_PULSE 0

define MINIMUM_STEPPER_DIR_RATE 400000

RESULT: Successful compile.

What else do you see I need to add to this configuration for testing purposes? My board is working and maybe I attempted the other day making a huge configuration and goobered it up. At this point I hope this helps and would appreciate some guidance on getting the LCD to read correctly.

Files attached. MarlinFirmware.zip

R, Doug W

[gloomyandy]

Why are you expecting to see an eeprom.dat file on the sd card? The default configuration for LPC176X boards is to use flash memory to emulate the eeprom, so no file on the sd card.

As to the LCD, have you had the same display working on the same board with other firmware?

[kAdonis]

The LCD needs 5V, you need a special cable for Re-Arm (you can make it yourself) look at the Panucatt website. As far as I understand, your problem was solved by @p3p Your Re-Arm freezed, because you had no TMC2130 connected, so Initialisation failed: Error:Printer halted. kill() called!

[dcwalmsley]

According to http://marlinfw.org/docs/basics/install_arm.html, it stated that the eeprom.dat and firmware.cur file will be displayed on the memory card. I know you mentioned this before but I came across a Youtube video from Chris 's Basement (https://www.youtube.com/watch?v=H-c8UTg-EMU&t=632s) at time stamp 10:35. This video was produced and published on Nov 21. So I expected the same result.

The LCD has been used and test on my Hypercube and I attempted to figure what was different in the /src/inc/Conditionals_LCD.h, the /src/lcd/dogm/ultralcd_st7920_u8glib_rrd_AVR.h files.

[dcwalmsley]

@kAdonis,

I ran 24v directly to RAMPS board input power connectors and never saw a difference.
Are you saying I need to jump the display with it's own 5v input? I thought the Re-Arm board stepped down the input voltage to provide 5v for the display. Both the REARM and RAMPS1.4 are powered with 24v DC.

At this point, I have the RAMPS board driver sockets empty but I plan to modify the TMC2130 drivers to provide feedback for sensorless detection of endstops. As of now, I'm only looking to ensure I can flash the boards I have to ensure repeated positive results to see the firmware.cur file on memory card via Windows Explorer and to be able to connect to it. I've had issues before and this is why I posted this blog to the Devs to see if it's a code issue, board, issue, or operator error issue.

[kAdonis]

The LCD is powered by the RAMPS, With Arduino+RAMPS it gets 5V, with the Re-ARM+Ramps it gets only 3.3V when using the standard cable http://panucattdevices.freshdesk.com/support/solutions/articles/1000243195-lcd-display-installation Your boards are working as expected, dont worry For further testing you need at least stepper drivers and steppers connected

[gloomyandy]

That used to be the case, but both the video and the documentation are out of date. Using flash eeprom emulation has been the default since October 14th. It didn't make sense to have the default be using a file when we made sharing the SD card between a PC and Marlin the default configuration (as reading/writing the file would require the card to be made unavailable to the PC).

As to the LCD do you have the special cable you need for this LCD/board combination as mentioned above you need to connect 5V separately. See the following page... http://panucattdevices.freshdesk.com/support/solutions/articles/1000243195-lcd-display-installation

[dcwalmsley]

@gloomyandy,

I will look into this when I get home this afternoon. Thanks!

[dcwalmsley]

Just got home and modified the EXP1 cable to accept J3's 5vdc power. Now seeing display with no issues. Thanks again for the assist.

[dcwalmsley]

Received new TMC2130 drivers and custom built wiring to pin up onto a RAMPS board. Will start testing next day or so. After this is done, I may request this ticket be closed as I'm unclear why I had initial problems with the REARM board accepting my firmware build.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.