grblhal / stm32f1xx Goto Github PK

Hi guys.
First of all I would like to say many thanks to Terje Io and all other guys participated in GRBL development. This is a really good job.

Recently I have faced a strange issue with incorrect operation of step motors connected to my STM32F103-based board (STM32F103CBT6). After a couple of hours since I launched my G-code program, I noticed that a distance travelled by a motor does not correspond a distance specified in the executed G-code. Here's my program:
_all_3.txt
The programs consists of multiple repeated movings in Z-axis direction.

Below are my GRBL settings. Step pulse duration and Z-axis acceleration make sense in this test.
gmsc3u_grbl_backup_2022-02-16_grblHAL.txt

When I started to dig into the issue I noticed that some steps on Z axis have a longer duration than specified in GRBL settings.
Below are some waveforms with different timestamp resolution captured on Z-step pin of my board.

With 20us resolution:

With 8us resolution:

With 4us resolution:

As you can see in the worst case the time interval between 2 steps is less than 2us and looks like some motor drivers detect these 2 pulses as a single step pulse which leads to skipping of steps and therefore errors in travel distance by a motor.

To reproduce the issue it's not necessary to run a program. Just execute a simple command:
G0Z500
and you will see that lots of pulses have a longer duration than specified in $0 parameter:

Can you please help to fix this issue.

mcu=103c8
As per the instructions found here: https://github.com/grblHAL/core/wiki/Compiling-GrblHAL
I added OVERRIDE_MY_MACHINE, BOARD_CNC3040, N_AXIS and USB_ENABLE around my configuration as a laser engraver.
N_AXIS=2
USB_ENABLE=0

While N_AXIS = 4 and N_AXIS=3 work just fine but select 2 axis( as in for a laser cutter ) and

`In file included from ../grbl/gcode.h:27,
from ../grbl/system.h:26,
from ../grbl/core_handlers.h:28,
from ../grbl/hal.h:32,
from ../grbl/gcode.c:28:
../grbl/nuts_bolts.h:68:16: error: array index in initializer exceeds array bounds
68 | #define Z_AXIS 2
| ^
../grbl/gcode.c:125:10: note: in expansion of macro 'Z_AXIS'
125 | .ijk[Z_AXIS] = 1.0f
| ^~~~~~
../grbl/nuts_bolts.h:68:16: note: (near initialization for 'scale_factor.ijk')
68 | #define Z_AXIS 2
| ^
../grbl/gcode.c:125:10: note: in expansion of macro 'Z_AXIS'
125 | .ijk[Z_AXIS] = 1.0f
| ^~~~~~
make: *** [grbl/subdir.mk:109: grbl/gcode.o] Error 1
make: *** Waiting for unfinished jobs....
In file included from ../grbl/gcode.h:27,
from ../grbl/system.h:26,
from ../grbl/core_handlers.h:28,
from ../grbl/hal.h:32,
from ../grbl/machine_limits.c:28:
../grbl/machine_limits.c: In function 'limits_homing_cycle':
../grbl/nuts_bolts.h:104:56: error: 'A_AXIS_BIT' undeclared (first use in this function); did you mean 'Z_AXIS_BIT'?
104 | #define AXES_BITMASK (X_AXIS_BIT|Y_AXIS_BIT|Z_AXIS_BIT|A_AXIS_BIT|B_AXIS_BIT|C_AXIS_BIT|U_AXIS_BIT|V_AXIS_BIT)
| ^~~~~~~~~~
../grbl/machine_limits.c:424:34: note: in expansion of macro 'AXES_BITMASK'
424 | } while (axislock.mask & AXES_BITMASK);
| ^~~~~~~~~~~~
../grbl/nuts_bolts.h:104:56: note: each undeclared identifier is reported only once for each function it appears in
104 | #define AXES_BITMASK (X_AXIS_BIT|Y_AXIS_BIT|Z_AXIS_BIT|A_AXIS_BIT|B_AXIS_BIT|C_AXIS_BIT|U_AXIS_BIT|V_AXIS_BIT)
| ^~~~~~~~~~
../grbl/machine_limits.c:424:34: note: in expansion of macro 'AXES_BITMASK'
424 | } while (axislock.mask & AXES_BITMASK);
| ^~~~~~~~~~~~
../grbl/nuts_bolts.h:104:67: error: 'B_AXIS_BIT' undeclared (first use in this function); did you mean 'Z_AXIS_BIT'?
104 | #define AXES_BITMASK (X_AXIS_BIT|Y_AXIS_BIT|Z_AXIS_BIT|A_AXIS_BIT|B_AXIS_BIT|C_AXIS_BIT|U_AXIS_BIT|V_AXIS_BIT)
| ^~~~~~~~~~
../grbl/machine_limits.c:424:34: note: in expansion of macro 'AXES_BITMASK'
424 | } while (axislock.mask & AXES_BITMASK);
| ^~~~~~~~~~~~
../grbl/nuts_bolts.h:104:78: error: 'C_AXIS_BIT' undeclared (first use in this function); did you mean 'Z_AXIS_BIT'?
104 | #define AXES_BITMASK (X_AXIS_BIT|Y_AXIS_BIT|Z_AXIS_BIT|A_AXIS_BIT|B_AXIS_BIT|C_AXIS_BIT|U_AXIS_BIT|V_AXIS_BIT)
| ^~~~~~~~~~
../grbl/machine_limits.c:424:34: note: in expansion of macro 'AXES_BITMASK'
424 | } while (axislock.mask & AXES_BITMASK);
| ^~~~~~~~~~~~
../grbl/nuts_bolts.h:104:89: error: 'U_AXIS_BIT' undeclared (first use in this function); did you mean 'Z_AXIS_BIT'?
104 | #define AXES_BITMASK (X_AXIS_BIT|Y_AXIS_BIT|Z_AXIS_BIT|A_AXIS_BIT|B_AXIS_BIT|C_AXIS_BIT|U_AXIS_BIT|V_AXIS_BIT)
| ^~~~~~~~~~
../grbl/machine_limits.c:424:34: note: in expansion of macro 'AXES_BITMASK'
424 | } while (axislock.mask & AXES_BITMASK);
| ^~~~~~~~~~~~
../grbl/nuts_bolts.h:104:100: error: 'V_AXIS_BIT' undeclared (first use in this function); did you mean 'Z_AXIS_BIT'?
104 | #define AXES_BITMASK (X_AXIS_BIT|Y_AXIS_BIT|Z_AXIS_BIT|A_AXIS_BIT|B_AXIS_BIT|C_AXIS_BIT|U_AXIS_BIT|V_AXIS_BIT)
| ^~~~~~~~~~
../grbl/machine_limits.c:424:34: note: in expansion of macro 'AXES_BITMASK'
424 | } while (axislock.mask & AXES_BITMASK);
| ^~~~~~~~~~~~
make: *** [grbl/subdir.mk:109: grbl/machine_limits.o] Error 1
"make -j4 all" terminated with exit code 2. Build might be incomplete.

20:14:04 Build Failed. 9 errors, 0 warnings. (took 1s.474ms)

`

