Marlin 🚀 - UBL Issue | bleepingcoder.com

Hey @bgort !!! I've been chasing this problem for 5 or 6 days. If you want to jump in and help it would be very much appreciated. Please turn on your M100_FREE_MEMORY_WATCHER option. That will let you verify this is happening. (It will give you access to the top_of_stack() function)

In your ubl_G29.cpp file, Add these lines of code right at the start of the function:

char* top_of_stack();
  void gcode_G29() {
  SERIAL_PROTOCOLLNPAIR("Start of G29     ", hex_word(top_of_stack()));
    if (ubl.eeprom_start < 0) {
      SERIAL_PROTOCOLLNPGM("?You need to enable your EEPROM and initialize it");
      SERIAL_PROTOCOLLNPGM("with M502, M500, M501 in that order.\n");
      return;
    }
  SERIAL_PROTOCOLLNPAIR("After accessing UBL object: ", hex_word(top_of_stack()) );

What I'm seeing is the stack pointer is in a normal position before UBL object is referenced. The stack pointer will be somewhere close to 0x2180. But after accessing the UBL object, the stack pointer has been corrupted and (in my case) is somewhere around 0x1cc0. Obviously, this is causing all kinds of problem. Important system values are stored there.

Can you see and/or verify if you see the stack pointer jump ?

Roxy-3D on 13 Apr 2017

Hey Roxy! Sure!

Here's what I have doing that:

*** snip ***
Recv: ok
Send: G29 P1
Recv: Start of G29; stack @ 8588
Recv: ubl.eeprom_start=64
Recv: After accessing UBL object; stack @ 8506
Recv: Mesh invalidated. Probing mesh.
Recv: 
Recv: d from 3rd point: -0.000000  c: -0.000000
*** (snipped a bunch of newlines here) ***
start
Recv: echo:Marlin 1.1.0-RCBugFix
Recv: 
Recv: echo: Last Updated: 2016-12-06 12:00 | Author: BG
Recv: Compiled: Apr 13 2017
Recv: echo: Free Memory: 1204  PlannerBufferBytes: 1296
Recv: echo:V34 stored settings retrieved (451 bytes)
Recv:  UBL not active!
*** snip ***

Stack is different.

I'll dig in a bit right after I get back from FedEx. Need to drop off a package.

bgort on 13 Apr 2017

What ever is wrong... It is something very small and simple. But right now, I can't figure it out!!!

Recv: Start of G29; stack @ 8588
Recv: ubl.eeprom_start=64
Recv: After accessing UBL object; stack @ 8506

Do you have the hex_word() around the top_of_stack() calls? I'm not sure things print in a reasonable manner without that. But it does appear like you are seeing the stack pointer shift in an unreasonable way.

@bgort Are you a GCC expert? I know GCC can produce .ii and .iii files with the C code intermixed with the assembly code the compiler produced. That would be very helpful right now. But I don't know how to get those files within an Arduino environment and especially not on Windows. Is this something you can figure out?

Roxy-3D on 13 Apr 2017

So hard to find sometimes... the little things.

Starting on it now. Hopefully something stands out - fresh eyes and all of that.

bgort on 13 Apr 2017

So hard to find sometimes... the little things.
Starting on it now. Hopefully something stands out - fresh eyes and all of that.

I've got some updates to M100 that I'm going to get cleaned up and put back up in the main branch. It is those that helped me narrow the scope to the very start of the G29 routine. I'll probably have that in place to assist you within an hour.

Roxy-3D on 13 Apr 2017

Ah, great!

bgort on 13 Apr 2017

Still not sure what's going on, but it has nothing to do with G29, I think.

After looking around for a bit, I decided to try this just to see what I could see:

  char *top_of_stack();
  extern char __bss_end;
  extern char __heap_start;
  extern void* __brkval;

  void gcode_G29() {
    int cnt=0;

    SERIAL_PROTOCOLLNPAIR("Start of G29; stack @ ", (unsigned int)top_of_stack());

    while(1) {
      SERIAL_PROTOCOLLNPAIR("G29 Loop ", ++cnt);
      SERIAL_PROTOCOLLNPAIR("Stack @ ", (unsigned int)top_of_stack());

      int free_memory;
      if ((int)__brkval == 0) free_memory = ((int)&free_memory) - ((int)&__bss_end);
      else free_memory = ((int)&free_memory) - ((int)__brkval);

      SERIAL_PROTOCOLLNPAIR("Free memory ", free_memory);

      delay(200);
    }

Here's the output:

Send: G29 P1
Recv: Start of G29; stack @ 8588
Recv: G29 Loop 1
Recv: Stack @ 8586
Recv: Free memory 1534
Recv: G29 Loop 2
Recv: Stack @ 8586
Recv: Free memory 1534
*** snip - all identical ***
Recv: G29 Loop 22
Recv: Stack @ 8586
Recv: Free memory 1534
Recv: G29 Loop 23
Recv: Stack @ 8586
Recv: Free memory 1534
*** crash after loop 23 ***
Recv: start
Recv: echo:Marlin 1.1.0-RCBugFix
Recv:

I've tried this numerous times -- always crashes at the same place - loop 23. As you can see, we're not even touching the UBL object/structure, so it's not likely anything to do with that. I don't see why this loop should ever crash, unless an interrupt fires and it crashes elsewhere?

Will continue to look, but thought I'd check in with that, at least.

bgort on 14 Apr 2017

@bgort and @thinkyhead Please take a look at: https://github.com/MarlinFirmware/Marlin/pull/6334

And if you add the lines of code shown to ubl_G29.cpp

void check_for_free_memory_corruption(char *);

void gcode_G29() {
  check_for_free_memory_corruption("G29 starting... ");
  SERIAL_PROTOCOLLNPAIR("ubl.eeprom_start=", ubl.eeprom_start);
  if (ubl.eeprom_start < 0) {
    SERIAL_PROTOCOLLNPGM("?You need to enable your EEPROM and initialize it");
    SERIAL_PROTOCOLLNPGM("with M502, M500, M501 in that order.\n");
    return;
  }
  check_for_free_memory_corruption("after accessing UBL object... ");

I believe you will get a lot of good information about what is happening. You should probably do a

M100 I
M100 F
G28
M100 F
G29
And at that point... The stack pointer is messed up!

Roxy-3D on 14 Apr 2017

Will check that out now.

Also, added my loop to G28 and it crashes in loop 23 there, too. So, nothing to do with G29. Unless I'm just barking up the wrong tree entirely.

bgort on 14 Apr 2017

Well... We are dealing with a memory corruption problem. So there is no telling what is at root cause. But having a way to reliably cause the problem is a big help. I've been over and over the UBL object class definition and I don't see a problem. I've changed all the linkage from static to 'normal'. I've moved stuff out of the class. Etc. Etc. The problem still keeps happening...

So if you are seeing it happen in G28, that is actually a good thing. It means that is getting impacted also. There is a chance this has nothing to do with UBL and UBL being sick is just a symptom.

Roxy-3D on 14 Apr 2017

So if you are seeing it happen in G28, that is actually a good thing. It means that is getting impacted also. There is a chance this has nothing to do with UBL and UBL being sick is just a symptom.

That's my opinion/belief, right now. It's not UBL -- UBL puking is just a symptom. Might be wrong, but ...

bgort on 14 Apr 2017

I've been over and over the UBL object class definition and I don't see a problem.

FWIW, I don't see a problem there, either.

bgort on 14 Apr 2017

I just compared our Configuratioh.h and Configuration_adv.h files. About the only thing we have similar is we both have BL-Touch probes. Other than that... most stuff is different. LCD Panels, End Stop Interrupts, Z-BabyStepping, Filament_Change_Sensor, etc... Our machines seem to only share the BL-Touch configuration.

I wonder if we should be look through any and all BL-Touch changes over the last 6 weeks????

One thing I can do is go back to my FolgerTech i3-2020 and see if I can make the problem show up there. That has a servo with a probe leg, but no BL-Touch. That might be an interesting data point.

UPDATE: The other thing I can do is undeclare the BL_Touch on my gMax and just set the correct servo angles. I would be giving up the error state detection and reset but it would be a very good counter positive test.

Roxy-3D on 14 Apr 2017

I wonder if we should be look through any and all BL-Touch changes over the last 6 weeks????

Makes sense to me...

End Stop Interrupts,

I didn't realize endstop interrupts were in RCBugFix; I didn't get all the way through the new Configuration.h -- pretty much just merged the new into the old, fixed the conflicts, and compiled. Neat! Looking forward to using that once this issue is sorted.

bgort on 14 Apr 2017

The major change because of the BLTouch was the "guaranteed detection" changes.

With endstop interrupts off then the stepper ISR is run at least every 2 mS. I'm running 200 steps per unit so if the feedrate is above 150mm/minute then the stepper ISR is running faster than 2mS.

If the endstop interrupts are on then the stepper ISR runs at it's normal rate and one extra ISR is run when an endstop is hit.

The other change was to call the stop() function when the BLTouch wouldn't come out of an error state. As best I can tell the stop function doesn't actually do anything until all the stepper movements have finished. There's some added long delays when doing the retries and trying to get the error message out.

I forced a WDT timeout but Marlin doesn't report why it went through reset.

Bob-the-Kuhn on 14 Apr 2017

Yeah, resetting the watchdog enables the loop I was testing with to run forever, so it seems it was just the wdt doing a reset. Sorry for not catching that sooner and for any sidetracking. Thanks, BtK.

Back to looking for the other problem...

bgort on 14 Apr 2017

FYI: I don't have an issue with doing a G29 P1 on this branch:
https://github.com/Tannoo/Marlin/tree/RGB_Printer_Events

There are now 7 merges that I have not assimilated into my branch (They are currently about 1 day old). Maybe this will help you guys.

Tannoo on 14 Apr 2017

I have UBL working now. Reducing the UBL grid points to 11 or fewer 'fixes' the crash/reset problem for me.

check_for_free_memory_corruption() still reports corrupted memory, but it seems to do that regardless of whether the ubl object is accessed/on the stack. I took a look at the positions of __heap_start, __brkval, the stack pointer, available memory, etc., and everything seems okay, generally.

Will go through check_for_free_memory_corruption() in a bit. Maybe something is off there?

bgort on 14 Apr 2017

@Tannoo I was looking for all those screen captures you posted. But I can't find them. Do you know where those got posted??? (I'm trying to create a few distinctly different branches!)

Roxy-3D on 14 Apr 2017

I have UBL working now. Reducing the UBL grid points to 11 or fewer 'fixes' the crash/reset problem for me.

I think I can confirm... I started with Tannoo's branch just because he said his was working and I started crossing over my settings. With a 10x10 grid it worked. When I bumped it up to 15x15 things got very sick. There should be enough memory for 15x15.

But one thing that did change is the name

  #define GRID_MAX_POINTS_X 15      // Don't use more than 15 points per axis, implementation limited.
  #define GRID_MAX_POINTS_Y 15      // Don't use more than 15 points per axis, implementation limited.

That was done to use common names across the various flavors of bed leveling. There might be some array definitions or something else that is doing the wrong thing with that change.

check_for_free_memory_corruption() still reports corrupted memory, but it seems to do that regardless of whether the ubl object is accessed/on the stack. I took a look at the positions of __heap_start, __brkval, the stack pointer, available memory, etc., and everything seems okay, generally.

Is the free area ending up as multiple blocks with 'noise' in the middle of it? If not, it probably is OK.

Will go through check_for_free_memory_corruption() in a bit. Maybe something is off there?

The check routine is not super fancy. Mostly, it is just doing two things. It is seeing if the free area is one big chunk and nothing has 'corrupted' the middle of it. The other thing it does is make sure the stack pointer is bigger than the end of the heap.

What exactly is the check complaining about on your system?

Mean while... I'm going to change ubl.z_values[][] to not be part of the ubl object. I'm just going to make it a global with a name of ubl_z_values[][]. That should change where everything gets located in memory. It will be interesting to see what that affects.

@bgort Hey!!! With the latest RCBugFix and the attached Configuration.h files... I'm running just fine with a 15x15 grid.

I did need to take care of some scope issues for the new Z-BabyStepping changing z_offset. I just plain turned it off for UBL at the moment. If you Cut & Paste this into ultra_lcd.cpp it is very possible your system will work at 15x15. I would appreciate it if you can compare your Configuration.h files with these... And let me know how good or bad things work for you!


    #if HAS_BED_PROBE
      #ifndef AUTO_BED_LEVELING_UBL

      void lcd_babystep_zoffset() {
        if (lcd_clicked) { defer_return_to_status = false; return lcd_goto_previous_menu(); }
        defer_return_to_status = true;
        ENCODER_DIRECTION_NORMAL();
        if (encoderPosition) {
          const int babystep_increment = (int32_t)encoderPosition * (BABYSTEP_MULTIPLICATOR);
          encoderPosition = 0;

          const float new_zoffset = zprobe_zoffset + steps_to_mm[Z_AXIS] * babystep_increment;
          if (WITHIN(new_zoffset, Z_PROBE_OFFSET_RANGE_MIN, Z_PROBE_OFFSET_RANGE_MAX)) {

            if (planner.abl_enabled)
              thermalManager.babystep_axis(Z_AXIS, babystep_increment);

            zprobe_zoffset = new_zoffset;
            refresh_zprobe_zoffset(true);
            lcdDrawUpdate = LCDVIEW_REDRAW_NOW;
          }
        }
        if (lcdDrawUpdate)
          lcd_implementation_drawedit(PSTR(MSG_ZPROBE_ZOFFSET), ftostr43sign(zprobe_zoffset));
      }
      #else
        void _lcd_babystep_z() { _lcd_babystep(Z_AXIS, PSTR(MSG_BABYSTEPPING_Z)); }
        void lcd_babystep_z() { lcd_goto_screen(_lcd_babystep_z); babysteps_done = 0; defer_return_to_status = true; }
      #endif
    #else // !HAS_BED_PROBE
      void _lcd_babystep_z() { _lcd_babystep(Z_AXIS, PSTR(MSG_BABYSTEPPING_Z)); }
      void lcd_babystep_z() { lcd_goto_screen(_lcd_babystep_z); babysteps_done = 0; defer_return_to_status = true; }
    #endif // HAS_BED_PROBE
  #endif //BABYSTEPPING

Configuration_adv-h.txt
Configuration-h.txt

Roxy-3D on 15 Apr 2017

I was looking for all those screen captures you posted. But I can't find them. Do you know where those got posted??? (I'm trying to create a few distinctly different branches!)

For the bed topography? --> #6105
Or the Git desktop operations? Can't find the post, but here are the captures:
https://drive.google.com/open?id=0B560i8PeUNErTjk0Vk11cHFtaGM

Tannoo on 15 Apr 2017

Or the Git desktop operations? Can't find the post, but here are the captures:

YES!!! The Git DeskTop steps to create a branch!!! I kind of have it doing the right thing. But it seems like any time I try to create a new branch it kills (re-uses) the directory the previous branch was in.

Roxy-3D on 15 Apr 2017

Yes, it does that. If I want to save that branch locally, I just copy that directory somewhere else before I switch the branch.
I only creates new directories for different repos. Not branches of the same repo.

Tannoo on 15 Apr 2017

Yes, it does that. If I want to save that branch, I just copy that directory somewhere else before I switch the branch.

Question: If I decide to 'commit' all my changes to the branch, do I need to copy that directory off somewhere? The next time I switch to that branch, it will hammer everything in that directory back to what I committed, right?

Roxy-3D on 15 Apr 2017

After committing to a branch....click the sync button to "upload" them to your Git repo.

You can then switch to another branch. When you switch back to the previous branch, your commits that were sync'ed, will be there.

Tannoo on 15 Apr 2017

do I need to copy that directory off somewhere?

Only if you want to keep a local copy.

Tannoo on 15 Apr 2017

The next time I switch to that branch, it will hammer everything in that directory back to what I committed, right?

Only if you had SYNC'ed first.

In Git Desktop,
Submitting a commit only commits it to the local copy of that branch. Sync it before you switch to another branch. Or those local commits will be lost.

Tannoo on 15 Apr 2017

@Roxy-3D, what was that G29 command to get the least square fit?

Tannoo on 15 Apr 2017

@Roxy-3D, what was that G29 command to get the least square fit?

It was G29 G 3 to do a 3 x 3 Grid probe... But there is too much push back on using a 'Magic Letter' like G for Grid. So now the command is 'J'. But it isn't done yet. I got side tracked with that data corruption problem. If that is behind me... In the next couple of days I'll get the least square fit of the grid going to tilt your mesh.

For now... If you want to tilt your mesh, you have to use the 3-Point version to do it. That is G29 T

Roxy-3D on 15 Apr 2017

Ok.

Tannoo on 15 Apr 2017

@Roxy-3D UBL is really incredible, Roxy. Finally had time to finish setting it up, and I'm very impressed.

Right out of the gate (first test):
2017-04-15 13 43 44
(ignore the missing circle in the corner -- I did that after it was finished -- printed perfectly)

To say that I'm thrilled is an understatement.... Great, great work.

Will take a look at the M100-related routines here shortly.

bgort on 15 Apr 2017

@bgort Hey!!! With the latest RCBugFix and the attached Configuration.h files... I'm running just fine with a 15x15 grid.

Awesome! I'll try it in a few minutes!

bgort on 15 Apr 2017

@bgort Hey!!! With the latest RCBugFix and the attached Configuration.h files... I'm running just fine with a 15x15 grid.

Awesome! I'll try it in a few minutes!

Actually... That was with yesterday's files... Today, the data corruption is back. I would appreciate any help you can offer to find the problem!

But Thank You for the comments! :)

