Welcome! Log In Create A New Profile


Endstops not working after firmware upgrade

Posted by prof braino 
Endstops not working after firmware upgrade
January 25, 2015 01:17PM
Hi after modifying sprinter firmware on my previously working sanguinololu 1.3a, the X axis only moves in one firections, and the X,Y, and Z endstops do not appear to be detected.

Previous firmware was 2011, Windows XP, Arduino 0023, Sanguino-0018r2; this worked "good enough" until I found I might improve print quality be correcting e-steps etc. using new calibration instructions.

However, old Windows XP PC died, I am now using Linux Mint 17-64 (similar to Ubuntu), Arduino 1.0.5 (from software center), and Sanguino 0101r1 from google code, and the same (?) sprinter from klimet's git repository.

Compiling the default code code gives error:

/usr/share/arduino/hardware/sanguino/cores/arduino/HardwareSerial.cpp:132:15: error: attempt to use poisoned "SIG_USART1_RECV"
#elif defined(SIG_USART1_RECV)

This was "correctted" by applying fix:


to Arduino.h in /usr/share/arduino/hardware/sanguino/cores/arduino

Unfortunately, that fix appears to cause my endstops/one-direction-X problem.

I also recived the same 'poisoned "SIG_USART1_RECV"' from Gen7 2.1 from [reprap.org] so I stopped investigating Gen7 after seeing the same result.

Since the machine was printing for years before the firmware change, I think the physical hardware is still fine, and the error must come from the tool chain.

Has anyone noticed an issue with linux 64bit OS, or can you identify my mistake(s)? Has anyone had success with linux, or are successful firmware created using windows?

Thanks in advance, this is making me nuts over here.
Re: Endstops not working after firmware upgrade
January 25, 2015 01:54PM
read here: [reprap.org]

I would guess that the pins are not mapped correctly because the sanguino wiring i/o may not be correct. read the instructions, and see if this all helps.

what tests have you done to test the end stops? are you sure the pinouts are the same as before for the i/o?

list all of your code by uploading a zip file. someone here will likely help you out!
Re: Endstops not working after firmware upgrade
January 26, 2015 01:07PM
What instructions in particular are you refering me to? the ones linked above point to "Burning the Sanguino Bootloader using Arduino as ISP" which do not appear relevant as the bootload must already be programmed, as I can send new firmware to the printer and see the "Sprinter" boot identifer string change to e.g. "Sprinter 20150125-1746". Is there an indication my bootloader is incorrect?

What indicates that the pins are not mapped correctly, where can I find the correct mapping? Where can I find the newest "sanguino wiring i/o", what is this and how has it changed form the original sanguinololu 1.3a? I thought these were part of the sanguino support we download from e.g. google code [code.google.com]

Here is my testing results:
Test1 - no ends stops triggered: SENDING:M119 - x_min:L y_min:L z_min:L
Test2 - x enstop triggered: SENDING:M119 - x_min:L y_min:L z_min:L
Test3 - y enstop triggered: SENDING:M119 - x_min:L y_min:L z_min:L
Test4 - z enstop triggered: SENDING:M119 - x_min:L y_min:L z_min:L

The only changes I have made (aside from the sprinter boot identifier string) are to the sprinter configurattion.h file, according to my notes from the original build. (my notes may be incomplete, which would account for my confusion now). I have mechanical endstops normally closed between signal and ground. I think the note in the code says to leave the #define ENDSTOPPULLUPS (NOT commented out); and NOT to invert the endstops, since the axiis all move, they just done stop and teh x only moves in one direction.


// BASIC SETTINGS: select your board type, thermistor type, axis scaling, and endstop configuration
//... [comments removed]
// Sanguinololu 1.2 and above = 62
// Gen 7 @ 16MHZ only= 7
// ... [comments removed]
#define MOTHERBOARD 62

//// Thermistor settings:
// 1 is 100k thermistor
// ... [comments removed]

//// Calibration variables
// X, Y, Z, E steps per unit - Metric Prusa Mendel with Wade extruder:
// #define _AXIS_STEP_PER_UNIT {80, 80, 3200/1.25,700}
#define _AXIS_STEP_PER_UNIT {58.1818, 58.1818, 3200/1.25,625.70629055} // DAW 20150117

