-
-
Notifications
You must be signed in to change notification settings - Fork 19.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Panucatt Re-Arm Board Issue After Compiling #12426
Comments
You do need to reset the board to write the firmware after it is moved onto the sdcard, the fact it turned into 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. |
Always supply your configs as requested in the issue template. |
@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 |
You mention setting |
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 ***@***.***> 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.
|
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? |
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 ***@***.***> 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.
|
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? |
Upload port is the volume or usb card on the re-arm [platformio] 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. |
@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. |
@gloomyandy. I will give that a try when I get home this afternoon. |
Hi
this not work for me. show in my case, my environmet is linux, and set the upload_port to
move to [env:LPC1768] section fails because alwais search Marlin/Marlin/src/HAL/HAL_LPC1768/upload_extra_script.py Lines 72 to 110 in 2d92f33
creating any hit? greetings |
ok. i made some progress. seems the upload_extra_script.py fails if the hardcoded creating the path anyone can fix this without creating the path by hand? greetings |
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.
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 |
@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? |
done on my side. thanks @p3p greetings |
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 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..... |
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? |
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 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? |
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). any clues? |
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. |
Got news! 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! |
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. |
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. Please let me know what steps I should take next. Thanks. |
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. |
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. |
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.
|
@p3p how do you get that output? Did you need to configure a serial port other then USB? |
Indeed Hardware Serial is the only way to get startup information, USB takes too long to initialise and connect. |
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. |
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. |
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. Test #1 Test #2 Test #3 Test #4 Test #5 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. R, |
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? |
The LCD needs 5V, you need a special cable for Re-Arm (you can make it yourself) look at the Panucatt website. |
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. |
I ran 24v directly to RAMPS board input power connectors and never saw a difference. 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. |
The LCD is powered by the RAMPS, |
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... |
I will look into this when I get home this afternoon. Thanks! |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: