RAMBo eeprom troubles

[BenTheRighteous]

Today I decided I was going to fine-tune my extruder settings, and I think I somehow broke my EEPROM as a result.

My test was that I would remove the bowden from the ezstruder and then have it spit out 1m of filament. So I did that and measured the result - 1001mm. Just 1mm off - easily within my human margin of error.

What I SHOULD have done was leave it damn well alone.

What I DID do was calculate a new steps per mm using this formula: (previous steps per mm) * (measured result) / (desired result) = 92.65 * 101 / 100 = 91.732673267326732673267326732673.

Of course I was being a nitwit and rather than key in 9 1 point 7 3 3, I just copy/pasted the whole thing into Repetier Host, thinking naively that it would automatically round it to the appropriate precision for me. Ho ho ho.

Now whenever I open eeprom settings, I get something that looks like the following, although the rows that are screwed up are random each time:

What I've tried already (in the order I tried it):
Upload eeprom_clear via arduino
Make sure I have the latest seemecnc firmware via github (repetier 0.91 I believe)
Upload latest firmware
Recheck eeprom settings in RH (still screwed up)
Recheck eeprom settings in MC (still screwed up)
Reboot computer
Recheck eeprom settings in RH (still screwed up)
Import known-good eeprom settings in RH
Recheck eeprom settings in RH (still screwed up)

...at this point I'm not sure what else I can try. I'm afraid to run the printer like this. Since both RH and MC don't display the correct values in the table, the fault has to be within the RAMBo, but if eeprom_clear won't fix that, what will?

[Earthbound]

A couple of things:

First, to add insult to injury, the calculation is incorrect. 92.65 * 100 / 101 = 91.7326....... You swapped the measured and desired values in the post and should be 1000 and 1001, not 100 and 101. You want a number close to 92.56.



Back to what will help with the settings...

When you upload the EEPROM Clear sketch, are you getting an error message. EEPROM does not appear to be resetting. Clearing it forces the firmware to load it with default values.

[jdurand]

I'm not familiar with the Atmel processor, could a program buffer overrun killed part of the code space? Might need to reload the program.

[Earthbound]

I'm not familiar with the Atmel processor, could a program buffer overrun killed part of the code space? Might need to reload the program.

Seems he already tried reloading the code (Repetier firmware).

What I've tried already (in the order I tried it):
Upload eeprom_clear via arduino
Make sure I have the latest seemecnc firmware via github (repetier 0.91 I believe)
Upload latest firmware
Recheck eeprom settings in RH (still screwed up)
Recheck eeprom settings in MC (still screwed up)
Reboot computer
Recheck eeprom settings in RH (still screwed up)
Import known-good eeprom settings in RH
Recheck eeprom settings in RH (still screwed up)

[Earthbound]

Got something worth trying. Don't know that it will fix your issue, but easy enough to give it a shot.

Clearly, you pushed some garbage in to the EEPROM. Running EEPROM Clear isn't helping. I took a look at eeprom_clear.ino and see that it only zeroes out the first 512 bytes. It was written (or last updated) when Arduinos only had 512 bytes of EEPROM. RAMBo uses more EEPROM than that.

I suggest opening the EEPROM Clear example sketch (as instructed in the manual) but before you upload it to the RAMBo, change the value on line 14 (the "for" loop) from 512 to 4096. ATMEGA2560 chip on the RAMBo has 4096 bytes of EEPROM. Upload the modified Clear sketch, then try loading Reptier 0.91 again.

Hope this does it.

[BenTheRighteous]

Earthbound - I think you're on to something, but unfortunately your suggestion didn't solve the problem. And to answer your previous question, I'm not getting any error messages when uploading. Just "Done uploading" as well as "Binary sketch size: 127,964 bytes (of a 258,048 byte maximum)"

Is it wrong to think that perhaps instead of using 512 or 4096 for the for loop, it should be 258048? Or is the EEPROM space separate from the firmware space? Along the same lines, what would happen if I made the number bigger than the amount of memory the RAMBo has? Could I just put 2^32 and be totally sure I'm blasting everything?

[BenTheRighteous]

I think I answered my own question, at least partially:

http://arduino.cc/en/Main/arduinoBoardMega2560

It says very clearly that EEPROM is 4k, flash memory is 256k, which would indicate that they are completely separate.

[jdurand]

Note to programmers:

Put your EEPROM structure version at the head of your EEPROM. On boot, check that it matches, if not zap and reload (or cleaner, read and update to new structure format).

To force a clear, simply zero the first byte and reboot.

(if it isn't obvious, I've been doing embedded stuff for mumble decades)

[Mac The Knife]

So, hitting the reset button wouldn't work either? Or is that the same function as hitting the reset button on the lcd panel?

[BenTheRighteous]

Here is my modified eeprom clear program:

Code: Select all

/*
 * EEPROM Clear
 *
 * Sets all of the bytes of the EEPROM to 0.
 * This example code is in the public domain.

 */

#include <EEPROM.h>