Roxy-3D on 15 Apr 2017

Actually... That was with yesterday's files... Today, the data corruption is back. I would appreciate any help you can offer to find the problem!

I was just looking through your configs and the recent changes to see what might be responsible, but wasn't coming up with anything. FWIW, I do think the idea to remove the z_values from the ubl object is a good one.

bgort on 15 Apr 2017

I found this thread looking on google, As Im also having the same problem as the OP. It will do G28 and G29 will be skipped. Doing so in Pronterface will read out this error
ubl.eeprom_start=-1
?You need to enable your EEPROM and initialize it
with M502, M500, M501 in that order.

EEPROM is enable. Also my latest RC8 fix I download it yesterday late at 11pm. I also running a BlTouch.

Rhonal89 on 15 Apr 2017

That problem is because UBL is detecting the state structure is incoherent. If you do the M502, M500, M501 and reset... It should go away.

Roxy-3D on 15 Apr 2017

The latest is actually working w/a 15x15 here. Populating the z_values matrix now. I haven't yet applied the ultra_lcd changes you suggested above.

If you haven't already started, I can move z_values out of the ubl object? Looks pretty straight forward.

bgort on 15 Apr 2017

@bgort

UBL is really incredible, Roxy. Finally had time to finish setting it up, and I'm very impressed.
Right out of the gate (first test):
(ignore the missing circle in the corner -- I did that after it was finished -- printed perfectly)
To say that I'm thrilled is an understatement.... Great, great work.

You needed to use the Interactive Mesh Editor to get the validation pattern to print that nice, right? How many iterations of G26 and G29 P4's did it take to get your mesh that nice?

Can you be talked into posting your mesh? I'm curious what types of imperfections people are fighting. I went to the Dollar store to get the absolute worst piece of glass I could find just so the system would be stressed.

Will take a look at the M100-related routines here shortly.

I'm gearing up to take another run at the data corruption. Like I say... Any help would be hugely appreciated!

Roxy-3D on 15 Apr 2017

You needed to use the Interactive Mesh Editor to get the validation pattern to print that nice, right?