Hi,
i've tried to build the GRBL Driver STM32F103C8 in STM32CubeIDE. The Build Project failed with 5 errors.
I can build the project with pio run --environment bluepill_f103c8_128k_USB
I've attached the whole output.
Best wishes:
Dan

../Src/sysmem.c:63:1: error: unknown type name 'caddr_t'
63 | caddr_t _sbrk(int incr)
| ^~~~~~~
../Src/sysmem.c: In function '_sbrk':
../Src/sysmem.c:76:25: error: 'caddr_t' undeclared (first use in this function)
76 | return (caddr_t) -1;
| ^~~~~~~
../Src/sysmem.c:76:25: note: each undeclared identifier is reported only once for each function it appears in
../Src/sysmem.c:81:25: error: expected ';' before 'prev_heap_end'
81 | return (caddr_t) prev_heap_end;
| ^~~~~~~~~~~~~~
| ;
../Src/sysmem.c:67:15: warning: variable 'prev_heap_end' set but not used [-Wunused-but-set-variable]
67 | char *prev_heap_end;
| ^~~~~~~~~~~~~
../Src/sysmem.c:82:1: warning: control reaches end of non-void function [-Wreturn-type]
82 | }
| ^
arm-none-eabi-gcc "../Src/usb_serial.c" -mcpu=cortex-m3 -std=gnu11 -g3 -DUSE_HAL_DRIVER -DSTM32F103xB -DDEBUG -DRX_BUFFER_SIZE=512 -DNVS_SIZE=1536 -DNO_SETTINGS_DESCRIPTIONS -c -I../Inc -I../grbl -I../Drivers/CMSIS/Device/ST/STM32F1xx/Include -I../Drivers/CMSIS/Include -I../Drivers/STM32F1xx_HAL_Driver/Inc/Legacy -I../Drivers/STM32F1xx_HAL_Driver/Inc -I../USB_DEVICE/App -I../USB_DEVICE/Target -I../Middlewares/ST/STM32_USB_Device_Library/Core/Inc -I../Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Inc -I../FatFs -I"/home/bkb/workspaces/STM32CubeIDE/GRBL Driver STM32F103C8" -Og -ffunction-sections -fdata-sections -Wall -fstack-usage -MMD -MP -MF"Src/usb_serial.d" -MT"Src/usb_serial.o" --specs=nano.specs -mfloat-abi=soft -mthumb -o "Src/usb_serial.o"
make: *** [Src/subdir.mk:61: Src/sysmem.o] Error 1
make: *** Waiting for unfinished jobs....

"make -j8 all" terminated with exit code 2. Build might be incomplete.

14:30:49 Build Failed. 5 errors, 3 warnings. (took 1s.285ms)

OS version
-Version-
Kernel : Linux 5.19.0-32-generic (x86_64)
Version : #33~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Jan 30 17:03:34 UTC 2
C Library : GNU C Library / (Ubuntu GLIBC 2.35-0ubuntu3.1) 2.35
Distribution : Ubuntu 22.04.2 LTS

STM32CubeIDE version
Version: 1.11.2
Build: 14494_20230119_0724 (UTC)
build_errors.txt

Hi i have uploaded the firmware soon as i do that the com port closes, still has power threw the usb but no connection or pc picking it up.
i have tried to use both firmware's for the SKR MINI E3 V2.0 with no luck any ideas?