void setup()
{
  for (int i = 0; i < 5 ; i++) {
    digitalWrite(13, HIGH);
    delay(2000);
    digitalWrite(13, LOW);
    delay(2000);
  }
  // write a 0 to all 512 bytes of the EEPROM
  for (int i = 0; i < 4096; i++)
    EEPROM.write(i, 0);
    
  // turn the LED on when we're done
//  digitalWrite(13, HIGH);
  
  for (int i = 0 ; i < 100 ; i++) {
    digitalWrite(13, HIGH);
    delay(500);
    digitalWrite(13, LOW);
    delay(500);
  }
}

void loop()
{
}

I tweaked it a bit to flash the LED before and after the write, just so I could make sure the program was actually running. I can upload the firmware and see the LED flash slowly, then go dark for about 10-15 seconds, then flash quickly. (It's labeled LED1, near the USB connector, and is dim - but visible).

I watched that run, then re-uploaded the Repetier firmware. Still seeing the same problem.

[BenTheRighteous]

Mac... there is a reset button other than the one on the LCD panel? I'll try it... where is it?

EDIT: Found it, it just reboots the firmware.

[Mac The Knife]

I had hit that once while fiddling with the wiring,,,,, with the power off. After I fired it back up, I had to reload the firmware and had blamed that button. I guess it wasn't the cause.

[Earthbound]

Using MC or RH, can you edit any of the EEPROM values? If it appears to take the changes, close the program and re-open, see if new value stuck. I'm wondering if the EEPROM has gotten locked. If it seems to take changes, get a back-up copy of someone else's EEPROM and try importing it. I'd send you mine, but printer is in the middle of a job right now.

[BenTheRighteous]

I can change values and they do stick after closing and reopening RH. And as a matter of fact, I happen to have an eeprom backup as well! (How about that - a backup when you need it!)

Unfortunately, importing it doesn't fix the problem. I still get random wrong/blank rows. No clue what the problem could be. I'm starting to suspect a hardware failure. I have a hard time believing that such a simple misstep could cause something like this, but... here we are.

[BenTheRighteous]

Well, maybe it's not a hardware failure. I just loaded up the eeprom_read example sketch, tweaked it, and watched 4096 zeroes fly by. So that's what I was hoping for, but now I'm at a complete loss! If the eeprom can read/write no problem, then why isn't reuploading the firmware fixing my issue?! This is totally nuts.

[BenTheRighteous]

Not sure if this sheds any light, but the output of the M205 command seems messed up. Apparently M205 is what RH uses to dump the eeprom settings and load them into its fancy dialog.

Code: Select all

21:53:17.494 : EPR:3 108 87.860 Bed PID P-gain
21:53:17.494 : EPR:3 112 3.010 Bed PID I-gain
21:53:17.494 : EPR:3 116 641.820 Bed PID D-gain
21:53:17.494 : EPR:0 120 255 Bed PID max value [0-255]
21:53:17.504 : EPR:3 200 92.400 Extr.1 xtr.1 acceleraEPR:3 204 100.000 Extr.1 max. feedrate [mm/s]
21:53:17.504 : EPR3] 208 45.000 Extr.1 start feedrate [mm/s]
21:53:17.504 : EPR:3 212 6500.000 Extr.1 acceleration [mm/s^2]
21:53:17.504 : EPR:0 216 1 Extr.1 heat manager [0-3]
21:53:17.504 : EPR:0 217 205 Extr.1 PID drive max
21:53:17.514 : EPR:0 245 60 Extr.1 PID drive min
21:53:17.514 : EPR:3 218 31.3600 Extr.1 PID P-gain/dead-time
21:53:17.514 : EPRxtr.1 X-offset [steps]
21:53:17.514 : EPR:2 235 0R:3 226 112.9000 Extr.1 PID D:1 239 3 Extr.1 temp. str.1 PID max value [0-255]
21:53:17.514 : EPR:2 231 0 Extr.1 X-offset [steps]
21:53:17.514 : EPR:2 235 0 Extr.1 Y-offset [steps]
21:53:17.524 : EPR:1 239 3 Extr.1 temp. stabilize time [s]
21:53:17.524 : EPR:1 250 150 Extr.1 temp. for retraction when heating [C]
21:53:17.524 : EPR:1 252 0 Extr.1 distance to retract when heating [mm]
21:53:17.524 : EPR:0 254 255 Extr.1 extruder cooler speed [0-255]
21:53:17.524 : EPR:3 246 0.000 Extr.1 advance L [0=off]

Some of those lines are fine. And others are screwed up. There is no pattern that I can see - every time I run M205, the set of corrupt lines is different.

[jdurand]

Do these processors have any boot code or factory set values that could have been overwritten? Some have things like clock calibration and such and you can send yourself off in the weeds if you trash that.

[BenTheRighteous]

Alright, here's some progress: I installed the RAMBo drivers and Repetier Host on another laptop to test the issue with, and there was no problem! M205 works fine, eeprom settings in RH worked fine. So apparently my RAMBo is totally good (whew!), and the problem is on my laptop.

