Sanguino 1.3b (reprap.me) + Sprinter unidirectional X axis

Hi guys,
I'm currently investigating a unidirectional X axis issue:
o Sanguino 1.3b
o Sprinter : MOTHERBOARD 62, mcu=atmega644p so __AVR_ATmega644P__ defined by gcc
o fake stepsticks

HW comes from reprap.me

So I wrote a little test program to troubleshoot. It's making a X revolution in one direction (1 step every milli), then wait 1s and then goes in the other direction and so on and so forth:

void test() {

  SET_OUTPUT(X_ENABLE_PIN);
  //SET_OUTPUT(X_DIR_PIN);
  DDRC |= MASK(PINC5);
  
  SET_OUTPUT(X_STEP_PIN);
  
  WRITE(X_ENABLE_PIN, LOW);
  //WRITE(X_DIR_PIN, LOW);
 PORTC &= ~MASK(PINC5);
 
  int dir = 1; 
  while (true) {
    int nsteps = 200 * 8;
    delay(1000);
    dir = !dir;
    
     //WRITE(X_DIR_PIN, dir);
    if (dir) {
      PORTC |= MASK(PINC5);
    } else {
      PORTC &= ~MASK(PINC5); 
    }
    
  
    //WRITE(X_ENABLE_PIN, dir);
    WRITE(X_STEP_PIN, LOW);
    while (nsteps--) {
      delay(1);
      WRITE(X_STEP_PIN, HIGH);
      delay(1);
      WRITE(X_STEP_PIN, LOW);    
    }
  }
}

Note that's it doing 200 * 8 steps per rev because reprap.me's selling fake stepstick not capable of 1/16th of a step.
Note also that I tried both using Sprinter fastio.h macros/pin definitions (from pins.h) and using directly stuff from avr/io.h
From the 1.3b board schematics found on reprap.me, and confirmed by visual inspection, the direction pin of the X driver goes to PC5 on the 644p (pin 24)

Not working. X stepper still goes in one direction. It's working with Y axis (changing every X in Y in the test code).

So I unplugged the driver and used a logic analyser to monitor the dir, step and enable pins (I uncommented the "WRITE(X_ENABLE_PIN, dir);" for this test)

Here are the results:


As you can see the X dir pin (24) is always high and the X enable pin is switching one every two rev.
So switching from HIGH/LOW works for ENABLE but not for DIR.

I double checked for shorts on the circuit with a multimeter and it's all good.

Do you have any idea what could be wrong ?

Do you think the 644p's dead ?

Cheers,
Seb

Edited 1 time(s). Last edit at 08/04/2012 07:26AM by sb.

Most likely a PCB fault but could be the pin. You can bend the pin so it doesn't go in the socket to isolate it to be sure.

---

[www.hydraraptor.blogspot.com]

For the community record: the problem was that the JTAG was enabled (factory default). JTAG is using PC2,3,4,5 which on my hardware configuration (Sanguinololu 1.3b) are mapped to X,Y,Z end-stops and the X direction.
So if your end-stops AND the X direction aren't working it's likely that the JTAGEN bit of the high fuse byte is set to 0 (enabled) on your 644p.
Seb

Edited 1 time(s). Last edit at 08/11/2012 01:10AM by sb.

Thank you for describing this problem in such detail, Seb. My setup is experiencing the same symptoms that you've described. The X_DIR_PIN remains at ~4.7V regardless of direction, but the Y, Z, and E axes DIR_PINS all switch between 0V and 4.96V as expected when changing direction via Pronterface. This RepRap build is my first encounter with ATMEGA chips and the Arduino software. I used an Arduino Uno as an ISP to burn the bootloader. Is there a way to use it to reset fuse bits, or should I just try different firmware?

Thanks

You can set the fuse byte using ISP and avrdude like so:

avrdude -c usbtiny -p m644p  -u -U hfuse:w:0xD8:m -v

In this example, JTAG is disabled and also:
o boot loader as to be mapped in memory at address $7000 (words)
o boot loader max size is 4096 (words)

So, if you choose to use this 0xD8 value, make sure that in the bootloader Makefile, you tell the linker that it must
be mapped at $7000 (words). Like so:

LDSECTION  = --section-start=.text=0xE000

(ld's expecting offset in byte, not word, so 2 x $7000 = 0xE000).

You might want to read the value of the fuse byte before, just to check what's your current setup.

In general, make sure that your boot options are consistent with the bootloader Makefile.

Also, I found this website very useful: [www.engbedded.com]

Hope it helps,
Seb

Edited 1 time(s). Last edit at 08/19/2012 12:33AM by sb.

Hey GUys ! I have a same problem with Y axis. I don't know how could I fix it. I don't know how the electronics are work.

I have an ARDUINO MEGA 2560. How can I disable JTAG? because My Y pololu's DIR pin is connected to A7 pin. Please someone let me know the stpes. Thanks a lot! I'm too sily for this .

Bazsi

Hy guys!!

I have a big problem with my RAMPS and Arduino mega 2560. I have got the same problem like your had. My Y axis stepper motor move only one direction. I measure the Voltage between GnD and DIR pin. It's constantly 0.00 V the other three Pololus work good. Today I check my ARDUINO with a blink Firmware ( BLINK FIRMWARE ) . My Y axis pololu's dir pin is connect to A7 connectro on ARDUINO. The LED was blinking constantly so the mother board is good. I read a lot of about JTAG enable / disable problems but I don't think that this could be cause the problem.

Here are the facts:
- The A7( analog) pin doesn't changing the Voltage between zero and around 5.0 V This pin connect to Y axis stepper motor's POLOLU dir pin.
- The Mother board is good because of the test Blink program
- The pololu is good because it's work with an another motor.
- Every other stuff are working good!
- I think the Endstop is good because I checked it with an another stepper motor.

Electronics:
- ARDUINO MEGA 2560
- RAMPS 1.4 REV3.0
- Pololu
- Matrix stepper motor

FIRMware:
- MArlin / Sprinter firmware are same don't work.
- I use Printerface program and try out an another which name is REplicatorG.