I prepared to add board map for MKS Robin E3 V1.0 which has F103RC variant and uses TMC2209 drivers in UART mode.
MKS Robin is compact and suitable for CNC machine, like as BTT SKR E3 V2 (#2)

but according to the schematic, UART pins were used differently for each motor, this design did not seem very effective to me. Is there any limit for grblHAL support? https://github.com/makerbase-mks/MKS-Robin-E3-E3D/blob/master/hardware/MKS%20Robin%20E3%20V1.0_002/MKS%20Robin%20E3%20V1.0_002%20SCH.pdf

https://www.banggood.com/Makerbase-MKS-Robin-E3-Upgraded-32Bit-Control-Board-Integrate-tmc2209-Support-Uart-Mode-Driver-For-CR-10-Ender-3-3D-Printer-p-1666464.html?akmClientCountry=America&&utm_source=google&utm_medium=cpc_ods&utm_campaign=nancy-content-sdsrm-camera-list-content&utm_content=nancy&gclid=Cj0KCQjw6s2IBhCnARIsAP8RfAiCC4yTmDBJEWxNYXTPtpyRSgtJV3fohBrcWTwN-RYfHUp3LKx5EHwaAiHTEALw_wcB&cur_warehouse=CN

If the the motor supply voltage (VS) of TMC2209 is temporarily switched off and re-established then TMC2209 loads power up default settings even VCC_IO was present.
If a Reset bit is set in GSTAT register of TMC2209 the TMC2209 would have to be reinitialized.
Maybe adding periodic check of GSTAT is good idea or ioSender can start this check before sending GCODE?

M122
[TRINAMIC]
                      X       Y       Z       A
Driver          TMC2209 TMC2209 TMC2209 TMC2209
...
msteps                8       8       8       8
...

$$
...
$150=8
$151=128
$152=32
$153=16
...

I wanted to offer to upgrade chip for current users, also i have a board in
the works that will be pin compatible. Here is a link
https://github.com/customsolutions/STM32F1xx/blob/master/Inc/my_cpu_map.h
This is my github. Id be glad to assisit in any way I can.

On Sat, Nov 18, 2023, 1:59 AM Terje Io @.***> wrote:

Do you have a working board map for the MG2, and possibly MG3? Or working
links to this information - I can't find any.
And which chip variant do they use? The 64K flash ones? If the 64K variant
then I see no point in adding board map(s) as I consider it unlikely that
end users will replace the MCU.

[image: image]
https://user-images.githubusercontent.com/20260062/283986061-40b6949c-503f-4327-9bd3-1f0134c022d4.png

Any assist is appreciated.

Open a new issue in the STM32F1xx driver repo
https://github.com/grblHAL/STM32F1xx/issues for that.

P.S i have in the works custom board thatll use same pinout.

With which MCU? You should not design a board for the 128K flash versions
(medium density) as this has a stripped down version of grblHAL that is
likely to become unsupported soon. The high density versions are ok, but
you will get better performance out of STM32F3xx or STM32F4xx since these
are faster MCUs with a FPU.

—
Reply to this email directly, view it on GitHub
grblHAL/core#203 (reply in thread),
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AF5JEYD4JI5PAOEQRZZBGJLYFBTFRAVCNFSM6AAAAAARHDFMYGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TMMBVGMYTQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

Originally posted by @customsolutions in grblHAL/core#203 (comment)

Hello,

I use Blue Pill but try to re-map pins difference from CNC3040 and need UART1. This is a map file that I try to modifications and What other files do I need to edit?

#if N_ABC_MOTORS > 2 || N_GANGED
#error Axis configuration is not supported!
#endif

#if EEPROM_ENABLE
#error EEPROM plugin not supported!
#endif

#if N_AXIS == 5
#define BOARD_NAME "CNC 3040 5-axis"
#elif N_AXIS == 4
#define BOARD_NAME "CNC 3040 4-axis"
#else
#define BOARD_NAME "CNC 3040"
#endif

// Define step pulse output pins.
#define X_STEP_PORT GPIOA
#define X_STEP_PIN 5
#define Y_STEP_PIN 7
#define Z_STEP_PORT GPIOB
#define Z_STEP_PIN 1
#define STEP_OUTMODE GPIO_BITBAND

// Define step direction output pins.
#define X_DIRECTION_PORT GPIOA
#define X_DIRECTION_PIN 6
#define Z_DIRECTION_PORT GPIOB
#define Y_DIRECTION_PIN 0
#define Z_DIRECTION_PIN 10
#define DIRECTION_OUTMODE GPIO_BITBAND

// Define stepper driver enable/disable output pin.
#define STEPPERS_ENABLE_PORT GPIOB
#define STEPPERS_ENABLE_PIN 13

// Define homing/hard limit switch input pins.
#define LIMIT_PORT GPIOA
#define X_LIMIT_PIN 0
#define Y_LIMIT_PIN 1
#define Z_LIMIT_PIN 2
#define LIMIT_INMODE GPIO_SHIFT10

// Define ganged axis or A axis step pulse and step direction output pins.
#if N_ABC_MOTORS > 0
#define M3_AVAILABLE
#define M3_STEP_PORT GPIOB
#define M3_STEP_PIN 11
#define M3_DIRECTION_PORT GPIOB
#define M3_DIRECTION_PIN 12
#define M3_LIMIT_PORT GPIOA
#define M3_LIMIT_PIN 3
#endif

// Define ganged axis or B axis step pulse and step direction output pins.
#if N_ABC_MOTORS == 2
#define M4_AVAILABLE
#define M4_STEP_PORT GPIOB
#define M4_STEP_PIN 14
#define M4_DIRECTION_PORT GPIOB
#define M4_DIRECTION_PIN 15
#define M4_LIMIT_PORT GPIOA
#define M4_LIMIT_PIN 4
#endif

// Define spindle enable and spindle direction output pins.
#define SPINDLE_ENABLE_PORT GPIOA
#define SPINDLE_ENABLE_PIN 8
#define SPINDLE_DIRECTION_PORT GPIOA
#define SPINDLE_DIRECTION_PIN 9

// Define spindle PWM output pin.
#define SPINDLE_PWM_PORT_BASE GPIOA_BASE
#define SPINDLE_PWM_PIN 10

// Define flood and mist coolant enable output pins.
#define COOLANT_FLOOD_PORT GPIOB
#define COOLANT_FLOOD_PIN 3
#define COOLANT_MIST_PORT GPIOA
#define COOLANT_MIST_PIN 15

// Define user-control controls (cycle start, reset, feed hold) input pins.
#define CONTROL_PORT GPIOB
#define RESET_PIN 9
#define CYCLE_START_PIN 5
#define CONTROL_PORT GPIOC
#define FEED_HOLD_PIN 14
#if SAFETY_DOOR_ENABLE
#define SAFETY_DOOR_PIN 15
#endif
#define CONTROL_INMODE GPIO_BITBAND

// Define probe switch input pin.
#define PROBE_PORT GPIOB
#define PROBE_PIN 8

#if KEYPAD_ENABLE == 1
#error I2C keypad mode is not supported!
#endif

HI.

I found the following code in the STM32F1xx/Src/driver.c file and have some questions

// Main stepper driver
void TIM2_IRQHandler(void)
{
    if ((STEPPER_TIMER->SR & TIM_SR_UIF) != 0)                  // check interrupt source
    {
        STEPPER_TIMER->SR = ~TIM_SR_UIF; // clear UIF flag
        hal.stepper.interrupt_callback();
    }
}

void TIM3_IRQHandler(void)
{
    PULSE_TIMER->SR &= ~TIM_SR_UIF;                 // Clear UIF flag

    if (PULSE_TIMER->ARR == pulse_delay)            // Delayed step pulse?
    {
        PULSE_TIMER->ARR = pulse_length;
        stepperSetStepOutputs(next_step_outbits);   // begin step pulse
        PULSE_TIMER->EGR = TIM_EGR_UG;
        PULSE_TIMER->CR1 |= TIM_CR1_CEN;
    } else
        stepperSetStepOutputs((axes_signals_t){0}); // end step pulse
}

I see that the pulses in grblHAL are generated by timer interrupts. The output pulse frequency of grblHAL is very high. Won't frequent entry into the timer interrupt interrupt the entire program's operation? Will this cause some signals to be ignored during the interrupt?

Best regards!

how to compile the stm32f103tx , because the only choice is only for stm32f103rc , if i debug it with rc , the file output is 144 kb which is cant be uploaded to stm32f103c8t6 since the max flash size for f103c8t6 is maximum 128kb, did i need to set the path & symbols ? if yes can u give me a clue the path & symbol please ?

I use STM32F103 MCU and try to compile it in the MDK environment, but there are many errors. After all, there are many users of the combination of STM32 and MDK. I hope to write a porting tutorial, thank you very much

$I
[VER:1.1f.20211203:]
[OPT:VNMZHSL,95,1024,4,0]
[NEWOPT:ENUMS,RT+,HOME,TC,SED,SD,YM]
[FIRMWARE:grblHAL]
[NVS STORAGE:*FLASH]
[DRIVER:STM32F103C8]
[DRIVER VERSION:211203]
[BOARD:BTT SKR MINI E3 V1.2 4-axis]
[PLUGIN:Trinamic v0.07]
[PLUGIN:SDCARD v1.04]
ok

$150
$150=16
ok

$150=32
ok

$150
$150=16
ok

$150=10
ok

$150
$150=16
ok

Hello again,

I'm playing around with the safety door function but I'm running into a problem.

When I enable the door with:

#define SAFETY_DOOR_ENABLE 1

...I can see the door input in the status and I can configure pullup and direction. Perfect so far.
Unfortunately the opening of the door-switch doesn't stop the program.

Sending 0x84 by software works perfectly. Is there anything I miss? Do I have to link the hardware door input to the 0x84-command?

I was trying to use the "hold/pause" input instead. That works ok, but I need to turn off the coolant as well (and "hold" just stops the motion)

Any hint for me?

The following error occurs, I try to compile when the SD card is activated, including the latest plugins modules for this card.

.........
Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\src\syscalls.o
Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\src\sysmem.o
Src\diskio.c:460:9: error: conflicting types for 'disk_read'
DRESULT disk_read (
^~~~~~~~~
In file included from Src\diskio.c:24:0:
FatFS/diskio.h:31:9: note: previous declaration of 'disk_read' was here
DRESULT disk_read (BYTE pdrv, BYTE* buff, LBA_t sector, UINT count);
^~~~~~~~~
Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\src\system_stm32f1xx.o
*** [.pio\build\BTT_SKR_MINI_E3_V20_USB\src\diskio.o] Error 1
Src\driver.c: In function 'HAL_IncTick':
Src\driver.c:1457:9: warning: implicit declaration of function 'disk_timerproc' [-Wimplicit-function-declaration]
disk_timerproc();
^~~~~~~~~~~~~~
Src\system_stm32f1xx.c:113:0: warning: "VECT_TAB_OFFSET" redefined
#define VECT_TAB_OFFSET 0x00000000U /*!< Vector Table base offset field.

:0:0: note: this is the location of the previous definition
===================================================================================== [FAILED] Took 5.45 seconds =====================================================================================

Environment Status Duration

BTT_SKR_MINI_E3_V20_USB FAILED 00:00:05.448
=============================================================================== 1 failed, 0 succeeded in 00:00:05.448 ===============================================================================

• The terminal process "C:\Users\myPC.platformio\penv\Scripts\platformio.exe 'run', '--environment', 'BTT_SKR_MINI_E3_V20_USB'" terminated with exit code: 1.
• Terminal will be reused by tasks, press any key to close it.

I recently set up GRBLHAL on a SKR Mini E3 V2.0 board and i am having issues inverting the step directions of an axis. Changing the values of $3 don't have any effect. Is there another way of inverting the axis direction or does this need to be done through physical wiring?

Can we use PA1 instead of PA8 as spindle pwm output?

Not an issue, more like a question.

I'm building a cheap board with an STM32F103CB. I'd like to have 5 axis.
On my board I'm using GPIOA for axis XYZA (Step and Dir), and GPIOB-0 and GPIOB-1 for the B-axis.
Jogging the B-axis results in a movement of X (which is hooked up to GPIOA0 and GPIOA1).

Is there a restriction in the usage of the ports? Do all STEP-pins have to be on the same port?
(The same with DIR-pins?).

And I tried to map the spindle-PWM to GPIOB-7, but that doesn't compile.

Maybe I should live with the CNC3040 pinout. Seems to compile fine.

I have a bunch of Creality 4.2.2 stm32f103ret6 boards from upgrading ender 3v2's I'm sure I'm not alone, was wondering if its possible to get grblhal on them they seem similar to the blue pill. I found schematics for it Jyers/Marlin#814 , I'm assuming a pin remap wouldn't be all that is needed ?

Processing BTT_SKR_MINI_E3_V20_USB (board: genericSTM32F103RC; platform: ststm32; framework: stm32cube)
---------------------------------------------------------------------------------------------------------------------------------------------------------Verbose mode can be enabled via -v, --verbose option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/genericSTM32F103RC.html
PLATFORM: ST STM32 (15.1.0) > STM32F103RC (48k RAM. 256k Flash)
HARDWARE: STM32F103RCT6 72MHz, 48KB RAM, 256KB Flash
DEBUG: Current (blackmagic) External (blackmagic, cmsis-dap, jlink, stlink)
PACKAGES:

• framework-stm32cubef1 1.8.4
• tool-ldscripts-ststm32 0.2.0
• toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
  LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
  LDF Modes: Finder ~ off, Compatibility ~ soft
  Found 51 compatible libraries
  Scanning dependencies...
  Dependency Graph
  |--
  |--
  |--
  |--
  |--
  |--
  |--
  |--
  |--
  |--
  |--
  Building in release mode
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_adc.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_adc_ex.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_can.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_cec.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_cortex.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_crc.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_dac.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_dac_ex.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_dma.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_eth.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_exti.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_flash.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_flash_ex.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_gpio.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_gpio_ex.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_hcd.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_i2c.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_i2s.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_irda.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_iwdg.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_mmc.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_nand.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_nor.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_pccard.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_pcd.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_pcd_ex.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_pwr.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_rcc.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_rcc_ex.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_rtc.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_rtc_ex.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_sd.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_smartcard.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_spi.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_sram.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_tim.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_tim_ex.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_uart.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_usart.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_hal_wwdg.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_ll_adc.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_ll_crc.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_ll_dac.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_ll_dma.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_ll_exti.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_ll_fsmc.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_ll_gpio.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_ll_i2c.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_ll_pwr.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_ll_rcc.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_ll_rtc.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_ll_sdmmc.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_ll_spi.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_ll_tim.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_ll_usart.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_ll_usb.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkHALDriver\Src\stm32f1xx_ll_utils.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\alarms.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\coolant_control.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\corexy.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\errors.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\gcode.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\grbllib.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\ioports.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\limits.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\maslow.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\motion_control.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\my_plugin.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\ngc_expr.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\ngc_params.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\nuts_bolts.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\nvs_buffer.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\override.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\pid.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\planner.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\protocol.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\regex.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\report.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\settings.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\sleep.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\spindle_control.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\state_machine.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\stepper.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\stream.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\system.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\tool_change.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib94d\grbl\wall_plotter.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib482\keypad\keypad.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\libcab\motors\trinamic.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib28b\odometer\odometer.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib0f3\sdcard\sdcard.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib0f3\sdcard\ymodem.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib4b5\Core\usbd_core.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib4b5\Core\usbd_ctlreq.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib4b5\Core\usbd_ioreq.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib50a\Class\CDC\Src\usbd_cdc.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib00a\App\usb_device.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib00a\App\usbd_cdc_if.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib00a\App\usbd_desc.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\liba6d\Target\usbd_conf.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib9cd\eeprom\eeprom_24AAxxx.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib9cd\eeprom\eeprom_24LC16B.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib6e0\trinamic\common.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib6e0\trinamic\tmc2130.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib6e0\trinamic\tmc2130hal.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib6e0\trinamic\tmc2209.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib6e0\trinamic\tmc2209hal.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib6e0\trinamic\tmc26x.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib6e0\trinamic\tmc5160.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib6e0\trinamic\tmc5160hal.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\lib6e0\trinamic\tmc_interface.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\src\btt_skr_mini_e3_2.0.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\src\diskio.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\src\driver.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\src\flash.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\src\i2c.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\src\main.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\src\serial.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\src\stm32f1xx_hal_msp.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\src\stm32f1xx_it.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\src\syscalls.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\src\sysmem.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\src\system_stm32f1xx.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\src\usb_serial.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkCMSISDevice\gcc\startup_stm32f103xe.o
  Compiling .pio\build\BTT_SKR_MINI_E3_V20_USB\FrameworkCMSISDevice\system_stm32f1xx.o
  Src\system_stm32f1xx.c:113:0: warning: "VECT_TAB_OFFSET" redefined
  #define VECT_TAB_OFFSET 0x00000000U /*!< Vector Table base offset field.

:0:0: note: this is the location of the previous definition
Archiving .pio\build\BTT_SKR_MINI_E3_V20_USB\libFrameworkCMSISDevice.a
Linking .pio\build\BTT_SKR_MINI_E3_V20_USB\firmware.elf
.pio/build/BTT_SKR_MINI_E3_V20_USB/lib0f3/sdcard/sdcard.o: In function file_read': sdcard.c:(.text.file_read+0xe): undefined reference to f_read'
.pio/build/BTT_SKR_MINI_E3_V20_USB/lib0f3/sdcard/sdcard.o: In function file_close': sdcard.c:(.text.file_close+0x8): undefined reference to f_close'
.pio/build/BTT_SKR_MINI_E3_V20_USB/lib0f3/sdcard/sdcard.o: In function file_open': sdcard.c:(.text.file_open+0x16): undefined reference to f_open'
.pio/build/BTT_SKR_MINI_E3_V20_USB/lib0f3/sdcard/sdcard.o: In function sd_cmd_unmount': sdcard.c:(.text.sd_cmd_unmount+0x28): undefined reference to f_mount'
.pio/build/BTT_SKR_MINI_E3_V20_USB/lib0f3/sdcard/sdcard.o: In function sdcard_on_program_completed': sdcard.c:(.text.sdcard_on_program_completed+0x12): undefined reference to f_lseek'
.pio/build/BTT_SKR_MINI_E3_V20_USB/lib0f3/sdcard/sdcard.o: In function sdcard_mount': sdcard.c:(.text.sdcard_mount+0x30): undefined reference to f_mount'
.pio/build/BTT_SKR_MINI_E3_V20_USB/lib0f3/sdcard/sdcard.o: In function scan_dir': sdcard.c:(.text.scan_dir+0x1a): undefined reference to f_opendir'
sdcard.c:(.text.scan_dir+0x38): undefined reference to f_readdir' sdcard.c:(.text.scan_dir+0x114): undefined reference to f_readdir'
sdcard.c:(.text.scan_dir+0x124): undefined reference to f_readdir' sdcard.c:(.text.scan_dir+0x176): undefined reference to f_closedir'
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\BTT_SKR_MINI_E3_V20_USB\firmware.elf] Error 1
============================================================== [FAILED] Took 18.81 seconds ==============================================================
Environment Status Duration

BTT_SKR_MINI_E3_V20_USB FAILED 00:00:18.808
========================================================= 1 failed, 0 succeeded in

Terminal will be reused by tasks, press any key to close it.

my platformio.ini file:
platformio.txt

Hello, does anyone have information on how to wire a z probe for the BTT skr mini E3 V2?

The X stepper runs as expected.
Y & Z, however run at about 1/4 of the proper speed, and distance.
If I flash the stock firmware, and run it, and then flash grblHAL, without removing power, the steppers will all work as expected. After removing power, Y and Z revert to moving slowly.
I have verified that the step pulses and enable signals are getting to the '2209s, they're just moving slower.
I find myself wondering if that X '2209 is getting written three times, and the others not at all?

Hi. I have successfully compiled this driver for the SKR Mini v1.1 after playing around with the mapping. In my_machine.h, USB_SERIAL_CDC is enabled, also in the platformio.ini as a build flags. I can confirm the the firmware is uploaded because the firmware.bin is now renamed to BIGTREETECH.bigtreetech, which is what happens when I upload Marlin firmware. What could possibly causes this error that I am getting here.

I am not that good in coding but if given some hint then I can try to find the issue.

Since it sounds like ill be doing this myself... Any suggestions of where to post regarding an error Im getting when I do the first build with out change in stmcubeide ".rodata' will not fit in region `FLASH'". I imported the stm32f1xx build, and copied the core, then build....... All fresh and no other builds in the work space.

Originally posted by @customsolutions in grblHAL/core#203 (comment)

I am using the latest updated version of grblhal software. my CNC machine suddenly stops while working
BOARD:BTT SKR MINI E3 V2.0 (alt2)

The ST USB code has a really crappy license, which makes it incompatible with GPLed software.

  * This software component is licensed by ST under Ultimate Liberty license
  * SLA0044, the "License"; You may not use this file except in compliance with
  * the License. You may obtain a copy of the License at:
  *                      www.st.com/SLA0044

Hi, I have created a mapping for this board and also updated the build env for platform IO. However, I am not able to reuse the available header for the limit switch as control pins. This board has both min and max limit pins so I try to use the min limit pins for the control.

limits

#define X_LIMIT_PORT GPIOA
#define X_LIMIT_PIN 2 //PA2
#define Y_LIMIT_PORT GPIOA
#define Y_LIMIT_PIN 1 //PA1
#define Z_LIMIT_PORT GPIOC
#define Z_LIMIT_PIN 3 //PC3
#define LIMIT_INMODE GPIO_BITBAND

and for control

#define CONTROL_PORT GPIOC
#define RESET_PIN 2 //PC2
#define FEED_HOLD_PIN 1 //PC1
#define CYCLE_START_PIN 0 //PC0

So it looks like it is re-using pins even if these pins are in different port. I always get this error from driver.c

#if DRIVER_IRQMASK != (LIMIT_MASK+CONTROL_MASK+I2C_STROBE_BIT)
#error Interrupt enabled input pins must have unique pin numbers!
#endif

How can I proceed with this.

Hi
Is it possible to support, 64 pin STM32F103RC with 256 Kbytes of Flash memory? so I want to use BTT SKR MINI E3 V2.0 3D printer board.
https://www.bigtree-tech.com/products/bigtreetech-skr-mini-e3-v2-0-32-bit-control-board-integrated-tmc2209-uart-for-ender-3.html

SKR MINI E3 V1.2 3D - difference from v 2.0

• no EEPROM
• some pins relocated

USB_CONN pin have to be pulled down after usbInit() to enable USB.

Schematic
MAP file: btt_skr_mini_e3_1.2_map.zip

"USB_SERIAL_CDC 1", " SDCARD_ENABLE 2" and "TRINAMIC_ENABLE 2209" works.

I have an oscilloscope, logic analyzer and Black Magic debugger so I can run some tests if needed.

Im trying to use grblhal on mach3 usb board. It has a stm32f103rct6 and needs pulldown on PC11.
i managed to work out the PC11 but i always get usb descriptor failed.
I already created a simple program using cubemx to test the usb and it works. I get a com port.

The board is

There is STM32CubeIDE warning:
Description Resource Path Location Type
Invalid project path: Missing project folder or file: \GRBL Driver STM32F103C8\FatFS for Source path. GRBL Driver STM32F103C8 pathentry Path Entry Problem

Can be solved by renaming FatFs to FatFS.

Running STM32F103RCT6 on a red rnr MACH3BOB. Working fine but the only issue is once in awhile I'll get
error:7 - A settings read failed. Auto-restoring affected settings to default values.
on power up and it loads all the default settings again.. I than have to load them up. Is there a setting to prevent restoring the defaults?
Thanks Jim

[VER:1.1f.20230903:]
[OPT:VNMSL,35,1024,4,0]
[AXS:4:XYZA]
[NEWOPT:ENUMS,RT+,ES,SED]
[FIRMWARE:grblHAL]
[NVS STORAGE:*FLASH]
[DRIVER:STM32F103RC]
[DRIVER VERSION:230828]
[BOARD:MACH3 USB BOB (BSMCE04U)]
[AUX IO:0,1,0,0]
[CLUSTER:16]
[PLUGIN:LightBurn clusters v0.04]
[G54:0.000,0.000,0.000,0.000]
[G55:0.000,0.000,0.000,0.000]
[G56:0.000,0.000,0.000,0.000]
[G57:0.000,0.000,0.000,0.000]
[G58:0.000,0.000,0.000,0.000]
[G59:0.000,0.000,0.000,0.000]
[G59.1:0.000,0.000,0.000,0.000]
[G59.2:0.000,0.000,0.000,0.000]
[G59.3:0.000,0.000,0.000,0.000]
[G28:0.000,0.000,0.000,0.000]
error:7 - A settings read failed. Auto-restoring affected settings to default values.
[MSG:Warning: Settings write failed!]

Errors:
'reg_ptr' undeclared (first use in this function) trinamic.c /GRBL Driver STM32F103C8/motors line 774
'reg_ptr' undeclared (first use in this function) trinamic.c /GRBL Driver STM32F103C8/motors line 874
'stepper[report.sg_status_motor]' is a pointer; did you mean to use '->'? trinamic.c /GRBL Driver STM32F103C8/motors line 690
'tmc5160_regaddr_t' undeclared (first use in this function) trinamic.c /GRBL Driver STM32F103C8/motors line 774
expected ')' before 'gc_block' trinamic.c /GRBL Driver STM32F103C8/motors line 774 C/C++ Problem

The processor seems to be driving SWCLK, and SWDIO low. This pretty well kills the SWD debugger.
The stock firmware has a two-second delay after reset before driving SWCLK low, (which in turn pulls up USB D+). SWDIO is not driven low with the stock firmware.
I've tried lifting the BOOT0 pin (it's tied directly to GND) and pulling it high. After a reset, SWCLK and SWDIO are high, and the debug session will start, but fail at the end. (Possibly because the processor is not executing the expected code.)
Perhaps a delay similar to the stock firmware could be implemented? (debug-by-printf and swapping sd cards is getting old)

