[BUG] G28 causes incorrect Z-axis 0-point when using KlackEnder about marlin HOT 7 OPEN

Please download bugfix-2.1.x to test with the latest code and let us know if you're still having this issue.

from marlin.

Please download bugfix-2.1.x to test with the latest code and let us know if you're still having this issue.

I've actually never successfully booted with code under the bugfix branch. There is no output from the display and no output from the serial port.
I'm guessing it's a configuration item, because if I turn on MARLIN_DEV_MODE in the release branch it does the same thing.

Hmm.. seems for some reason the firmware.elf it's building is not having correct vaddr?

readelf -l ./firmware.elf

Elf file type is EXEC (Executable file)
Entry point 0x80090f1
There are 3 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x08000000 0x08000000 0x361c4 0x361c4 RWE 0x10000
  LOAD           0x040000 0x20000000 0x080361c4 0x002d0 0x021c8 RW  0x10000
  LOAD           0x0421c8 0x200021c8 0x200021c8 0x00000 0x00600 RW  0x10000

 Section to Segment mapping:
  Segment Sections...
   00     .isr_vector .text .rodata .init_array .fini_array 
   01     .data .bss 
   02     ._user_heap_stack 

I think it should be at 0x08007000?

from marlin.

Entry point 0x80090f1
Its an elf, its relocatable to correct address when bin is generated.
This is fine

Much more likely you haven't checked what chip you have
The build environment you choose is stm32f103re or rc, the rc has a lot less flash and less ram.
building for a rc on a re chip works fine, but building for a re on a rc chip will not boot.

And the gd32 chip is just an incompatible nightmare...

So Identify your chip.

from marlin.

Entry point 0x80090f1 Its an elf, its relocatable to correct address. This is fine

Much more likely you haven't checked what chip you have The build environment you choose is stm32f103re or rc, the rc has a lot less flash and less ram. building for a rc on a re chip works fine, but building for a re on a rc chip will not boot.

And the gd32 chip is just an incompatible nightmare...

So Identify your chip.

I‘m pretty sure it's a RC, the env I'm using is STM32F103RC_creality. The bin is 190kb and the largest binary I have used with 2.1.2.1 is ~200kb so I don't think either is a problem.

The elf is not relocatable, as you can see the file type is EXEC..

from marlin.

you cannot build with STM32F103Rx_creality on real marlin, its an internal name.
If it does not start with env: at the front you cannot use it as a build environment

ELF files are Executable Linkable Format which consists of a symbol look-ups and relocatable table, that is, it can be loaded at any memory address by the kernel and automatically, all symbols used, are adjusted to the offset from that memory address where it was loaded into. Usually ELF files have a number of sections, such as 'data', 'text', 'bss', to name but a few...it is within those sections where the run-time can calculate where to adjust the symbol's memory references dynamically at run-time.

You don't even use the elf. Its an intermediate file

You use the .bin generated from the elf file

from marlin.

stm32f103re

Correction: I looked at the photo and it's actually RE, so that should more than likely not be an issue.

STM32F103Rx_creality

I was copying from the config and what I meant to say is RC.

from marlin.

I printed some logs..

DEBUG: homeaxis Z
>>> homeaxis(Z)
  current_position= X102.00 Y91.00 Z5.00 : Probe::set_deployed
deploy: 1
  current_position= X102.00 Y91.00 Z5.00 : Debug: Before z raise
Probe::do_z_raise(10.00)
echo:busy: processing
  current_position= X102.00 Y91.00 Z10.00 : Debug: After z raise
  current_position= X102.00 Y91.00 Z10.00 : Debug: old_xy
Home Fast: -375.00mm
Debug: Axis set to zero
echo:busy: processing
echo:busy: processing
Move Away: 5.00mm
Debug: Axis set to zero
echo:busy: processing
Re-bump: -10.00mm
Debug: Axis set to zero
echo:busy: processing
Re-bump done
Debug: Setting...
Debug: Axis Z is at home
  current_position= X102.00 Y91.00 Z-1.20 : sync_plan_position
  current_position= X102.00 Y91.00 Z-1.20 : > AFTER set_axis_is_at_home
  current_position= X102.00 Y91.00 Z-1.20 : Probe::set_deployed
deploy: 0
  current_position= X102.00 Y91.00 Z-1.20 : Debug: Before z raise
Probe::do_z_raise(10.00)
echo:busy: processing
  current_position= X102.00 Y91.00 Z10.00 : Debug: After z raise
  current_position= X102.00 Y91.00 Z10.00 : Debug: old_xy
  current_position= X102.00 Y91.00 Z10.00 : Debug: Before probe_specific_action
  current_position= X102.00 Y91.00 Z10.00 : Debug: Before stow step 1
echo:busy: processing
echo:busy: processing
  current_position= X245.00 Y114.00 Z20.00 : Debug: After stow step 1
  current_position= X245.00 Y114.00 Z20.00 : Debug: Before stow step 2
  current_position= X245.00 Y114.00 Z0.00 : Debug: After stow step 2
  current_position= X245.00 Y114.00 Z0.00 : Debug: Before stow step 3
  current_position= X220.00 Y114.00 Z0.00 : Debug: After stow step 3
  current_position= X220.00 Y114.00 Z0.00 : Debug: Before stow step 4
echo:busy: processing
echo:busy: processing
  current_position= X220.00 Y114.00 Z20.00 : Debug: After stow step 4
  current_position= X220.00 Y114.00 Z20.00 : Debug: After probe_specific_action
Error:Z-Probe failed
Error:Printer stopped due to errors. Fix the error and use M999 to restart. (Temperature is reset. Set it after restarting)
  current_position= X220.00 Y114.00 Z20.00 : sync_plan_position
X:220.00 Y:114.00 Z:20.00 E:0.00 Count X:17600 Y:9120 Z:8000
ok

For some reason those

  current_position= X245.00 Y114.00 Z0.00 : Debug: After stow step 2
  current_position= X245.00 Y114.00 Z0.00 : Debug: Before stow step 3

are not executed on z-axis, but the printer thought they are done.
Any idea why this could happen? something to do with the planner? or is there a way I can dig into this..?

from marlin.