I've tried uninstalling and reinstalling everything I could think of - MatterControl, Repetier Host, and the RAMBo driver itself - but I can't seem to squash this trouble on this laptop. Can anyone suggest what the trouble might be?

[BenTheRighteous]

This probably shouldn't come as a surprise but I managed to coax PuTTY into talking directly to the COM5 port on my computer just so I could be sure this wasn't a RH/MC issue. (I only have the slightest idea of what I'm doing here btw, I'm shocked this worked at all). Lo and behold, the output of M205 is still randomly corrupt.

So, seems like we can rule out the printer itself, Repetier Host, Matter Control, and the USB cable being faulty - seems like this has got to be either A.) a driver issue, or B.) two threads talking to COM5 at the same time perhaps?

But if it's (A), why did this just happen today, and seem to be brought about by my pasting of a long number into the eeprom?
Then again, I don't even know if (B) is a possibility...

PuTTY output from M205:

Code: Select all

EPR:0 107 255 Bed PID drive max
EPR:0 124 80 Bed PID drive min
EPR:3 108 87.860 Bed PID P-gain
EPR:3 112 3.010 Bed PID I4 100.000 Extr.1 max. feedrate [mm/gain
EPR:0 120 255 Bed PID mtart feedrate [mm/s]
E 200 92.400 Extr.1 steps per mm
EPR:3 204 100.000 Extr.1 max. feedrate [mm/s]
EPR:3 208 45.000 Extr.1 start feedrate [mm/s]
EPR:3 212 6500.000 Extr.1 acceleration [mm/s^2]
 2.1800 Extr.1 PID I-gaID drive max3]
EPR:0 245 60 Extr.1 PID dri
                           EPR:0 230 :3 218 31.3600 Extr.1 PID P-gain/dead-time
EPR:3 222 2.1800 Extr.1 PID I-gain
EPR:3 226 112.9000 Extr.1 PID D-gain
EPR:0 230 255 Extr.1 PID max value [0-255]
EPR:2 231 0 Extr.1 X-offset [steps]
EPR:2 235 0 Extr.1 Y-offset [steps]
EPR:1 239 3 Extr.1 temp. stabilize time [s]
EPR:1 250 150 Extr.1 temp. for retraction when heating [C]
EPR:1 252 0 Extr.1 distance to retract when heating [mm]
EPR:0 254 255 Extr.1 extruder cooler speed [0-255]
EPR:3 246 0.000 Extr.1 advance L [0=off]

[BenTheRighteous]

Ok, I may - MAY - have fixed the problem.

I changed the baud rate in the eeprom from 250000 to 115200, and adjusted Repetier Host to match. Now, M205 returns perfectly and the eeprom dialog renders beautifully.

I'm definitely still confused why THIS is the [possible] solution, considering how this nonsense started.

[Earthbound]

It's possible your first pasted longgggggggg decimal corrupted the RAMBo. It shouldn't have. I would expect R-H to parse it correctly (and you've shown it didn't).

There are some configuration bytes that control the behavior of the ATMEGA MCU. One of them is the OSCAL (calibration for internal oscillator). The RAMBo uses an external oscillator so I don't know whether or not OSCAL matters. It takes a programming device (AVRISP or similar) to adjust those configuration bytes. If you have a buddy who does a lot with electronics, check with them. But it sounds like things work at full speed using the 2nd laptop, so problem could actually be on the 1st laptop and not with RAMbo.

[BenTheRighteous]

That's right - 2nd laptop works full speed at 250000 baud. For some reason, starting today, the 1st laptop doesn't work unless I scale it down. (I picked 115200 somewhat arbitrarily, it might work at a faster baud too but I'm happy not to break things again by tinkering.)

I have no idea whether the apparent cause and the apparent solution are actually related. It's a stretch. I'm following you when you describe the idea that I might've accidentally overwritten some important configuration bytes. But then why would the 2nd laptop work like a charm? It just doesn't add up.

One half of me says "we have to get to the bottom of this, try to reproduce it on the 2nd laptop!" but the other half of me says "NO FREAKING WAY, once bitten twice shy" so I think this one is just going to have to remain a mystery.

[BenTheRighteous]

BTW thanks for catching my calculation error much earlier. On the bright side, if I didn't have to sort all this out, I would've put that crappy steps_per_mm in the eeprom and who knows if I ever would've chased that one down again!

Thanks for all the ideas guys. This issue was definitely a head-scratcher...

[Earthbound]

The difference between the two laptops will be their own calibrations for timing. Could be that the RAMBo has been tweaked, and now has slightly non-standard timing. Tolerance for frequency error generally improves as baud rate decreases. One laptop handles it OK at higher baud than the other.

I tend to agree with the "set it to 155.2k and leave the rest well enough alone" theory of where to go next.

[geneb]

That's not how it works Earthbound.

It's likely that there may be something wrong with the USB controller on the laptop that's causing it to perform poorly at the 250000 baud rate.

g.