I'd like to try out the code for the BTT SKR E3 Mini v2.0 board that's being worked on in #2. I understand that Eclipse is grblHAL's IDE of choice but I'd prefer to use something that's less of an investment for me, such as standard Linux/macOS and Python package managers.

Since you mentioned PlatformIO in the other thread, I've explored this route and it seems attractive because:

• platform run (build process) downloads the appropriate platform toolchain and SDK framework automatically
• you can filter source files (not used below)
• it supports overriding weak symbols for libraries (not sure if STM32CubeMX makes use of these though?)
• it can be quickly installed and works out-of-the-box via the command line on Linux and macOS (good for me)

(PlatformIO expects source code in the src/ directory and libraries, such as grbl or motors, in their own directories below lib/, but it's possible to workaround this with include_dir, src_dir, build_flags and lib_extra_dirs.)

So far I've come up with the following platformio.ini file:

# file: platformio.ini
[platformio]
default_envs = BTT_SKR_MINI_E3_V20
include_dir = Inc
src_dir = Src

[common]
build_flags = 
  -I Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Inc
  -I Middlewares/ST/STM32_USB_Device_Library/Core/Inc
  # various source code does `#include "grbl/*.h"`
  -I .
  # code under Src does `#include "grbl.h"`
  #-I grbl
lib_deps =
  Class
  Core
  grbl
  motors
lib_extra_dirs =
  # this is so we can lib_deps=grbl eeprom motors
  . 
  Middlewares/ST/STM32_USB_Device_Library/Class
  Middlewares/ST/STM32_USB_Device_Library

[env]
platform = ststm32
framework = stm32cube
# Do not produce .a files for lib deps (which would prevent them from overriden weak symbols)
lib_archive = no

[env:BTT_SKR_MINI_E3_V20]
# See also: GRBL Driver STM32F103C8.ioc
board = genericSTM32F103RC
#board_build.ldscript = TBD
build_flags =
  ${common.build_flags}
  # Values from Inc/my_machine.h
  -D BTT_SKR_MINI_E3_V20=
  -D EEPROM_ENABLE=1
lib_deps =
  ${common.lib_deps}
  eeprom
  trinamic
lib_extra_dirs =
  ${common.lib_extra_dirs}

With this file in the root of the project dir, PlatformIO core (CLI) installed, you can start building the project with:

platform run -v

1. The ARM GCC toolchain trips on the use of backslashes in header includes in trinamic/. I posted a fix in Backslashes in include header paths is practically UB.

2. The compilation fails due to seemingly missing USB related .{c,h} files. I haven't used STM32CubeMX before so I hoped I could just find similarly named files for the expected version (assuming v1.7.0 based on GRBL Driver STM32F103C8.ioc) in the GitHub organization. Unfortunately I wasn't 100% successful with this approach.

I noted that you've previously committed "add missing USB files" in other projects in the GitHub org so perhaps that's necessary in this repo as well? I note that .mxproject appears to list some (or maybe all?) of these files that appears to be missing:

	Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Inc/usbd_cdc_if.h
	Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Src/usbd_cdc_if.c
	Middlewares/ST/STM32_USB_Device_Library/Core/Inc/usb_device.h
	Middlewares/ST/STM32_USB_Device_Library/Core/Inc/usbd_conf.h
	Middlewares/ST/STM32_USB_Device_Library/Core/Src/usbd_conf.c

(I suspect that usb_device.c is missing too, I just didn't come that far with the compilation)

Any chance that you can help locate these files?

Thanks!

HI.

I am using an STM32F103RCT6 development board, I have not made any changes to the project code, I only modified the platformio.ini file, then compiled the project, and used Jink to upload the firmware to my STM32F103RCT6. However, when I plug in the USB cable to my PC, my PC tells me 'Windows has stopped this device because it has reported problems. (Code 43)'. I am not sure why this is happening.

The following is the code for my platformio.ini file:

# This is the configuration file for PlatformIO, a cross-platform tool and IDE
# to build and develop software for embedded systems.
#
# To build the firmware with PlatformIO, install PlatformIO Core (CLI, no GUI):
# - https://docs.platformio.org/en/latest//core/installation.html
#
# For documentation on this file, see:
# - https://docs.platformio.org/en/latest/projectconf/index.html
#
# To add support for another STM32F1xx board, add a new [env:name..] section
# with the appropriate `board` and (optionally) `board_build.ldscript`.
# For a list of supported hardware, see:
# - https://docs.platformio.org/en/latest/platforms/ststm32.html
#
# To add support for additional grblHAL plugins or drivers, make the necessary
# changes to the common.build_flags, common.lib_deps and common.lib_extra_dirs
# below.
#
# By default this file sets the preprocessor directive `OVERRIDE_MY_MACHINE`
# to ignore all settings in `Inc/my_machine.h`.  Instead, you should edit this
# file and add the necessary directives (e.g. `-D FOOBAR_ENABLE`) to either
# `common.build_flags` or the environment specific `build_flags`.
#
# Typical command line usage:
#
#    # Build firmware for all defined environments
#    pio run
#    # Build only for specific environments with the -e option
#    pio run -e BTT_SKR_MINI_E3_V20 -e BTT_SKR_MINI_E3_V20_USB
#    # List the freshly built firmware ELF (.elf) and binary (.bin) files:
#    ls -l .pio/build/*/firmware.*
#    # If the target supports uploading (via `upload_protocol`):
#    pio run -e bluepill_f103c8_128k -t upload
#    # Clean up build related resources
#    pio run -t clean
#
[platformio]
include_dir = Inc
src_dir = Src

[common]
build_flags =
  -I .
  -I FatFs
  -I Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Inc
  -I Middlewares/ST/STM32_USB_Device_Library/Core/Inc
  -I USB_DEVICE/Target
  -D RX_BUFFER_SIZE=512
  -D NVS_SIZE=1536
  # Ignore all settings in Inc/my_machine.h (and instead use the below build flags)
  -D OVERRIDE_MY_MACHINE
  # Uncomment to enable debug builds
  #-D DEBUG
  # Uncomment to enable support for keypad
  #-D KEYPAD_ENABLE=1
  # Uncomment to enable support for odometer
  #-D ODOMETER_ENABLE=1
  # Uncomment to enable support for running G-code from the microSD card
  # You also need to uncomment FatFs and sdcard in lib_deps (see below)
  #-D SDCARD_ENABLE=1
lib_deps =
  grbl
  keypad
  motors
  odometer
# To enable support for SD card uncomment `FatFs` and `sdcard` below.
  #FatFs
  #sdcard
  # USB serial support
  Core
  Class
  App
  Target
lib_extra_dirs =
  .
  FatFs
  Middlewares/ST/STM32_USB_Device_Library
  USB_DEVICE

[env]
platform = ststm32
framework = stm32cube
# Do not produce .a files for lib deps (which would prevent them from overriding weak symbols)
lib_archive = no
lib_ldf_mode = off


; [env:BTT_SKR_MINI_E3_V20]
; board = genericSTM32F103RC
; board_build.ldscript = STM32F103RCTX_FLASH.ld
; build_flags = ${common.build_flags}
;   # See Inc/my_machine.h for options
;   -D BTT_SKR_MINI_E3_V20=
;   -D USB_SERIAL_CDC=0
;   # Relocate the vector table where the boot loader expects to find them
;   -D VECT_TAB_OFFSET=0x7000
;   -Wl,--defsym=LD_VECT_TAB_OFFSET=0x7000
; lib_deps = ${common.lib_deps}
;   eeprom
;   trinamic
; lib_extra_dirs = ${common.lib_extra_dirs}
; # Upload is not supported for this board since BOOT0 is tied to GND.
; # With the default boot loader, you must deploy new firmware by copying
; # .pio/build/<env name>/firmware.bin (produced by `pio run`) to the SD card.

[env:BTT_SKR_MINI_E3_V20_USB]
board = genericSTM32F103RC
board_build.ldscript = STM32F103RCTX_FLASH.ld
build_flags = ${common.build_flags}
  # See Inc/my_machine.h for options
  -D BTT_SKR_MINI_E3_V20=
  -D USB_SERIAL_CDC=1
  # Relocate the vector table where the boot loader expects to find them
  -D VECT_TAB_OFFSET=0x7000
  -Wl,--defsym=LD_VECT_TAB_OFFSET=0x7000
lib_deps = ${common.lib_deps}
  eeprom
  trinamic
lib_extra_dirs = ${common.lib_extra_dirs}
upload_protocol = jlink
# Upload is not supported for this board since BOOT0 is tied to GND.
# With the default boot loader, you must deploy new firmware by copying
# .pio/build/<env name>/firmware.bin (produced by `pio run`) to the SD card.

; [env:bluepill_f103c8_128k]
; board = bluepill_f103c8_128k
; board_build.ldscript = STM32F103C8TX_FLASH.ld
; build_flags = ${common.build_flags}
;   # See Inc/my_machine.h for options
;   -D BOARD_CNC3040=
;   -D USB_SERIAL_CDC=0
; lib_deps = ${common.lib_deps}
;   eeprom
; lib_extra_dirs = ${common.lib_extra_dirs}
; upload_protocol = stlink

; [env:bluepill_f103c8_128k_USB]
; board = bluepill_f103c8_128k
; board_build.ldscript = STM32F103C8TX_FLASH.ld
; build_flags = ${common.build_flags}
;   # See Inc/my_machine.h for options
;   -D BOARD_CNC3040=
;   -D NO_SETTINGS_DESCRIPTIONS=
;   -D USB_SERIAL_CDC=1
; lib_deps = ${common.lib_deps}
;   eeprom
; lib_extra_dirs = ${common.lib_extra_dirs}
; upload_protocol = stlink

The software was not stable. I compiled software for MACH3 bob board, and I had strange behaviour. (option no compiler optimisation). I found the following error in the STM32F103RCTX_FLASH.ld :
EEPROM_EMUL(xrw) : ORIGIN = 0x802F000 -> is inside the firmware space
FLASH(rx) : ORIGIN = 0x8000000+LD_VECT_TAB_OFFSET, LENGTH = 256K-2K-LD_VECT_TAB_OFFSET -> reserved Flash memory siez is 4K and not 2k.

you must have :
MEMORY
{
RAM(xrw) : ORIGIN = 0x20000000, LENGTH = 48K
EEPROM_EMUL(xrw) : ORIGIN = 0x803F000, LENGTH = 4K
FLASH(rx) : ORIGIN = 0x8000000+LD_VECT_TAB_OFFSET, LENGTH = 256K-4K-LD_VECT_TAB_OFFSET
}

This modifications solve the problem.

I figured out what the ioc file is used for and loading it in CubeIDE loaded a visualization of the pin assignments and I see USART_TX on PA9 and USART_RX on PA10. I built and uploaded the firmware and connected a 3.3v FTDI Rx pin to PA9 and see no grbl output.
I have set compatibility to 1 in config.h and I tried USB_ENABLE to both 0 and 1 and neither results in any grbl header echoed out USART_TX pin.

To test, I uploaded a grbl32 firmware and upon powerup saw grbl setting and version dump. So the board and aux port is operational.

CubeIDE Symbols:
USE_HAL_DRIVER
STM32F103xB
RX_BUFFER_SIZE 512
NVS_SIZE 1536
NO_SETTINGS_DESCRIPTIONS
OVERRIDE_MY_MACHINE
BOARD_CNC3040
USB_ENABLE 1
N_AXIS 3

I successfully installed GRBLHal on the BOB Mach3 board, but the Stepper Dynamo buzzes and vibrates a bit when using the A4988 driver and drv 8825, but it can run GCode perfectly, is there any solution to prevent the Stepper dynamo from vibrating and buzzing?

Hello,

I am using a reprogrammed Mach3 BOB which works great for my mini mill.

The only issue I found is that when the e-stop is active, I am still able to jog the machine.
The e-stop is detected by grblHAL and reported by ioSender as a red square above the E or the R letter, depending on configuration. The controller does not seem to enter alarm state.

I tried many build configurations with ESTOP_ENABLE set and unset, building with the web interface, PlatformIO and STCube. The issue happens in all cases (e-stop becomes reset when the flag is set to 0, but still no alarm state and I am able to jog the machine).

I also have a Teensy board and the problem does not happen there, despite very similar flag settings/configurations.

There are many STM32F1 based boards made for Mach3 that can be reprogrammed with grblHAL firmware. Currently I have this one:

DDMACH V5.0

It's based on STM32F105VCT6. Where to begin with? I can easily trace pinout.