No, this is directly after G29 P1, then G29 P2 B to fill in gaps (only had 11 it couldn't get).

Can you be talked into posting your mesh? I'm curious what types of imperfections people are fighting. I went to the Dollar store to get the absolute worst piece of glass I could find just so the system would be stressed.

I'm pretty flat, so there wasn't much stress.

Here's my mesh:

Recv: Bed Topography Report:
Recv: 
Recv: (0,10)                                                                                                                (10,10)
Recv: (0,0)                                                                                                            (237,308)
Recv:  -0.091   -0.087   -0.113   -0.086   -0.153   -0.174   -0.156   -0.175   -0.164   -0.199   -0.210
Recv: 
Recv:  -0.069   -0.056   -0.061   -0.093   -0.113   -0.084   -0.095   -0.140   -0.143   -0.163   -0.160
Recv: 
Recv:  -0.035   -0.045    0.011   -0.054   -0.039   -0.049   -0.075   -0.069   -0.099   -0.099   -0.089
Recv: 
Recv:   0.006   -0.003   -0.011    0.011   -0.003   -0.036   -0.038   -0.040   -0.065   -0.060   -0.053
Recv: 
Recv:   0.022    0.021    0.019    0.012    0.022   -0.009   -0.004   -0.005   -0.006   -0.030   -0.013
Recv: 
Recv:   0.017    0.044    0.011    0.024    0.000    0.001    0.011    0.002   -0.018   -0.028   -0.024
Recv: 
Recv:   0.045    0.015    0.029   -0.006    0.039    0.035    0.024    0.026    0.035   -0.008   -0.009
Recv: 
Recv:   0.026    0.055    0.019   -0.015    0.022    0.004    0.029    0.011    0.004    0.009    0.017
Recv: 
Recv:  -0.021   -0.035   -0.029   -0.031   -0.041   -0.036   -0.053   -0.024   -0.029   -0.024    0.001
Recv: 
Recv:  -0.034   -0.014   -0.059   -0.059   -0.058   -0.048   -0.060   -0.044   -0.051   -0.044   -0.023
Recv: 
Recv: [-0.090]  -0.050   -0.040   -0.050   -0.060   -0.020   -0.050   -0.050   -0.040   -0.020    0.010
Recv: (0,0)                                                                                                                (237,0)
Recv: (0,0)                                                                                                                   (10,0)
Recv: ok

bgort on 15 Apr 2017

Wow! That is very good!

Roxy-3D on 15 Apr 2017

I'm pretty happy with it. It's flattened K100S (cast/tooling aluminum) with a sheet of PEI. Not quite the flattening I paid for (supposed to be +/- 0.001" - 25.4um), but so much better than what I had before.

bgort on 15 Apr 2017

15x15 seems to be working fine here now:

Recv: Bed Topography Report:
Recv: 
Recv: (0,14)                                                                                                                                                                (14,14)
Recv: (0,0)                                                                                                                                                            (237,308)
Recv: [-0.021]  -0.023   -0.020   -0.024   -0.033   -0.104   -0.111   -0.086   -0.105   -0.141   -0.153   -0.163   -0.179   -0.170   -0.166
Recv: 
Recv:  -0.024    0.002   -0.026   -0.039   -0.019   -0.048   -0.076   -0.075   -0.093   -0.095   -0.121   -0.139   -0.129   -0.115   -0.124
Recv: 
Recv:   0.034    0.015    0.017    0.007   -0.034    0.025   -0.045   -0.074   -0.036   -0.066   -0.077   -0.031   -0.075   -0.064   -0.081
Recv: 
Recv:   0.031    0.048    0.040    0.045    0.046   -0.004   -0.024   -0.035    0.026   -0.061   -0.071   -0.055   -0.046   -0.048   -0.020
Recv: 
Recv:   0.101    0.089    0.060    0.029    0.071    0.043    0.024    0.014    0.019    0.017    0.005   -0.003   -0.013   -0.043   -0.001
Recv: 
Recv:   0.092    0.092    0.059    0.095    0.044    0.072    0.039    0.030    0.085    0.076    0.077    0.021    0.027    0.009    0.005
Recv: 
Recv:   0.086    0.056    0.086    0.040    0.076    0.104    0.065   -0.001    0.056    0.054   -0.008    0.072    0.065    0.020    0.027
Recv: 
Recv:   0.087    0.061    0.074    0.087    0.051    0.086    0.063    0.064    0.063    0.029    0.037    0.020   -0.004    0.071    0.036
Recv: 
Recv:   0.045    0.069    0.032    0.079    0.059    0.029    0.079    0.094    0.061    0.082    0.045    0.058    0.039    0.087    0.060
Recv: 
Recv:   0.061    0.089    0.035    0.101    0.069    0.053    0.079    0.096    0.087    0.102    0.060    0.060    0.075    0.075    0.094
Recv: 
Recv:   0.044    0.067    0.061    0.095    0.034    0.075    0.037    0.051    0.040    0.048    0.049    0.051    0.051    0.074    0.080
Recv: 
Recv:   0.009    0.025    0.027   -0.008    0.044    0.012    0.050    0.017   -0.006    0.014    0.021    0.021    0.020    0.049    0.056
Recv: 
Recv:   0.020    0.004    0.019    0.009   -0.021    0.058    0.000   -0.040    0.019    0.050    0.061    0.009    0.020    0.019    0.026
Recv: 
Recv:  -0.040   -0.010   -0.040   -0.020   -0.020   -0.030   -0.010    0.000   -0.010   -0.010   -0.020    0.020   -0.010   -0.010    0.030
Recv: 
Recv:  -0.070   -0.070   -0.020   -0.040   -0.010   -0.050   -0.010   -0.020   -0.020   -0.020    0.010   -0.010    0.000    0.020    0.020
Recv: (0,0)                                                                                                                                                                (237,0)
Recv: (0,0)                                                                                                                                                                   (14,0)

2017-04-15 16 27 51

Only a few little bad spots that I need to sort out how to fix. (I ruined the corner removing the prime blob, again.)

bgort on 15 Apr 2017

Only a few little bad spots that I need to sort out how to fix.

Just move the nozzle over the area that needs adjustment, and give it a G29 P4 R And when you have edited all the problem mesh points... Press and hold the Encoder Wheel and move the nozzle to the next area.

Don't forget to save the updated mesh! And you can save it in a new location to keep the old one as a backup.

Roxy-3D on 15 Apr 2017

Hey Roxy, Thanks for the help earlier. Now I'm wondering how you activate the mesh after G28 so it can be use.

Rhonal89 on 16 Apr 2017

Assuming you have the mesh loaded you want to use, you just do a G29 A
And you can combine commands. You can load and activate a mesh with G29 L1 A
And if you have a mesh you like to use, you can activate it, and then save it with G29 S 1
The system will automatically load and restore the state of the last saved mesh.

Roxy-3D on 16 Apr 2017

Still not finding anything wrt the memory issue.

Did find a small issue with ubl_state padding, however: https://github.com/MarlinFirmware/Marlin/pull/6361

bgort on 16 Apr 2017

I have encounter a problem. I have it set to 15 points and do get the low memory available, stability problem may occur. So something happen when doing the mesh leveling. I have hotend and bed cooled, and I notice I was getting error:printer halted, kill () called! . So switch back to 10 points and I was able to complete the mesh probing. So I try 15 points again and was getting the same error. But I did not know what was causing it, so this time I tried it again and pay attention. So I was looking at the LCD and the hotend got set automatically to heat up to 500c and bed to 80c . I shut it down and soon as I notice the temp was around 225 it was hot. I had not told the printer to heat, it was just doing mesh leveling cold.

Rhonal89 on 16 Apr 2017

Yeah... I've seen that too. The temperature object got its data corrupted. It was just trying to do what it remembered it was supposed to do.

Roxy-3D on 16 Apr 2017

So is not my printer acting up. I have checked wiring and everything looks great. Only time I seen the error is switching to 15 points from 10. Don't know if is because 15 point probing takes longer than 10 points probing that it starts heating up and kills the heating to prevent over temp.

Rhonal89 on 16 Apr 2017

So I found lots of thread about this problem and to correct my values, I had no be temp set and Hotend started to heat to 500c and bed was actually -80c automatically in the middle of 15 point mesh leveling. I have not notice this with 10 point with the time I ran it today. Every time I run 15 point mesh it kills the action.

Rhonal89 on 16 Apr 2017

Only time I seen the error is switching to 15 points from 10. Don't know if is because 15 point probing takes longer than 10 points probing that it starts heating up and kills the heating to prevent over temp.

No. 15x15 is a much bigger memory footprint than 10x10. It is moving some other critical data (like what the hotends and bed temperatures are supposed to be) into the target area for what ever is causing this data corruption.

My bet is if you switch bed leveling schemes and increase the Bi-Linear mesh size to 15x15 and add in some of the BILINEAR_SUBDIVISIONS, You are going to see other (similar) random things happen.

Roxy-3D on 16 Apr 2017

Is the 15x15 ubl stepping on the memory locations of the tempuratures?

Tannoo on 16 Apr 2017

Have you tried a 14x14?

Tannoo on 16 Apr 2017

Will try in the AM. Hoping we can figure this out. Love the work everyone does. Especially Roxy that has been helping me since 2014.

Rhonal89 on 16 Apr 2017

Is the 15x15 ubl stepping on the memory locations of the tempuratures?

I don't think so. But 15 x 15 is big enough it is pushing critical pieces of data (like hotend target temperatures) into the blast zone. I think it is random what gets hit with corruption. I've seen the serial communication buffers get hit with 'noise'.

Roxy-3D on 16 Apr 2017

Random thought here: If we stored the z_values as microns of deviation from zero as signed 16-bit integers we'd save roughly half the memory vs. floats. I'm not sure yet how the mesh/z correction is calculated or applied, but suspect there might be a few cycles worth of extra math if we did this?

Anyway, not sure if this idea is practical or not (or if it's already been considered), but would probably solve the memory issue by simply reducing usage.

bgort on 18 Apr 2017

Anyway, not sure if this idea is practical or not (or if it's already been considered), but would probably solve the memory issue by simply reducing usage.

Yes. I agree. But finding the reason memory is getting corrupted is the 'Best Answer' from a Marlin Stability perspective. I am getting more and more convinced UBL isn't doing this. But it enables what ever is causing the corruption. I guess we won't know that is true until we find the root cause.

But back to your idea. I'm not sure we even need 2 byte integers. A signed char would give us +/- 1.28 mm of displacement from a 'Perfect 0.000 mm' mesh. And having .01 mm of granularity (or accuracy) on each mesh point is probably fine for today's printers.

The extra math is not that bad. Depending on how the Z-Correction factor stuff is coded, it may be we can even do the Bi-Linear interpolation using integer math. But at worst case, using brute force, we would cast the four corners of the mesh cell to (float), do the math, and then multiply by .01 at the end (in the signed char case) to get rid of the extra two digits.

With some creeping elegance... It could be user selectable whether they used a 1 byte or 2 byte number for each mesh point value. If their bed was flat enough that it could be represented with 1 byte mesh points, that would be fine. But if they enabled the 2 byte mesh points each mesh point could correct up to +/- 32.767mm and that would give .001mm accuracy. Probably, if any of the mesh tilting schemes were turned on (like 3-point or grid) you would want the 2 byte values because otherwise you would be in danger of overflowing...

Do you feel like doing some coding????

Roxy-3D on 18 Apr 2017

But finding the reason memory is getting corrupted is the 'Best Answer' from a Marlin Stability perspective. I am getting more and more convinced UBL isn't doing this. But it enables what ever is causing the corruption. I guess we won't know that is true until we find the root cause.

Oh, I agree. Best to find and fix whatever the real issue is, if at all possible. Mostly just thinking out loud about ways to save memory and work around the problem, if it ends up being necessary.

I'm still not coming up with anything. I've looked at the stack, heap, and all of the other relevant addresses; inside G29 there -shouldn't- be an issue. There's plenty of space between the heap and stack for the ubl object.

FWIW, I still don't think there's anything wrong with UBL; seems this is just a memory-related issue. Doesn't seem there's exhaustion or a stack-heap collision, but I don't know what the other possibilities would be. The compiler is happy with everything, visual inspection yields nothing, etc. That leaves a runtime issue, and the only runtime issue that makes any sense at all is 'inappropriate' allocation of memory.

What's really weird is that it seems to occur semi-randomly. I know there's a debugger for Arduino out there, though I've never tried it; have you? Not sure if it'd work with Marlin or even could help with a problem like this.

But back to your idea. I'm not sure we even need 2 byte integers. A signed char would give us +/- 1.28 mm of displacement from a 'Perfect 0.000 mm' mesh. And having .01 mm of granularity (or accuracy) on each mesh point is probably fine for today's printers.

I agree. I was thinking micron precision would be ideal and so the 16-bit int was best, but you're right that it really isn't necessary; 8 bits would be enough for most use cases.

bgort on 18 Apr 2017

I'm still not coming up with anything. I've looked at the stack, heap, and all of the other relevant addresses; inside G29 there -shouldn't- be an issue. There's plenty of space between the heap and stack for the ubl object.

@thinkyhead showed me how to get both the symbol table and a disassembly of all the code. Did you know about this: https://github.com/MarlinFirmware/Marlin/pull/6354#issuecomment-294700312

With that... We can get the exact location of everything in the firmware image. And see the disassembled code. So now, if I can get another bogus stack frame to show up in the middle of the free memory area or in the communication buffers... It might be possible to unwind the stack and see what was going on...

FWIW, I still don't think there's anything wrong with UBL; seems this is just a memory-related issue. Doesn't seem there's exhaustion or a stack-heap collision, but I don't know what the other possibilities would be. The compiler is happy with everything, visual inspection yields nothing, etc. That leaves a runtime issue, and the only runtime issue that makes any sense at all is 'inappropriate' allocation of memory.

I agree... It isn't UBL, but UBL is moving things around enough in memory that we are seeing the problem. Actually... Looking at the link map and symbol table... I'm wondering if it is something else. At the front of the link map you will see:

SYMBOL TABLE:
00800200 l    d  .data  00000000 .data
00000000 l    d  .text  00000000 .text
0080036c l    d  .bss   00000000 .bss
00000000 l    d  .comment   00000000 .comment
00000000 l    d  .note.gnu.avr.deviceinfo   00000000 .note.gnu.avr.deviceinfo
00000000 l    d  .debug_aranges 00000000 .debug_aranges
00000000 l    d  .debug_info    00000000 .debug_info
00000000 l    d  .debug_abbrev  00000000 .debug_abbrev
00000000 l    d  .debug_line    00000000 .debug_line
00000000 l    d  .debug_frame   00000000 .debug_frame
00000000 l    d  .debug_str 00000000 .debug_str
00000000 l    d  .debug_loc 00000000 .debug_loc
00000000 l    d  .debug_ranges  00000000 .debug_ranges
00000000 l    df *ABS*  00000000 
0000003e l       *ABS*  00000000 __SP_H__
0000003d l       *ABS*  00000000 __SP_L__
0000003f l       *ABS*  00000000 __SREG__
0000003b l       *ABS*  00000000 __RAMPZ__
00000000 l       *ABS*  00000000 __tmp_reg__
00000001 l       *ABS*  00000000 __zero_reg__
00800204 l     O .data  00000001 soft_endstops_enabled
000001f8 l     O .text  0000001b _ZZ27prepare_move_to_destinationvE3__c
000001d9 l     O .text  0000001f _ZZ27prepare_move_to_destinationvE3__c_0

I know for a fact, the Stack Pointer is getting changed. How can that happen? Well, look at address 0x3e and 0x3d of the link map. Is the stack pointer not really an internal register on the AVR? Is it stored in memory? If so... A bad pointer might be writing over stuff near NULL (0x00000) and hammering the Stack Pointer. And that would explain everything else we have been seeing.

What's really weird is that it seems to occur semi-randomly. I know there's a debugger for Arduino out there, though I've never tried it; have you? Not sure if it'd work with Marlin or even could help with a problem like this.

I would love to have an In Circuit Emulator. I know Atmel sells one. And you can buy a little USB gizmo on eBay to use with it. http://www.ebay.com/itm/AVR-JTAG-USB-emulator-Debugger-download-AVR-JTAG-ICE-Download-Programmer-atmega/152209769313?_trksid=p2047675.c100005.m1851&_trkparms=aid%3D2220072%26algo%3DSIC.MBE%26ao%3D2%26asc%3D41811%26meid%3D9b9010ca55224b31b10d6383d87003da%26pid%3D100005%26rk%3D1%26rkt%3D6%26sd%3D371919571425 It shows a CD also for $8!

Here is one for $3.00 but no CD: http://www.ebay.com/itm/AVR-JTAG-AVR-USB-Emulator-Simulator-Debugger-Programmer-JTAG-ICE-for-Atmel-/371919571425?hash=item56982249e1:g:gFEAAOSwmgJY7~UI

I wonder if these have everything to do In Circuit Debugging? I'm not sure what has to be done to use one on an Atmega board, but it sure would be nice to have a hardware debugger running!

Roxy-3D on 18 Apr 2017

@thinkyhead showed me how to get both the symbol table and a disassembly of all the code. Did you know about this: #6354 (comment)

No, I hadn't seen that and didn't know about it. Will review now. Looks really cool. Thanks!

I would love to have an In Circuit Emulator. I know Atmel sells one. And you can buy a little USB gizmo on eBay to use with it. http://www.ebay.com/itm/AVR-JTAG-USB-emulator-Debugger-download-AVR-JTAG-ICE-Download-Programmer-atmega/152209769313?_trksid=p2047675.c100005.m1851&_trkparms=aid%3D2220072%26algo%3DSIC.MBE%26ao%3D2%26asc%3D41811%26meid%3D9b9010ca55224b31b10d6383d87003da%26pid%3D100005%26rk%3D1%26rkt%3D6%26sd%3D371919571425

It shows a CD also for $8! Here is one for $3.00 but no CD: http://www.ebay.com/itm/AVR-JTAG-AVR-USB-Emulator-Simulator-Debugger-Programmer-JTAG-ICE-for-Atmel-/371919571425?hash=item56982249e1:g:gFEAAOSwmgJY7~UI

I wonder if these have everything to do In Circuit Debugging? I'm not sure what has to be done to use one on an Atmega board, but it sure would be nice to have a hardware debugger running!

I've just spent the last 20 minutes looking at the various ICE/debuggers and may very well pick up the ATMEL ICE -- I need to be able to debug/program Cortex MCUs for an upcoming project, anyway, and it seems to do almost everything. EDIT: Annnd.. I just ordered one.

bgort on 18 Apr 2017

I've just spent the last 20 minutes looking at the various ICE/debuggers and may very well pick up the JTAG ICE -- I need to be able to debug/program Cortex MCUs for an upcoming project, anyway, and it seems to do almost everything.

Even if I have to solder wires onto the Atmega-2560 board... I don't care! I'll do it! But it would be very helpful to have a check list saying:

Buy this adapter off of eBay
download and install this software
solder these wires to a connector and make it look like this.
change your Arduino options to add GDB info by doing this...
etc.

Roxy-3D on 18 Apr 2017

Even if I have to solder wires onto the Atmega-2560 board... I don't care! I'll do it!

Yeah -- investigating now.

Decent threads:

But it would be very helpful to have a check list saying: ...

I agree, that would be great. I'll post here about what I learn and hopefully we can cobble something together.

bgort on 18 Apr 2017

Looks like these are the pins required for JTAG on the 2560:

TDO - PF6 (A6 in Arduino-speak)
TCK - PF4 (A4)
TDI - PF7 (A7)
TMS - PF5 (A5)
Vsense (+5V) & GND

2560 pinmap: https://www.arduino.cc/en/uploads/Hacking/PinMap2560big.png

Pretty sure all of these are free on my RAMBo and have headers; guessing I'll only need to rig up a connector/cable/adapter. Will post step-by-step here.

RAMBo pin mapping: http://reprap.org/wiki/Rambo_development

bgort on 18 Apr 2017

You have A7 listed twice... And I can't find A7 even once on the RAMPS v1.4 board. Maybe the ICE pig tail will have to be soldered to the Atmega-2560 board? (But A4 and A5 are easily available on the RAMPS v1.4 board!)

Roxy-3D on 18 Apr 2017

Sorry about that -- I typo'd and corrected it. PF6 = A6, PF7 = A7.

bgort on 18 Apr 2017

Looking at the schematic, I see A6 and A7 used for Y-STEP and Y-DIR? Bummer.

http://reprap.org/mediawiki/images/f/f6/RAMPS1.4schematic.png

bgort on 18 Apr 2017

A6 is Y-Step and A7 is Y-Dir. So... Those signals would have to be remapped to some other pins and the RAMPS Pin file changed to make them work. But very do-able!!!! It would be cleaner if those signals were on unused pins... But still.... To get a hardware debugger going would be great!

One idea would be to just unplug the Y-Axis step stick and map the Y-Axis movement to the 2nd extruder. Doing that would cut out a lot of soldering....

(Obviously... we are thinking the same thing!)

Roxy-3D on 18 Apr 2017

One idea would be to just unplug the Y-Axis step stick and map the Y-Axis movement to the 2nd extruder. Doing that would cut out a lot of soldering....

That's what I was thinking -- if you aren't using the second extruder, just remap Y to it. Problem solved, more or less.

bgort on 18 Apr 2017

I wish you were using an Atmega-2560 with a RAMPS board. That way we could bring up identical systems.

Roxy-3D on 18 Apr 2017

RAMBo is an Atmega2560. We'll be running pretty similar setups - just connected to different pins.

bgort on 18 Apr 2017

I have this laying here.. using it to build a cartesian robot to position a spectrophotometer. Hopefully be starting on it in a week or so. Just need to finish the design.

https://www.amazon.com/gp/product/B01FVTQQ2K

Pretty close to what you're using, I imagine?

bgort on 18 Apr 2017

RAMBo is an Atmega2560. We'll be running pretty similar setups - just connected to different pins.

Oh, I see. RAMPS is an addon board for the Mega2560. Pardon my ignorance!

bgort on 18 Apr 2017

Yeah... The RAMPS board plugs in on top of the Atmega-2560 processor board. And then all the little step stick boards and the LCD Interface board plug into the RAMPS board. But electrically... we won't be that different. And I suspect it will be clear if the USB-AVR-ICE gizmo is able to interface the debugging software to the processor chip.

Roxy-3D on 18 Apr 2017

Yeah, electrically we should be really similar -- more or less identical if you can pull the Y stepper driver board entirely. Then you just need a pigtail/cable assembly.

I ordered mine from Mouser so it should be here later in the week I imagine.. probably Thurs. or Fri. They're usually pretty fast.

bgort on 18 Apr 2017

What exactly did you order? If it wasn't a lot more than what is available on eBay... I'll order the same thing.

Roxy-3D on 18 Apr 2017

http://www.mouser.com/Search/ProductDetail.aspx?qs=KLFHFgXTQiDAUrt43H15kQ%3D%3D

It is quite a bit more, but I need the Cortex debugging capability in the future and it looks like a well designed unit, so it was worth it to me.

Actually, if you want one I can PayPal the money for it -- your work on UBL and on Marlin generally has been really helpful to me. Happy to contribute to what you're doing.

Let me know if that's of interest -- would just need a PayPal email address or some way to get the money to you.

bgort on 18 Apr 2017

I think I can get by with the eBay USB gizmo! But thanks for offering!

Assuming we can get the hardware interface going... (And it does look like that is not too hard to understand and accomplish...) The next question is what software to use. In the Arduino directory there are two programs. There is Arduino.exe which we all know what it does. But there is also a Arduino_debug.exe program. That maybe something we care about.

But also... JustAnother1 recommended to take a look at: http://openocd.org/ That might be a good host program for the debugging. Ideally... We end up with something that has the full symbol table and the ability to set break points on the access (execution, read, or write) to a specified memory location. With that... Things would be so much simpler.

Roxy-3D on 18 Apr 2017

No problem!

Right now I use platformio on an RPi3 for compile & flash.

I was planning on using Atmel Studio for this, but openocd looks interesting. Not sure if it'll work with what I just bought, though. EDIT: It does.

Which are you going to get on eBay?

bgort on 18 Apr 2017

It looks like all of the USB gizmo's are very similar. I was thinking of getting the one with the CD but it doesn't say it supports the Atmega-2560 processor. My guess is it does support it. But because of that, I'm just going to get one of the other ones. And I think that CD just has Atmel Studio v. 4 on it. If so... The CD doesn't really have any value anyway.

Roxy-3D on 18 Apr 2017

Gotcha. If you think having similar debugger/ICE setups would help, let me know which you end up with and I'll pick one up too (as long as it's not terribly expensive).

bgort on 18 Apr 2017

I am currently bidding on an auction that ends in 25 minutes. But this is the same one as what I hope to 'Win'. www.ebay.com/itm/AVR-JTAG-AVR-USB-Emulator-Simulator-Debugger-Programmer-JTAG-ICE-for-Atmel-/121325165606?hash=item1c3f8b1c26:g:HmUAAOSwrklVEOWL for $6.00

I'll let you know if I 'Win' the auction! And who knows they may put another one up so you can get it for $3.00 ! Oh! They already have another one up for auction at $3.00 Check out:

http://www.ebay.com/itm/AVR-JTAG-AVR-USB-Emulator-Simulator-Debugger-Programmer-JTAG-ICE-for-Atmel/352032621803?_trksid=p2047675.c100005.m1851&_trkparms=aid%3D222007%26algo%3DSIC.MBE%26ao%3D2%26asc%3D41811%26meid%3D0c9632f6a89e4317adcf8e562f0c64b6%26pid%3D100005%26rk%3D2%26rkt%3D6%26sd%3D371919571425

Roxy-3D on 18 Apr 2017

A little concerned with the only review that says it doesn't work. Not sure if that's legit or not, but I've been burnt by Chinese goods so many times....

bgort on 18 Apr 2017

A little concerned with the only review that says it doesn't work. Not sure if that's legit or not, but I've been burnt by Chinese goods so many times....

Yeah... I hear you!!!! But... it looks like there are 3 different USB gizmo designs on eBay where you can see the chips. They all have 2 crystals. And they all have a square flat pack with other chips on the board. My guess is Atmel did a 'Reference Design' and that is what these knock off China companies are selling.

Of course, I don't know that... But on the auction I'm bidding on it says 137 sold. 1 review saying "I didn't get it to work." and we already know we need to move the step sticks on the RAMPS board is actually kind of comforting... And... As long as somebody doesn't bid higher... I can afford $3.00 to see if it works! :)

Roxy-3D on 18 Apr 2017

Yep, I hear you! I'm just paranoid because I'm currently dealing with a return on items I bought from there. They're all suspect now...

$3 isn't much of a gamble! 👍

bgort on 18 Apr 2017

Yep, I hear you! I'm just paranoid because I'm currently dealing with a return on items I bought from there. They're all suspect now...

Yeah... There is a lot of BS electronics that comes from China on eBay. Especially things llike SD-Memory cards and USB Flash drives. Their whole strategy is the cost of sending something back with tracking is so high, it isn't worth while. But the shipping to you is 'free'. (It really is being subsidized by the government.)

Well... I'm the proud owner of a 'yet to be shipped' Chinese AVR ICE gizmo... If you use one of those links up above, you can bid on the exact same thing.

Roxy-3D on 18 Apr 2017

Yeah. I always try to force them to pay return shipping if whatever it is doesn't work or isn't as advertised, and mostly end up getting whatever defective junk it is 'free' because they won't pay the return shipping either. The eBay and PayPal buyer protection programs are pretty decent.

Don't get me wrong - I've found some really good vendors for some things, but they're relatively rare...

bgort on 19 Apr 2017

The cheap $8 JTAG USB debuggers work as a debugger only on a very few low end Atmel chips. Don't bother with them.

I ran into the "JTAG pins used for other functions" issue. I ended up getting a Ultimaker shield. It has A4-A7 on a breakout. I'll need to solder on a header but at least the signals are available.

I have a Dragon JTAG debugger on order. It should get here Friday. Now if I can ever figure out how to use Atmel Studio 7 I might be dangerous by the end of the weekend.

Bob-the-Kuhn on 19 Apr 2017

Maybe what you're bidding on will do the job. I just went on ebay & found some similarly named devices that explicitly say they only support the few chips BUT... they have different chips on them.

Bob-the-Kuhn on 19 Apr 2017

The thing is... If they can do J-Tag on the low end chips... You would think the high end chips would be willing to 'listen' to the J-Tag programmer? I guess we will know soon enough. If you learn anything new or if you get your setup working... Please let us know!

Roxy-3D on 19 Apr 2017

Some bits of information that might help:

Atmel had the Atmel JTAG ICE and open sourced it. This is also supported by Atmle Studio (Atmel Studio will update it's firmware). That is what these cheap clones are. It is a good thing if you work with Atmel Studio or avrdude.

Atmel then (for whatever reason) released the JTAK-ICE-mk2 That was closed source. And only the mk2 supports the mega2560. It took arvdude some time, but I think it now also supports the mk2. So this would work with debugging using Atmel Studio on Windows.

Atmel then had the mk3 and finally the ATMEL ICE. You can order that from mouser(as linked above) or Microchip direct, or others. This will support all AVRs and also the Atmel SAM processors. It will probably not work with other Cortex-M Processors and it only works with Atmel Studio. The reason for this is that the communication between Atmel Studio and the ATMEL ICE is proprietary.

The more open source approach is to have either a Device that speak the GDB language. or to have a open hardware board with a firmware that speaks something that a open source software can then translate to GDB language. This converter software is Openocd. They have a long list of supported boards (Bus Pirate, Open Bench, FTDI H*, ..) The OpenOcd guys seem to not be to confident in there AVR support though. This might just be because nobody used it. But it might mean that it won't work out of the box.

The pin out should not only include these (listed above)
TDO -
TCK -
TDI -
TMS -
Vsense (+5V) & GND

But also /Reset. That just makes it so much easier.

The Rumba board also has a JTAG Header. So with the ATMEL ICE you can just plug it in and start debugging. That is after you compiled Marlin using the Arduino Studio,..

For finding bug's like these I would also recommend to add unit testing. Yes unit testing for 8bit firmware is possible, and it isn't that hard either. It is just a lot of boring work.

I have done JTAG Debugging on the Arduino 2560 so if you need any more help, just let me know. I would offer to do some debugging on my own, but I can't figure out how to compile Marlin using Arduino IDE on my Linux machine. And the makefile also doesn't work,...

JustAnother1 on 19 Apr 2017

This is how an (ugly soldered) JTAG Adapter for the Arduino 2560 could look like. The 10 Pin connector has the standard Atmel Pinout.
20170419_025622

JustAnother1 on 19 Apr 2017

Atmel then (for whatever reason) released the JTAK-ICE-mk2 That was closed source. And only the mk2 supports the mega2560. It took arvdude some time, but I think it now also supports the mk2. So this would work with debugging using Atmel Studio on Windows.

So, with that pig tail in the picture up above, can some other J-Tag interface talk to the Atmega-2560 board? Or can only the MK2 do it?

And if only the MK2 will do it... Is this what you are talking about? If I order this, it should just connect up and work with no hassles? http://www.ebay.com/itm/Atmel-JTAGICE-mkII-JTAG-ICE-mk2-ATJTAGICE2-AVR-AVR32-Debugger-Emulator-compliant-/111999248960?hash=item1a13acea40:g:kL4AAOSwQ15XOY6W

Roxy-3D on 19 Apr 2017

This is great info. Thanks @JustAnother1.

I did find that the Atmel ICE supposedly works with openocd in several places, as it's CMSIS-DAP compliant (whatever that is).

Here's one of the links:
http://vk5tu.livejournal.com/56648.html

Hopefully this is true, as I'd like to not have to use Atmel Studio 7 if I don't want to.

bgort on 19 Apr 2017

So, with that pig tail in the picture up above, can some other J-Tag interface talk to the Atmega-2560 board? Or can only the MK2 do it?

The ATMEL Jtag-ICE (and it's clones) would not be able to talk to it. The mk2 and up (mk3, ATMEL ICE) are able to talk to it. The reason is that Atmel Studio reads the ID Bytes of the chips and then decides to not work with them if the open Hardware ice is connected. The reason seems to be just them being nice.

Openocd supported boards should also be able to talk to the chip.

There might be an issue though. The AVR has fuse bits. and one fuse bits disables the JTAG interface. But all the Debuggers also have ISP. And via ISP the JTAG Fuse bit can be enabled. On my Arduino 2560 the JTAG interface was disabled and I had to use the ISP interface to enable it before I could use the JTAG interface. On my Rumba board the JTAG was enabled. YMMV

JustAnother1 on 19 Apr 2017

@bgort CMSIS is a standard invented by ARM. It defines a lot of the Cortex-M stuff. DAP is probably Debug Adapter. If your linked pages tell the truth then you will be able to use the ATMEL ICE with openocd for probably all ARM Cortex processors.

But the AVR is not CMSIS compatible. Using the Atmel ICE with openocd for avr might work. Please let me know if you manage to do that.

JustAnother1 on 19 Apr 2017

Using the Atmel ICE with openocd for avr might work. Please let me know if you manage to do that.

And the MK2 or MK3 would qualify as an 'Atmel ICE' ? Right? Because for $23 they can be obtained here:

http://www.ebay.com/itm/AT-AVRISP-AVR-ISP-mkII-In-System-Programmer-ATAVRISP2-AVRISPmkII-Compliant/192152083426?_trksid=p2047675.c100005.m1851&_trkparms=aid%3D222007%26algo%3DSIC.MBE%26ao%3D2%26asc%3D41811%26meid%3Db3904b7d594c4dffb2a4c05f95ef33d3%26pid%3D100005%26rk%3D6%26rkt%3D6%26sd%3D111949022769

Roxy-3D on 19 Apr 2017

@Roxy-3D You will need the Atmel JTAG ICE-mkII not the Atmel ISP-mk2. The ISP mk2 you linked was (to my knowledge) never more expensive than $30. But it also only has ISP and not the JTAG interface. So that is the wrong device!

The JTAG-mk2 look similar. Is a bit bigger, has leds and has a flat cable with a pcb and two connectors at the end. It has the 10 pin JTAG pinout, the 6 pin ISP and a squid cable ,..

JustAnother1 on 19 Apr 2017

This is bad marketing on Atmel's part... Having the same name but just changing the MKII to MK2 is going to cause confusion! OK! THANKS! I'll look for the MK2 with J-Tag!

Roxy-3D on 19 Apr 2017

This is the JTAG mk2:
http://www.ebay.de/itm/Atmel-JTAGICE-mkII-JTAG-ICE-mk2-ATJTAGICE2-AVR-AVR32-Debugger-Emulator-compliant-/260612589287?hash=item3cadb886e7:m:mmnaWxJ-C5FA39Kv-D3zJ8Q

And this the mk3 ???:
http://www.ebay.de/itm/Atmel-JTAGICE-MKIII-JTAGICE-MK3-ATJTAGICE3-Entwicklungswerkzeug-/192127268398?hash=item2cbbad762e:g:K7kAAOSw2gxYxC1U

Historically the prices went down. The MK2 was always very expensive the mk2 was cheaper and the Atmel ICE was again cheaper (Maybe Atmel realized that making the debugger widely available isn't a bad thing,...)

JustAnother1 on 19 Apr 2017

@Roxy-3D No the difference is not mkII vs MK2 The difference is ISP-mk2 vs JTAG-mk2

I won't argue about the bad marketing. Maybe that is the reason they now are Microchip,...

JustAnother1 on 19 Apr 2017

OK... One more question: Using the J-TAG MK2, it looks like it still connects up to the 6 pin ISP connector? Does it also need a separate cable going to J-Tag pins? Or does it just use the ISP connector to do J-Tag?

Roxy-3D on 19 Apr 2017

But the AVR is not CMSIS compatible. Using the Atmel ICE with openocd for avr might work. Please let me know if you manage to do that.

Will do.

I won't argue about the bad marketing. Maybe that is the reason they now are Microchip,...

I was relatively confused when reading about/researching these. They really didn't/don't do a good job naming things, generally.

bgort on 19 Apr 2017

It needs the 10 pin connector to do JTAG. The 6 pin can only do ISP there is no tunneling it through.

JustAnother1 on 19 Apr 2017

It needs the 10 pin connector to do JTAG. The 6 pin can only do ISP there is no tunneling it through.

So we plug into the 6 pin ISP connector and add the 4 more pins it needs to the cable?

Roxy-3D on 19 Apr 2017

It needs the 10 pin connector to do JTAG. The 6 pin can only do ISP there is no tunneling it through.

So we plug into the 6 pin ISP connector and add the 4 more pins it needs to cable?

What ? JTAG and ISP are totally different interfaces. A device that can only do ISP is worthless if you want to do JTAG. The signals on those pins is also completely different.

The JTAG-MK2 can do both though. It has a ISP and a JTAG Interface.

JustAnother1 on 19 Apr 2017

Ooops! My apologies JustAnother1 I hit the wrong button and edited your comment...

The JTAG-MK2 can do both though. It has a ISP and a JTAG Interface.

Yes... What I'm trying to figure out is how I get it connected to my Atmega-2560 boards in J-Tag mode. Up above bgort found that we needed 4 signals besides power and ground to do J-Tag. That was in this comment: https://github.com/MarlinFirmware/Marlin/issues/6331#issuecomment-294963888

If we need to solder wires to get some of the signals... Even that is OK. And then I guess we plug into something like your pig tail in the picture up above, right?

Roxy-3D on 19 Apr 2017

The Arduino2560 has a 6 pin header next to the avr cpu. The Jtag-mkII has a 6 pin connector for that and can speak ISP (basically SPI: MISO, MOSI,..) on that.

The JTAG-mk2 also has a 10 pin connector. That needs to be connected to the pins listed above: TDO, TCK, TDI, TMS, Vsense (+5V), /Reset & GND

One way to do that is shown in the picture I posted. Just connect the Jtag-mk2 to the 10 pin connector that is shown in the picture and you are ready to go. That is the same as what @bgort describes in his post.

On the Rumba board you already have the same 10 pin connector (2 rows of 5 pins) already on the board.

If you buy a mk2 with the squid cable (a cable with a 10 pin connector and 10 lose wires then you can connect directly to the arduino. You might need some jumper wires as gender changes (I think the squid cable has female ends) But that will obviously not work with the Ramps attached.

JustAnother1 on 19 Apr 2017

If you buy a mk2 with the squid cable (a cable with a 10 pin connector and 10 lose wires then you can connect directly to the arduino. You might need some jumper wires as gender changes (I think the squid cable has female ends) But that will obviously not work with the Ramps attached.

Thank You for verifying that. The RAMPS part isn't a problem I can just make sure to solder the right type of wire onto the 10 pin connector.

THANK YOU FOR ALL THE HELPFUL INFORMATION!!!!!

Roxy-3D on 19 Apr 2017

Here is a better video of what I'm talking about. I start the whole process from start. Temp changes at 5:19 . https://youtu.be/jrsUpjyUvmg

Rhonal89 on 19 Apr 2017

@Rhonal89 Yes... I've seen that exact thing... I had different numbers for the target temperature of the bed and nozzle. But I've seen it. And when that happens, the Stack Pointer is off in a new location. An In Circuit Emulator would be very helpful to find the problem! But if you drop to a 10x10 grid... The problem doesn't seem to happen. So until we find the root cause of the problem... My suggestion would be to use a 10 x 10 Mesh. And I'm using a 10 x 10 mesh on a 400mm x 400mm bed. That offers plenty of 'correction' to get good adhesion across 100% of the bed.

Roxy-3D on 19 Apr 2017

👍1

Thank You!! Roxy, I just don't want to look crazy here. I appreciate all the work you guys do. Will use 10 points

Rhonal89 on 19 Apr 2017

I appreciate all the work you guys do. Will use 10 points

Thanks! And we will figure out the issue and get the system to allow 15x15. But no more cursing about how long it takes to probe a 15 x 15 grid! You can get a cup of coffee while it is doing its thing. Once you have a finely tuned mesh... It is saved in EEPROM and you just use it from that point going forward.

Roxy-3D on 19 Apr 2017

Thanks, I will. Now to follow everything you have written word by word to get a perfect mesh.

Rhonal89 on 19 Apr 2017

@Rhonal89 Start a new thread.... (This one has already gone pretty far off topic). And I'll coach you to get a very good mesh with minimal work. Do the 10 x 10 G29 P1 and post your map... I'll be up for another hour and a half. That should be plenty of time to do a couple of iterations to get it perfect.

For starters... That would be

Change Configuration.h to have a 10 x 10 mesh
Probably it makes sense to go into Configuration_adv.h and turn on Z-BabyStepping and the Double-Click to go to Z-BabyStepping option.
Reset the printer and do a M502, M500, And M501.
Reset the printer and get the nozzle and bed up to temperature
Give it a G28
Give it a G29 P1
Give it a G29 L1 to save the mesh. Then post the mesh and I'll reply as soon as I see it.

Roxy-3D on 19 Apr 2017

I would take that offer Roxy, but you are already busy enough. I'll see if I figure this out and I'll let you know if I need more help, Just take that extra hour and rest.

Rhonal89 on 19 Apr 2017

I'm just watching TV... I really don't mind. And you already have had a difficult time with this random data corruption issue. I would like you to have everything go smoothly from here on out.

And depending on what we see on the Topology Map... It takes almost no effort to suggest the 'right' way to handle it. Go ahead and post the map when you get it...

Roxy-3D on 19 Apr 2017

The 2560's On Chip Debugger is only accessible through the JTAG pins. Other Atmel devices can access the OCD via the ISP.

@JustAnother1 - were you using the Atmel Studio to do the debugging?

Any pointers to help/tutorials that'll ease the learning curve would be much appreciated.

Bob-the-Kuhn on 19 Apr 2017

@Bob-the-Kuhn We should try to learn what that Arduino_debug.exe is all about. That might automatically generate the symbol table files that GDB needs.

Update: Arduino_Debug.exe doesn't do anything we care about....

Roxy-3D on 19 Apr 2017

were you using the Atmel Studio to do the debugging?
Any pointers to help/tutorials that'll ease the learning curve would be much appreciated.

Can we still compile and build using Arduino, but generate the required symbol tables and then feed that into Atmel Studio? If not... How hard is it to get Marlin to compile inside Atmel Studio?

Roxy-3D on 19 Apr 2017

@Bob-the-Kuhn Yes I use Atmel Studio7 (I have also used the older versions) to debug.

As to tutorial: There is nothing that directly comes to mind. But I'm not aware what the issues are that on your learning curve. It probably makes most sense to add all information about how to compile and set up debugging to the Marlin documentation. This way others can also benefit from it. I think there is a Wiki somewhere. If you start a page and send me a link I will take a look and fill in the gaps if I can.

@Roxy-3D One handy trick if compiling with Atmel Studio is an issue:
In Atmel studio create a project and add the source. Then instead ob build just click on debug. It will complain that the *.elf file is missing. Take the already compiled elf file and put it at the place named and click debug again. Atmel Studio will then download that elf file into the chip and will start debugging it. If the source files are at the right position everything should work fine.

JustAnother1 on 19 Apr 2017

How hard is it to get Marlin to compile inside Atmel Studio?

That depends on how much Marlin depends on the Arduino specific stuff. I have converted this firmware https://github.com/minnow-pmc/Minnow from Arduino to non Arduino.
For all the Arduino libraries that are used you need to copy the *.c and *.h files into your project. Arduino then also helps with missing includes. If the code relies on Arduino IDE to add include statement then you have to also add them.

But instead of letting Atmel Studio create a new make file (that it then hides) you can also configure Atmel Studio to just execute an already existing makefile. If building Marlin using the Marlin provided makefile works then that should also be enough to get Atmel Studio to debug it.

JustAnother1 on 19 Apr 2017

FYI, there's a free addon for Atmel Studio 7 for Arduino ('Arduino IDE for Atmel Studio 7') that, I believe, provides all of the libraries, etc., and what looks like a limited version of the visualmicro.com Arduino debugger? I haven't tried any of this yet, but it's there and it installed fine.

There's also a pro version for $29 one-time (non-profit/non-commercial price) that adds a bunch of features that look worthwhile ('advanced memory report', 'almost real-time free memory report', etc.).

Will reply here when I've tried it all out. EDIT: Looks like my ATMEL ICE won't be here until Monday, as Mouser used almost-always-horribly-slow UPS Mail Innovations; that's what I get for choosing the cheapest option.

bgort on 19 Apr 2017

It probably makes most sense to add all information about how to compile and set up debugging to the Marlin documentation. This way others can also benefit from it. I think there is a Wiki somewhere. If you start a page and send me a link I will take a look and fill in the gaps if I can.

People: Let's try hard to keep good notes as we bring up our debugging hardware. I'm not sure about the right way to keep the documentation around but let's not lose the recipe. I'm not sure about the state of the Marlin Wiki. @thinkyhead can probably make a suggestion for how we keep our notes in a form others can benefit.

Roxy-3D on 19 Apr 2017

I plan to document everything here for now; can help with a wiki page at some point, too, if/when one exists.

bgort on 19 Apr 2017

Just to throw the Idea out there:
There is also the AVR simulator. Using the simulator for debugging would enable people with no hardware at all to help with programming and debugging. And the simulator can provide even more information on what is really happening than JTAG debugging can.

Also probably a pain to set up correctly,..

JustAnother1 on 20 Apr 2017

There is also the AVR simulator. Using the simulator for debugging would enable people with no hardware at all to help with programming and debugging.

Yeah... But right now I'm looking for a bad pointer that is writing over the stack pointer. Without hardware to move around... How do I get the problem to happen?

Roxy-3D on 20 Apr 2017

Is this one of the UBL symptoms? After the strange line numbers it usually waits 5-10 seconds and then reboots. Once it just scrolled the invalid line number complaints forever.

12:32:43.676 : N27 G29 P1*102
12:32:43.681 : ubl.eeprom_start=64
12:32:43.693 : Mesh invalidated. Probing mesh.
12:32:43.739 : Error:Line Number is not Last Line Number+1, Last Line: 131072
12:32:43.739 : Resend: 131073
12:32:43.784 : Error:Line Number is not Last Line Number+1, Last Line: 16520896
12:32:43.784 : Resend: 16520897
12:32:54.744 : Printer reset detected - initalizing
12:32:54.745 : start
12:32:54.745 : echo:Marlin 1.1.0-RCBugFix

I'm trying to use a Ultishield board with nothing tied to it. This is so I don't have to rip up all my cabling to install a new controller (the Ultishield) on my printer. To do this I've done the following:

added this code to the end of the setup() function LOOP_XYZ(i) axis_homed[i] = true ;
set the extruder sensor to 999 and set that to 220
set all my endstops & probe to false - strange but if I set only the probe to false then the system hangs when doing G29 P1 with a 3x3.
selected FIX_MOUNTED_PROBE

`

Bob-the-Kuhn on 20 Apr 2017

I'm looking for a bad pointer that is writing over the stack pointer. Without hardware to move around... How do I get the problem to happen?

How do you expect to find the issue with JTAG? The AVR doesn't have data Breakpoints.

Then I did not mean to use a simulator that only simulates the AVR core and then to have the firmware basically just sitting there doing nothing. A simulation of the hardware would also be needed. Then again for bed leveling the only thing you need is the sensor, right? When debugging the firmware running inside the simulator you can change the value of variables. Changing the value read from the sensor (triggered not triggered) should be configurable in the simulator, right?

JustAnother1 on 20 Apr 2017

How do you expect to find the issue with JTAG? The AVR doesn't have data Breakpoints.

I didn't realize this. But still... Being able to set break points on code will be helpful. For example, setting a break point on any of the reset or initialization code would at least stop things much sooner than we can do that now. AND... we would be able to look at the stack frame and see what was going on when the reset happened...

A simulation of the hardware would also be needed. Then again for bed leveling the only thing you need is the sensor, right? When debugging the firmware running inside the simulator you can change the value of variables.

I think all of the stepper motors would have to be simulated also. The nozzle is moved around a bunch. And for that matter... The encoder wheel is pretty critical to the UBL functionality too.

Roxy-3D on 20 Apr 2017

Can you please tell me, for clarity, if the memory issue is with regard to
reading/writing to the EEPROM the UBL mesh?

Grogyan on 20 Apr 2017

Can you please tell me, for clarity, if the memory issue is with regard to
reading/writing to the EEPROM the UBL mesh?

It is hard to be specific because the corruption has many different symptoms and we have not found the root cause. But the problem seems to show up when you define a very large mesh within the UBL system. A 15x15 mesh seems to make it happen pretty often. A 10x10 mesh seems to be OK.

The EEPROM does not seem to be affected. Right now, my best guess is there is a NULL pointer that is being written to somewhere in the Marlin code, and it is hammering the first locations of RAM where the Stack Pointer is stored. Once the Stack Pointer is corrupted, as soon as that code does a 'return', things go off into space.

Does GCC have a compiler option to always check a pointer for being NULL before writing to it? If so... That might help us find the problem.

UPDATE: It appear not. At least not for us:

-fdelete-null-pointer-checks
Assume that programs cannot safely dereference null pointers, and that no code or data element resides at address zero. This option enables simple constant folding optimizations at all optimization levels. In addition, other optimization passes in GCC use this flag to control global dataflow analyses that eliminate useless checks for null pointers; these assume that a memory access to address zero always results in a trap, so that if a pointer is checked after it has already been dereferenced, it cannot be null.

Note however that in some environments this assumption is not true. Use -fno-delete-null-pointer-checks to disable this optimization for programs that depend on that behavior.

This option is enabled by default on most targets. On Nios II ELF, it defaults to off. On AVR and CR16, this option is completely disabled.

Passes that use the dataflow information are enabled independently at different optimization levels.

Roxy-3D on 20 Apr 2017

Have been looking at the code, wondering why using the EEPROM so much?
There are only so many write cycles to the EEPROM
There is also some potential there for underflow.

Also, what I can't tell from the code is whether the EEPROM is being
written to every probe point, or all at once once all probe points are done.

Perhaps, i'm just an idiot. But is just my 2c worth

Grogyan on 21 Apr 2017

Is this one of the UBL symptoms? After the strange line numbers it usually waits 5-10 seconds and then reboots. Once it just scrolled the invalid line number complaints forever.

For whatever it's worth, I haven't seen the invalid line number thing at all.

bgort on 21 Apr 2017

@Grogyan Have been looking at the code, wondering why using the EEPROM so much? There are only so many write cycles to the EEPROM There is also some potential there for underflow.

UBL state info is being written to EEPROM perhaps a little too frequently currently, but that will likely change as we move the state to the normal config. store (probably tomorrow). I imagine it was done the way it is now because UBL has been in development and it's simpler.

Also, what I can't tell from the code is whether the EEPROM is being written to every probe point, or all at once once all probe points are done.

Probed points aren't written to EEPROM at all until a G29 Sx is issued; then they're written all at once.

bgort on 21 Apr 2017

@Roxy-3D

all of the stepper motors would have to be simulated also

You may be over complicating it. The only inputs Marlin uses are the thermal inputs, the endstops & probe. I've been running G29 P1 15x15 on just a bare bones RAMPs (with LCD attached) & getting strange behavior. 10x10 seems to be well behaved.

See my previous post on what I did.

Bob-the-Kuhn on 21 Apr 2017

The EEPROM has at least 10,000 erase/write cycles on the old AVR parts. Currently, it is spec'ed at over 100,000 cycles. But even so... The EEPROM is only written when the UBL System's state is changed and a 'Save' of the mesh happens. So right now... If you do a G29 A or a G29 D it will write to the EEPROM. And any G29 S that saves the current mesh will write to the EEPROM.

So.... for me that is a non-issue. I turn on the system and never turn it off. But you are correct we should not be stamping on the EEPROM every time a user turns on or off the system. Probably the thing to do is still save the current state when a Mesh is saved. But other than that... Not save the updated state just because the user did a G29 A or G29 D. I'm going to think about this some more. But probably this will be changed in the next few days when I re-Synch my local code with the main branch.

Roxy-3D on 21 Apr 2017

My 2 cents here...
I hate those kind of issues that could be due to the inside the box (the MARLIN set of code) AND to the outside of the box (compiler)...

Seems that the symptom changes when modifying the Marlin code... This COULD mean that we trigger an outside mis-behavior..

Could we get a failing Marlin code and CHANGE the outside box. To use OTHER compile parameters (think of -fpermissive flag) or even change the compiler version COULD give some indications about how to proceed while waiting the needed hardware... BTW, what is the Arduino version used by who do see the issue?

Sorry, just some ideas that I cannot try myself...

lrpirlet on 21 Apr 2017

But other than that... Not save the updated state just because the user did a G29 A or G29 D. I'm going to think about this some more. But probably this will be changed in the next few days when I re-Synch my local code with the main branch.

This is one of the areas where I thought we could save EEPROM writes; personally, I don't see a need for - or want - state saving unless I issue M500, and I think most would be comfortable with that, generally. I was going to float this change when I move the state to the config. store.

Probably the thing to do is still save the current state when a Mesh is saved.

Hmm. Don't think I agree; saving the mesh shouldn't save the state, in my opinion. The 'normal' method of saving the current state of the entire printer w/M500 is sufficient, for me. This minimizes potentially undesirable changes to 'permanent' settings, minimizes EEPROM writes, and I think it's best to keep things logically segmented, generally, rather than 'chain' saving in a way that might not be obvious (or desired).

Like you say, you activate UBL and leave it activated, and I think almost everyone will do the same once they've transitioned to UBL; needing to issue M500 to save the state is to be expected (and probably desired), generally, I think.

bgort on 21 Apr 2017

Want to archive this here, because it's well done, potentially of use in finding this bug, and I have no idea where I got it:
atmega640_1280_1281_2560_2561_sram_data_memory_locations

bgort on 21 Apr 2017

Hmm. Don't think I agree; saving the mesh shouldn't save the state, in my opinion. The 'normal' method of saving the current state of the entire printer w/M500 is sufficient, for me. This minimizes potentially undesirable changes to 'permanent' settings, minimizes EEPROM writes, and I think it's best to keep things logically segmented, generally, rather than 'chain' saving in a way that might not be obvious (or desired).

The reason the state is saved at the same time as a mesh is saved is because that gives a user a way to control whether the system powers up from reset with UBL active or disabled. What ever the state of the machine was when the mesh was saved is how the system will behave.

I'm OK with changing that to be more intuitive. But it is important to provide a way for the user to say how they want the machine to power up (UBL Active or UBL Disabled). Maybe the 'Right' answer is to make a small modification to the G29 A and G29 D commands and add an extra (optional) parameter. If you did a G29 A R it will be active after a Reset (and the state information would be saved that way) but a simple G29 A would just change the current machine state and not save to EEPROM. And then the same logic for G29 D and G29 D R.

That is probably more intuitive and easier for the user to understand and control. And it would cut down on the EEPROM writes.

Roxy-3D on 21 Apr 2017

Hmm. I'm thinking that just saving with M500 once it's in the state you want it to power up in is probably most consistent with how things are done now, and what most people will probably expect in terms of behavior. So in that scenario, you'd do your mesh-whatever, save the new mesh with G29 Sx, activate the mesh with G29 A, and then if you want the machine to always come up in that state, just do a M500 right then and you're in good shape. Both the new storage slot # and active state would be saved to the config store without having to write anything else again (as you know and I just realized, the config store eeprom writer checks to see if the new value is the same as what's already saved, and then skips the write if there's been no change), so there's no wasted write cycles.

I feel like adding another parameter to G29 A/D like the 'R' you're proposing probably isn't necessary, but we could do it without much trouble if you feel it's important. I'll finish what I'm in the middle of and if you think the extra 'R' is necessary after seeing it all, I can add it and amend the commit.

bgort on 21 Apr 2017

I understand what you are thinking... I kind of developed the UBL system with a different thinking. For example... When I start building a mesh for a piece of glass I do a G29 P1. After that gets as much of the glass probed as it can, I do a G29 S0. I then fill in the invalid regions and do a G29 S1. I then do a G26 and edit any questionable areas. And I usually save that as G29 S2. But I never do an M500. Also... When I have a perfectly tuned mesh, I seem to prefer it is in slot 1. So I'll do a G29 L4 (or how many tries it took me) and follow it with a G29 S1 to put it in slot 1.

What ever we do, it is important that people can move their mesh patterns by doing Loads and Saves outside of M500.

I feel like adding another parameter to G29 A/D like the 'R' you're proposing probably isn't necessary, but we could do it without much trouble if you feel it's important. I'll finish what I'm in the middle of and if you think the extra 'R' is necessary after seeing it all, I can add it and amend the commit.

I think I like the idea of only writing the state information if an R is added to the G29 A or G29 D command. The downside is G29 is out of letters to use and R is used as a 'Repeat' sub-option. So it is kind of butchering what 'R' stands for. But then again... It is sort of a 'Global Repeat'. We are trying to get the systems activation or deactivation to Repeat at Reset or Power Up.

Anyway... To add the check for 'R' on G29 A and G29 D should be very straight forward. The command parser will already have the repeat_flag set for you. Very literally, the code becomes:

    if (code_seen('A')) {     // Activate the Unified Bed Leveling System
      ubl.state.active = 1;
      SERIAL_PROTOCOLLNPGM("Unified Bed Leveling System activated.\n");
      if (repeat_flag)
        ubl.store_state();
    }

    c_flag = code_seen('C');
    if (c_flag)
      ubl_constant = code_value_float();

    if (code_seen('D')) {     // Disable the Unified Bed Leveling System
      ubl.state.active = 0;
      SERIAL_PROTOCOLLNPGM("Unified Bed Leveling System de-activated.\n");
      if (repeat_flag)
        ubl.store_state();
    }

The comments describing the various options will take more effort to get right than the code! When does that ever happen?

Roxy-3D on 21 Apr 2017

I understand what you are thinking... I kind of developed the UBL system with a different thinking. For example... When I start building a mesh for a piece of glass I do a G29 P1. After that gets as much of the glass probed as it can, I do a G29 S0. I then fill in the invalid regions and do a G29 S1. I then do a G26 and edit any questionable areas. And I usually save that as G29 S2. But I never do an M500. Also... When I have a perfectly tuned mesh, I seem to prefer it is in slot 1. So I'll do a G29 L4 (or how many tries it took me) and follow it with a G29 S1 to put it in slot 1.

All of what you said makes sense to me, and I ended up doing what you do when I created my first meshes (pretty much exactly); we're definitely on the same page there. I think saving the mesh with a separate command was a great idea, and well-executed. To be clear, I wasn't proposing changes to any of the 'workflow' you just described.

What ever we do, it is important that people can move their mesh patterns by doing Loads and Saves outside of M500.

Of course. I wasn't suggesting that meshes themselves should be saved with M500 (those would always be saved with G29 S); I'm talking about saving the state (and the state only) using M500 (which is what I thought you were asking me to do when you said you wanted the state moved). Sorry if that wasn't clear before.

I'll do a PR shortly. I think what I have will work well for you and others, but we can revise/change after that if you're uncomfortable with anything, if that makes sense?

bgort on 21 Apr 2017

Of course. I wasn't suggesting that meshes themselves should be saved with M500 (those would always be saved with G29 S);

Let's talk about this from a user's perspective. If the UBL state structure has a valid Mesh Slot defined in it... My guess is at least some users would expect an M500 to also save the current mesh. I guess it depends on how many users expect that behavior. It probably is safest to 'Save Everything' with a M500 command. But you get more granular control if you use the G29 path to save or update EEPROM.

If you agree... Let's also save the current mesh in the current mesh slot when an M500 happens.

And then we have another decision to make... Should we move the existing mesh patterns to the very end of the EEPROM now that the UBL State Structure isn't taking up space there? If we do that... Some users will lose their mesh patterns. But... They can move them with a G29 S -1 and print that output in the updated version. And... independent of that, it is now faster and easier to generate a new mesh.

So... It is really a decision about cleaning up the data structures versus trying to minimize hassles for the users. If Marlin is going 'Golden' at the end of the month (or very soon), it would be good to have the data structures compacted. And having space not used by the UBL State structure at the end of EEPROM is kind of ugly. But I also hate to cause some users to loose their mesh data.

Roxy-3D on 21 Apr 2017

If you agree... Let's also save the current mesh in the current mesh slot when an M500 happens.

This is what I've already done. Fighting with git now so I can finish up and do a PR.

And then we have another decision to make... Should we move the existing mesh patterns to the very end of the EEPROM now that the UBL State Structure isn't taking up space there?

I've already done this also.

If we do that... Some users will lose their mesh patterns. But... They can move them with a G29 S -1 and print that output in the updated version. And... independent of that, it is now faster and easier to generate a new mesh.

Yes, this was exactly my plan, and would have mentioned this (the G29 S-1) in the PR comments.

So... It is really a decision about cleaning up the data structures versus trying to minimize hassles for the users. If Marlin is going 'Golden' at the end of the month (or very soon), it would be good to have the data structures compacted. And having space not used by the UBL State structure at the end of EEPROM is kind of ugly. But I also hate to cause some users to loose their mesh data.

I agree with all of that, and I think those of us using UBL now can manage to do a G29 S-1 and then simply import meshes. Certainly it has to happen eventually -- there's no reason to leave the space at the end wasted; better now while there are fewer using UBL than in the future when a lot of people are. Also, I was able to make some improvements to the EEPROM storage and a few UBL things, generally, and ended up saving ~100 bytes of SRAM and a good bit of EEPROM space, in the end.

I just need to figure out wtf git is doing (or what I'm doing with git) so I can properly merge in the changes you just merged without having to redo everything I've already done. EDIT: stash did the job for me!

bgort on 21 Apr 2017

@Roxy-3D - thanks for the memory map.

I haven't been able to find the end of the heap yet but I just started looking.

Bob-the-Kuhn on 21 Apr 2017

No! That was bgort that posted that! I thought the same thing! I'm printing that puppy out!

But Bob... here is the thing... If you really have full symbolic support with the J-Tag interface... GDB should let you just dump memory at __BSS_END. It should know that symbol and its value. Probably you will have to fight with it to figure out how to make that happen. But when you compile with the right debug options and such, it would be my expectation that you can use any symbol and the debugger will know the exact location you are talking about.

And JustAnother1 was saying we don't get data break points. That sucks. But... Even so... if we can single step, and step over function calls, we can find the data corruption pretty fast. We would just get the system set up such that we know a sequence that causes the problem. And we can single step (or step over) calls and keep watching the data areas that get hammered. It will take a small amount of effort... But we can get there pretty quickly.

GDB is Gnu's Debugger for GCC (Gnu's C Compiler)

Roxy-3D on 21 Apr 2017

@bgort - thanks

What is GDB?

Bob-the-Kuhn on 21 Apr 2017

I haven't been able to find the end of the heap yet but I just started looking.

Turn on the M100 option. When you do a M100 I or an M100 F, it will tell you the exact location of __BSS_END and __BRK_VAL.

Roxy-3D on 21 Apr 2017

@bgort - thanks

No worries, Bob.

(GDB = GNU debugger)

bgort on 21 Apr 2017

Just got to the point of actually testing my changes on the printer and have encountered this: https://github.com/MarlinFirmware/Marlin/issues/6417

Steppers go wild on motion of any kind.

Need to sort this out so I can test and be comfortable things work prior to PR.

bgort on 21 Apr 2017

Steppers go wild on motion of any kind.
Need to sort this out so I can test and be comfortable things work prior to PR.

Agreed!

Code that totally breaks Marlin's functionality should NOT be merged in.

Roxy-3D on 21 Apr 2017

Yeah -- reverting changes to steppers.cpp fixes the problem. No idea what it is -- not going to dig into the datasheet to try to figure it out. This is a 'you break it, you fix it' situation. 👍

Good news is that my changes seem to be fine. Doing a bit more checking, but think we're good.

bgort on 21 Apr 2017

How many changes are in that commit? Is it just one topic? Can things be made to work again by reverting that merge?

Roxy-3D on 21 Apr 2017

Here it is: https://github.com/MarlinFirmware/Marlin/pull/6400

6 files changed across 3 commits.

Looks like reverting would be okay, but hard to know for sure.

bgort on 21 Apr 2017

I found the stepper.cpp issue - it's caused by a typo in fastio.h, line 141. PR #6418.

benlye on 21 Apr 2017

👍1

This has been found and fixed by @benlye, @Roxy-3D. His change fixed it for me.

https://github.com/MarlinFirmware/Marlin/pull/6418

bgort on 21 Apr 2017

Ha.. good timing, I guess.

bgort on 21 Apr 2017

😄1

Just finished my PR. Everything I tested (mostly UBL-related) seems to be working fine. I have not yet tested the other bed leveling configurations, but I don't see why there'd be a problem with them.

bgort on 21 Apr 2017

About a week ago this thread had a discussion about AVR JTAG ICE clones. I just got mine.

Studio 7 doesn't recognize it.

Anyone been able to use theirs?

Bob-the-Kuhn on 27 Apr 2017

Did you try older versions of Atmel Studio 4.something for example?

JustAnother1 on 27 Apr 2017

I have a Olimex AVR-JTAG-USB. That is a clone of the Atmel JTAG ICE (mk1). I just tried it with Atmel Studio 7 and Atmel Studio 6.2 and both doesn't recognize it.

The reason might be that this device is detected by Windows as a serial port. The new Atmel ICE is a USB Device that does try to be a serial port. Detecting a serial port is a bit harder than detecting a native USB device. So I assume if the newer Studios support the old devices (The JTAG ICE and JTAG ICE mk2 both had a serial interface) they would need a configuration setting to tell Studio which COM port is the debugger. I haven't found that setting.

The old Studios 4.* worked with my clone and they ask you which COM port the debugger uses.

JustAnother1 on 27 Apr 2017

The vendor replied and said to use Studio 4.

I installed Studio 4, set the com port within Studio 4 and got a big silence.

I had to re-install Studio 7. Seems that Studio 4 doesn't play well with Studio 7.

For $8 it was worth the fun just to see if the cheap clone would work.

Bob-the-Kuhn on 29 Apr 2017

Marlin: UBL Issue

All 163 comments

Related issues