//// Endstop Settings

#define ENDSTOPPULLUPS // Comment this out (using // at the start of the line) to disable the endstop pullup resistors
// The pullups are needed if you directly connect a mechanical endswitch between the signal and ground pins.
//If your axes are only moving in one direction, make sure the endstops are connected properly.
//If your axes move in one direction ONLY when the endstops are triggered, set [XYZ]_ENDSTOP_INVERT to true here:
const bool X_ENDSTOP_INVERT = false;
const bool Y_ENDSTOP_INVERT = false;
const bool Z_ENDSTOP_INVERT = false;

// const bool X_ENDSTOP_INVERT = true; // DAW
// const bool Y_ENDSTOP_INVERT = true; // DAW
// const bool Z_ENDSTOP_INVERT = true; // DAW

// This determines the communication speed of the printer
#define BAUDRATE 115200
//#define BAUDRATE 250000 // 20150118 DAW

// Comment out (using // at the start of the line) to disable SD support:
// #define SDSUPPORT // 20150118 DAW

[end of changed to file]

I feel the root cause might be related to the error message:
/usr/share/arduino/hardware/sanguino/cores/arduino/HardwareSerial.cpp:132:15: error: attempt to use poisoned "SIG_USART1_RECV"
#elif defined(SIG_USART1_RECV)

and the "fix" as listed above ( fix gets rid of the error message, but results in other problems). I do not recall this message (or any error message) last time I burned the firmware.

Edited 1 time(s). Last edit at 01/26/2015 08:14PM by prof braino.
Re: Endstops not working after firmware upgrade
January 26, 2015 01:44PM
So, I found the endstop testing instructions, [reprap.org]

The voltage on the signal pin is 0 volts when in the normally closed position, and 4.8-5.0 volts when tripped.
However, the software M119 command reports the endstops a L (low) in either case.

Therefore, the firmware is misconfigured.

I have [sanguino.googlecode.com] copied into my ...


... directory, with no changes. Is there something more appropriate?

Again, I have sanguinololu 1.3a hardware, toolchain running on Linux Mint 17 64 bit, arduino IDE 1.0.5 from software center.

Re: Endstops not working after firmware upgrade
February 17, 2015 01:46PM
Follow up: Endstops not working after firmware upgrade was cause by incorrect fuse setting after buring the boot loader. The Boards.txt file in Sanguino 0101r1 from google code has incorrect fuse settings for Sanguino 1.3a (probably factory defaults).
Editing boards.txt file and re burning the firmware corrected the issue.

Also, the 'poisoned "SIG_USART1_RECV" message was caused by installing the arduino IDE from the software center (using Linux Mint 17 MATE). The install place the arduino iIDE in /usr/share/arduino and this seems to be the problem. (premissions or paths of something). The fix for this was to download the arduino ide zip file and extract is in my home directory, and use the executable directly without an install step.

my notes are at [reprap.org] if you want to see the whole gory story.
Re: Endstops not working after firmware upgrade
February 18, 2015 06:12AM
Default is to have jtag enabled.

On a sanguinololu type board this disabled X,Y and Z endstop pins and X stepper driver direction line
Re: Endstops not working after firmware upgrade
April 27, 2017 08:42AM
I have a ATmega 1284 based Gen 7 AVR 1.5 which has been running on Marlin 1.0.2 firmware without issues for a few years. I tried to updated to Marlin 1.1.0 RC8. using Arduino IDE 1.8.1 All went fine with the update and everything seems to work except not only is the X endstop not working but it is not even recognised with a M119. See below

SENT: M119
READ: Reporting endstop status
READ: z_min: open
READ: ok

The problem seems to be firmware related because when I go back to ver 1.0.2 the x endstop is reported as expected. I have checked the pin file in both firmware versions for GEN7_VERSION 14 and pin 0 is assigned to X endstop in both. Can anyone throw some light on what might be happening?
Sorry, only registered users may post in this forum.

Click here to login