[BUG] PR #22840 Sanity-check BLTOUCVH_SET_5V_MODE not compiling for SKR Mini E3 V2.0 and BLTOUCH Smart v3.1

[swanlm]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

Hardware: SKR Mini E3 V2.0, Genuine BLTouch Smart 3.1

From configuration.h
//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

// Force the use of the probe for Z-axis homing
#define USE_PROBE_FOR_Z_HOMING

#define Z_MIN_PROBE_PIN PC14 // Pin 32 is the RAMPS default

From configuration_adv.h
#define BLTOUCH_SET_5V_MODE

Prior to this PR, this configuration compiled successfully.

Per the BTT Github, the pins for the Z Probe are 5V (both PC14 and PA1). I see two issues with the PR that was introduced.

1. These two Pins are not included in the function _IS_5V_TOLERANT (line 1537)
2. The logic of checking seems incorrect if I understand the code. It seems to check first "if both USES_Z_MIN_PROBE_PIN and NOT _IS_5V_TOLERANT(Z_MIN_PROBE_PIN)" is true, otherwise is the Z_MIN_PIN 5V tolerant". In other words, if the Z_MIN_PROBE_PIN is 5V tolerant then check whether the Z_MIN_PIN is 5V tolerant. On this board, the Z_MIN_PIN is NOT 5V and so compile fails with "BLTOUCH_SET_5V_MODE is not compatible with the Z_MIN_PIN.".
   I changed that section of the code to read:
   "#if USES_Z_MIN_PROBE_PIN //&&
   #if !_IS_5V_TOLERANT(Z_MIN_PROBE_PIN)
   #error "BLTOUCH_SET_5V_MODE is not compatible with the Z_MIN_PROBE_PIN."
   #endif
   #elif !_IS_5V_TOLERANT(Z_MIN_PIN)
   #error "BLTOUCH_SET_5V_MODE is not compatible with the Z_MIN_PIN."
   #endif"
   and changed line 1537 to read:
   #define _IS_5V_TOLERANT(P) (_5V(P,PA1,PA1) || _5V(P,PA8,PA15) || _5V(P,PB2,PB15) || _5V(P,PC6,PC12) || _5V(P,PC14,PC14) || _5V(P,PD0,PD15) || _5V(P,PE0,PE15) || _5V(P,PF0,PF5) || _5V(P,PF11,PF15))

which compiles successfully.

Bug Timeline

With introduction of PR #22840

Expected behavior

I expected the project to compile successfully as it was prior to this PR.

Actual behavior

The project fails with error BLTOUCH_SET_5V_MODE is not compatible with the Z_MIN_PIN in sanitycheck.h

Steps to Reproduce

Configure as follows:
From configuration.h
//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

// Force the use of the probe for Z-axis homing
#define USE_PROBE_FOR_Z_HOMING

#define Z_MIN_PROBE_PIN PC14 // Pin 32 is the RAMPS default

From configuration_adv.h
#define BLTOUCH_SET_5V_MODE

Version of Marlin Firmware

bugfix-2.0.x 02000902

Printer model

Creality Ender 5

Electronics

BTT SKR Mini E3 V2.0

Add-ons

BLTouch Smart v3.1

Bed Leveling

UBL Bilinear mesh

Your Slicer

No response

Host Software

OctoPrint

Additional information & file uploads

From configuration.h
//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

// Force the use of the probe for Z-axis homing
#define USE_PROBE_FOR_Z_HOMING

#define Z_MIN_PROBE_PIN PC14 // Pin 32 is the RAMPS default

From configuration_adv.h
#define BLTOUCH_SET_5V_MODE

[ellensp]

see MarlinFirmware/Configurations#575
Both of those pins are NOT 5v tolerant

[ellensp]

Previous configurations where in error, which is why that test was added.
DO NOT ENABLE BLTOUCH_SET_5V_MODE on this controller

[swanlm]

Previous configurations where in error, which is why that test was added.
DO NOT ENABLE BLTOUCH_SET_5V_MODE on this controller

Thanks, I was going on the schematic. I was also of the understanding that the BLTouch Smart 3.0 and 3.1 required BLTOUCH_SET_5V_MODE. Is that not true?

[ellensp]

no. BLTOUCH_SET_5V_MODE is only needs on badly designed 5v controllers that have to much capacitance on the IO line

[swanlm]

Thanks for the help. Regards, Lance

…

On 03 Oct 2021, at 09:40, ellensp ***@***.***> wrote: no. BLTOUCH_SET_5V_MODE is only needs on badly designed 5v controllers that have to much capacitance on the IO line — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#22870 (comment)>, or unsubscribe </~https://github.com/notifications/unsubscribe-auth/ANVWM2TE5I27TJZEGPNNDGDUFACHZANCNFSM5FHJC2YA>.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.