Building grblHAL with PlatformIO

[noahwilliamsson]

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!

[terjeio]

1. Merged
2. Missing files added, note that they were moved to the USB_DEVICE directory when I updated to the latest ST driver code.

Note that the library code should not be regenerated using the .ioc file as I have modified the generated code to make it work with grblHAL.

The STM32F103RCTX_FLASH.ld linker script has to be used for linking for the BTT_SKR_MINI_E3_V20 board, STM32F103C8TX_FLASH.ld for all the others,

[noahwilliamsson]

Thanks!

With an updated platformio.ini file I managed to compile it. I have yet to test it out.

[platformio]
include_dir = Inc
src_dir = Src

[common]
build_flags =
  -I .
  -I Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Inc
  -I Middlewares/ST/STM32_USB_Device_Library/Core/Inc
  -I USB_DEVICE/Target
lib_deps =
  grbl
  keypad
  motors
  odometer
  sdcard
  # USB
  Core
  Class
  App
  Target
lib_extra_dirs =
  . 
  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
debug_tool = stlink
upload_protocol = stlink

[env:BTT_SKR_MINI_E3_V20]
# Upload is not supported for this board as BOOT0 is tied to GND
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 EEPROM_ENABLE=1
lib_deps =
  ${common.lib_deps}
  eeprom
  trinamic
lib_extra_dirs = ${common.lib_extra_dirs}

[env:bluepill]
board = bluepill_f103c8_128k
board_build.ldscript = STM32F103C8TX_FLASH.ld
build_flags =
  ${common.build_flags}
  -D EEPROM_ENABLE=1
lib_deps =
  ${common.lib_deps}
  eeprom
lib_extra_dirs = ${common.lib_extra_dirs}

Example output:

% platformio run -v 
Processing BTT_SKR_MINI_E3_V20 (board: genericSTM32F103RC; board_build.ldscript: STM32F103RCTX_FLASH.ld; build_flags: -I ., -I Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Inc, -I Middlewares/ST/STM32_USB_Device_Library/Core/Inc, -I USB_DEVICE/Target, -D BTT_SKR_MINI_E3_V20=, -D EEPROM_ENABLE=1; lib_deps: grbl, keypad, motors, odometer, Core, Class, App, Target, eeprom, trinamic; lib_extra_dirs: ., Middlewares/ST/STM32_USB_Device_Library, USB_DEVICE; platform: ststm32; framework: stm32cube; lib_archive: False; lib_ldf_mode: off)
------------------------------------------------------------------------------------------------------------------------------------
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/genericSTM32F103RC.html
PLATFORM: ST STM32 (14.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.3 
 - tool-ldscripts-ststm32 0.1.0 
 - toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ off, Compatibility ~ soft
Found 50 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <grbl> (/private/tmp/STM32F1xx/grbl)
|-- <keypad> (/private/tmp/STM32F1xx/keypad)
|-- <motors> (/private/tmp/STM32F1xx/motors)
|-- <odometer> (/private/tmp/STM32F1xx/odometer)
|-- <Core> (/private/tmp/STM32F1xx/Middlewares/ST/STM32_USB_Device_Library/Core)
|-- <Class> (/private/tmp/STM32F1xx/Middlewares/ST/STM32_USB_Device_Library/Class)
|-- <App> (/private/tmp/STM32F1xx/USB_DEVICE/App)
|-- <Target> (/private/tmp/STM32F1xx/USB_DEVICE/Target)
|-- <eeprom> (/private/tmp/STM32F1xx/eeprom)
|-- <trinamic> (/private/tmp/STM32F1xx/trinamic)
Building in release mode
MethodWrapper(["checkprogsize"], [".pio/build/BTT_SKR_MINI_E3_V20/firmware.elf"])
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [====      ]  35.7% (used 17556 bytes from 49152 bytes)
Flash: [=====     ]  48.2% (used 126304 bytes from 262144 bytes)
.pio/build/BTT_SKR_MINI_E3_V20/firmware.elf  :
section               size        addr
.isr_vector            484   134217728
.text               104420   134218216
.rodata              20776   134322640
.ARM.extab               0   134343416
.ARM                     0   134343416
.preinit_array           0   134343416
.init_array              4   134343416
.fini_array              4   134343420
.data                 1108   536870912
.bss                 16448   536872020
._user_heap_stack     9220   536888468
.ARM.attributes         41           0
.comment               126           0
.debug_frame          5664           0
Total               158295
=================================================== [SUCCESS] Took 1.10 seconds ===================================================

Processing bluepill (board: bluepill_f103c8_128k; board_build.ldscript: STM32F103C8TX_FLASH.ld; build_flags: -I ., -I Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Inc, -I Middlewares/ST/STM32_USB_Device_Library/Core/Inc, -I USB_DEVICE/Target, -D EEPROM_ENABLE=1; lib_deps: grbl, keypad, motors, odometer, sdcard, Core, Class, App, Target, eeprom; lib_extra_dirs: ., Middlewares/ST/STM32_USB_Device_Library, USB_DEVICE; platform: ststm32; framework: stm32cube; lib_archive: False; lib_ldf_mode: off; debug_tool: stlink; upload_protocol: stlink)
------------------------------------------------------------------------------------------------------------------------------------
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/bluepill_f103c8_128k.html
PLATFORM: ST STM32 (14.1.0) > BluePill F103C8 (128k)
HARDWARE: STM32F103C8T6 72MHz, 20KB RAM, 128KB Flash
DEBUG: Current (stlink) External (blackmagic, cmsis-dap, jlink, stlink)
PACKAGES: 
 - framework-stm32cubef1 1.8.3 
 - tool-ldscripts-ststm32 0.1.0 
 - toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ off, Compatibility ~ soft
Found 50 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <grbl> (/private/tmp/STM32F1xx/grbl)
|-- <keypad> (/private/tmp/STM32F1xx/keypad)
|-- <motors> (/private/tmp/STM32F1xx/motors)
|-- <odometer> (/private/tmp/STM32F1xx/odometer)
|-- <sdcard> (/private/tmp/STM32F1xx/sdcard)
|-- <Core> (/private/tmp/STM32F1xx/Middlewares/ST/STM32_USB_Device_Library/Core)
|-- <Class> (/private/tmp/STM32F1xx/Middlewares/ST/STM32_USB_Device_Library/Class)
|-- <App> (/private/tmp/STM32F1xx/USB_DEVICE/App)
|-- <Target> (/private/tmp/STM32F1xx/USB_DEVICE/Target)
|-- <eeprom> (/private/tmp/STM32F1xx/eeprom)
Building in release mode
MethodWrapper(["checkprogsize"], [".pio/build/bluepill/firmware.elf"])
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [========  ]  76.4% (used 15656 bytes from 20480 bytes)
Flash: [========= ]  85.0% (used 111464 bytes from 131072 bytes)
.pio/build/bluepill/firmware.elf  :
section               size        addr
.isr_vector            268   134217728
.text                90980   134218000
.rodata              19416   134308984
.ARM.extab               0   134328400
.ARM                     0   134328400
.preinit_array           0   134328400
.init_array              4   134328400
.fini_array              4   134328404
.data                 1068   536870912
.bss                 14588   536871980
._user_heap_stack     4096   536886568
.ARM.attributes         41           0
.comment               126           0
.debug_frame          5280           0
Total               135871
=================================================== [SUCCESS] Took 1.15 seconds ===================================================

[terjeio]

Great, I guess a new linker script should be added so that a/the bootloader can be used to program the chip? See issue #3.

The MEMORY and possibly .isr_vector settings has to be changed for that? Here is code from the F4xx driver that could be a useful hint of what to change:

/* Memories definition */
MEMORY
{
  RAM    (xrw)    : ORIGIN = 0x20000000,   LENGTH = 64K
  BOOT_FLASH    (rx)    : ORIGIN = 0x8000000,   LENGTH = 16K
  EEPROM_EMUL(xrw)      : ORIGIN = 0x8004000,   LENGTH = 16K
  FLASH    (rx)    : ORIGIN = 0x8008000,   LENGTH = 224K
}

/* Sections */
SECTIONS
{
  /* The startup code into "FLASH" Rom type memory */
  .isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector)) /* Startup code */
    . = ALIGN(4);
  } >BOOT_FLASH

As I do not own a board I can test with and since linker scripts is something I am not used to work with it is not possible for me to tell what correct settings should be.

[noahwilliamsson]

Apologies for the delay, I've spent some time trying to figure out why I couldn't boot the file PlatformIO produced on my pristine SKR Mini E3 V2.0 board. No USB device showed up, there was no output on USART1 and no pins could be toggled despite placing the relevant HAL_GPIO_*() calls right before grbl_enter(). Additionally, my ST-Link V2 clone was unable to connect to the board via SWD (couldn't connect to target, and no success with --connect-under-reset -- likely due to the lack of an nRST pin).

I'm not sure what kind of boot loader these boards are using out of the box. My only experience with flashing these boards is by placing a firmware.bin file on the SD card. Once you power up the board, it will flash the contents of this file, rename it to FIRMWARE.CUR and reset.

FWIW, the firmware.bin is produced from an ELF file using a command such as ~/.platformio/packages/toolchain-gccarmnoneeabi/arm-none-eabi/bin/objcopy -O firmware.bin firmware.elf. When compiling with PlatformIO, both of these files are created automatically (e.g. .pio/build/<env name>/firmware.{bin,elf}).

I took a few days before I realized that I had to add a 28KB (0x7000) offset to both the flash ORIGIN in the linker script AND to Src/system_stm32f1xx.c:VECT_TAB_OFFSET to make it work (and to understand your comment about the boot loader/linker script -- thanks!).

I'm not sure what kind of boot loader that ships with these boards out of the box, if it's a standard one or something else, but this is what I found out from studying https://github.com/bigtreetech/BIGTREETECH-SKR-mini-E3.

With that in place, I was able to get a grblHAL prompt via USART1 with USB serial turned off.

Next, I couldn't get -D USB_SERIAL_CDC=1 to work. It seems there's a MOSFET transistor between SWCLK (PA14) and USB D+ (PA12) whose purpose or function I don't understand (except that it breaks SWD if you're powering the board via USB instead of 12/24V DCIN..).

Also, it seems these ST-Link v2 clones doesn't come with an nRST pin (only a reset pin for STM8) so I've ordered a ST-LINK/V3SET and a Nucleo F411RE (STLINK-V2-1) in the hope that it will make things easier in the future.

As for programming the chip via the boot loader, I haven't really looked into it, but I'll note that Klipper's boot loader notes for STM32 says:

The HID bootloader is a compact, driverless bootloader capable of flashing over USB. Also available is a fork with builds specific to the SKR Mini E3 1.2.

For generic STM32F103 boards such as the blue pill it is possible to flash the bootloader via 3.3v serial using stm32flash as noted in the stm32duino section above, substituting the file name for the desired hid bootloader binary (ie: hid_generic_pc13.bin for the blue pill).

It is not possible to use stm32flash for the SKR Mini E3 as the boot0 pin is tied directly to ground and not broken out via header pins.

(via BTT SKR MINI E3 V2.0SCHpdf.PDF).

As I understand application note AN2586, this means that it will boot from Main Flash memory (and optionally by programming the chip via SWD, assuming that works with a proper ST-Link device).

With that said, I've come up with the following changes:

STM32F103RCTX_FLASH.ld:

diff --git a/STM32F103RCTX_FLASH.ld b/STM32F103RCTX_FLASH.ld
index cbc801e..e56563e 100644
--- a/STM32F103RCTX_FLASH.ld
+++ b/STM32F103RCTX_FLASH.ld
@@ -33,11 +33,14 @@ _estack = ORIGIN(RAM) + LENGTH(RAM);    /* end of "RAM" Ram type memory */
 _Min_Heap_Size = 0x2000; /* required amount of heap  */
 _Min_Stack_Size = 0x400;    /* required amount of stack */

+/* Dummy symbol we can override using -Wl,--defsym on the command line */
+LD_VECT_TAB_OFFSET = DEFINED(LD_VECT_TAB_OFFSET)? LD_VECT_TAB_OFFSET : 0;
+
 /* Memories definition */
 MEMORY
 {
   RAM    (xrw)    : ORIGIN = 0x20000000,   LENGTH = 48K
-  FLASH    (rx)    : ORIGIN = 0x8000000,   LENGTH = 256K
+  FLASH    (rx)    : ORIGIN = 0x8000000 + LD_VECT_TAB_OFFSET,   LENGTH = 256K - LD_VECT_TAB_OFFSET - 2*2K
 }

and

Src/system_stm32f1xx.c:

diff --git a/Src/system_stm32f1xx.c b/Src/system_stm32f1xx.c
index af3759a..d59da48 100644
--- a/Src/system_stm32f1xx.c
+++ b/Src/system_stm32f1xx.c
@@ -110,8 +110,10 @@
 /*!< Uncomment the following line if you need to relocate your vector Table in
      Internal SRAM. */ 
 /* #define VECT_TAB_SRAM */
+#if !defined (VECT_TAB_OFFSET)
 #define VECT_TAB_OFFSET  0x00000000U /*!< Vector Table base offset field. 
                                   This value must be a multiple of 0x200. */
+#endif

By allowing both the compile time VECT_TAB_OFFSET define to be overriden on the command line (-D VECT_TAB_OFFSET=...) and the link time symbol LD_VECT_TAB_OFFSET to be overriden on the command line (-Wl,--defsym=LD_VECT_TAB_OFFSET=...), I'm hoping this will work both with Eclipse (without changes) and with PlatformIO (using additional build flags).

Another option would be to define a board specific VECT_TAB_OFFSET and split up the link scripts, possibly by taking advantage of GNU ld's support for includes (to include common sections).

What do you think?

Next, to get USB serial working on this board, I've simply made the following change to Src/main.c:

diff --git a/Src/main.c b/Src/main.c
index 1786291..9435b5f 100644
--- a/Src/main.c
+++ b/Src/main.c
@@ -36,6 +36,14 @@ int main(void)
     __HAL_RCC_GPIOB_CLK_ENABLE();
     __HAL_RCC_GPIOC_CLK_ENABLE();

+    GPIO_InitTypeDef GPIO_Init = {
+        .Mode = GPIO_MODE_OUTPUT_PP,
+        .Pin = GPIO_PIN_14,
+        .Speed = GPIO_SPEED_FREQ_LOW,
+    };
+    HAL_GPIO_Init(GPIOA, &GPIO_Init);
+    HAL_GPIO_WritePin(GPIOA, GPIO_PIN_14, GPIO_PIN_RESET);
+
     grbl_enter();
 }

Obviously this is a kludge, but what would be the proper way of initializing output pins with some specific value in grblHAL? Can they be added to Src/driver.c somehow?

Finally, to enable support for building grblHAL for SKR Mini E3 V2.0 with PlatformIO, I've made the following changes. Please note that I disabled USB serial by default (not really userfriendly) in order to be able to build both a version with 3.3V serial and a version with USB serial.

Inc/my_machine.h:

diff --git a/Inc/my_machine.h b/Inc/my_machine.h
index 4cd93d6..875e629 100644
--- a/Inc/my_machine.h
+++ b/Inc/my_machine.h
@@ -29,7 +29,7 @@
 // Configuration
 // Uncomment to enable.

-#define USB_SERIAL_CDC       1 // Serial communication via native USB. Comment out for UART communication.
+//#define USB_SERIAL_CDC       1 // Serial communication via native USB. Comment out for UART communication.
 //#define SDCARD_ENABLE      1 // Run gcode programs from SD card, requires sdcard plugin.
 //#define KEYPAD_ENABLE      1 // I2C keypad for jogging etc., requires keypad plugin.
 //#define ODOMETER_ENABLE    1 // Odometer plugin.

platformio.ini:

[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
lib_deps =
  grbl
  keypad
  motors
  odometer
# To enable support for SD card, you must grab a copy FatFS:
#   curl -O http://elm-chan.org/fsw/ff/arc/ff14b.zip
#   unzip ff14b.zip 'source/*'
#   mv source FatFS
# ..before uncommenting the below option
# sdcard
  # For USB serial support
  Core
  Class
  App
  Target
lib_extra_dirs =
  . 
  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 EEPROM_ENABLE=3
  -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 EEPROM_ENABLE=3
  -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 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.

With these changes in place, you can:

(cd trinamic && git checkout master && git pull)   # the submodule have yet to be updated
pio run     # build all envs (or a single one: -e BTT_SKR_MINI_E3_V20_USB)

This will produce the following files:

% ls -1  .pio/build/BTT*/firmware.*  
.pio/build/BTT_SKR_MINI_E3_V20/firmware.bin
.pio/build/BTT_SKR_MINI_E3_V20/firmware.elf
.pio/build/BTT_SKR_MINI_E3_V20_USB/firmware.bin
.pio/build/BTT_SKR_MINI_E3_V20_USB/firmware.elf

I'd be happy to contribute a PR to enable support for PlatformIO in this repo assuming you're interested and the quirks mentioned above can be worked out. I might be able to take a stab at the same thing for the STM32F4xx repo once the Nucleo board I ordered shows up.

[terjeio]

Apologies for the delay

No problem, it is great that you spent time on this.

By allowing both the compile time VECT_TAB_OFFSET define to be overriden on the command line (-D VECT_TAB_OFFSET=...) and the link time symbol LD_VECT_TAB_OFFSET to be overriden on the command line (-Wl,--defsym=LD_VECT_TAB_OFFSET=...), I'm hoping this will work both with Eclipse (without changes) and with PlatformIO (using additional build flags).

In Eclipse it is easy add build configurations that has different symbols etc. The LPC176x driver has one for building a bootloader-friendly version.

FYI if the symbol OVERRIDE_MY_MACHINE is defined all options in my_machine.h can be moved to platformio.ini. What has been discussed before was to add a web-based build system where the user selected a processor or board to build for and then options for that. Click "Build" and you get a binary ready for flashing... It will be a lot of work to implement, but at least the basic stuff to allow it has been put in place. Note that options in grbl/config.h can also be set via command line defined symbols, their default values has been moved to grbl/defaults.h.

Please note that I disabled USB serial by default (not really userfriendly) in order to be able to build both a version with 3.3V serial and a version with USB serial.

I believe USB serial should be enabled by default as is now, to make it backwards compatible USB_SERIAL_CDC should only be defined in my_machine.h if not defined on the command line? Or OVERRIDE_MY_MACHINE should be added to platformio.ini and all options selected there? I believe the latter option is the best, at least if a web app is made.

Obviously this is a kludge, but what would be the proper way of initializing output pins with some specific value in grblHAL? Can they be added to Src/driver.c somehow?

I see that you have added the code to the board specific startup code in the PR, this is the correct way to do it.

I might be able to take a stab at the same thing for the STM32F4xx repo once the Nucleo board I ordered shows up.

I see that you have already done so. The Nucleo boards are really easy to program as they show up as a drive, just drop the binary on that to get it done. BTW the F4xx driver has many build configurations to select from in Eclipse, e.g the latest version has two non-Nucleo F407 variants with different oscillator frequencies (8 and 25 MHz). I assume it will be possible to build with PlatformIO for such configurations as well...?

[MeKeCNC]

Did you enable the sd card option and compile it? it gives the following error

[terjeio]

@MeKeCNC Did you see this the platformio.ini?

# To enable support for SD card, you must grab a copy FatFS:
#   curl -O http://elm-chan.org/fsw/ff/arc/ff14b.zip
#   unzip ff14b.zip 'source/*'
#   mv source FatFS
# ..before uncommenting the below option

There is also a related readme in the FatFs folder.

[noahwilliamsson]

@MeKeCNC good catch, I forgot about SDCARD_ENABLE (and a KEYPAD_ENABLE as well as ODOMETER_ENABLE..). Thanks!

I've updated PR #6 with new instructions in platformio.ini:

[common]
build_flags =
...
  # 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
  # Uncomment to enable support for keypad
  #-D KEYPAD_ENABLE=1
  # Uncomment to enable support for odometer
  #-D ODOMETER_ENABLE=1
...
lib_deps =
# To enable support for SD card, you must grab a copy FatFS:
#   curl -O http://elm-chan.org/fsw/ff/arc/ff14b.zip
#   unzip ff14b.zip 'source/*'
#   mv source/* FatFS
#   rm -fr ff14b.zip source FatFS/diskio.c
# Next, apply the changes outlined in FatFS/README.md and then
# uncomment `FatFS` and `sdcard` below.
  #FatFS
  #sdcard

I also discovered that the declarations in Src/diskio.c didn't match what was in FatFS/diskio.h so I changed the last arg from BYTE to UINT to match the upstream code. I also fixed a typo in FatFS/README.md (discio.c -> diskio.c).

[noahwilliamsson]

In Eclipse it is easy add build configurations that has different symbols etc. The LPC176x driver has one for building a bootloader-friendly version.

Which option is that exactly, @terjeio? Do you see it somewhere in https://github.com/grblHAL/LPC176x/blob/master/.cproject? Or maybe in one of the .launch files?

FYI if the symbol OVERRIDE_MY_MACHINE is defined all options in my_machine.h can be moved to platformio.ini.

I didn't know about OVERRIDE_MY_MACHINE. I'll look into that, thanks!

What has been discussed before was to add a web-based build system where the user selected a processor or board to build for and then options for that.

I agree that would be really nice. Sites that allow this -- such as https://www.sdsetup.com/console?switch -- are very user-friendly. I'm however not likely to contribute something like this myself.

I believe USB serial should be enabled by default as is now, to make it backwards compatible

Agreed, let me see what I can do now that I know about OVERRIDE_MY_MACHINE.

BTW the F4xx driver has many build configurations to select from in Eclipse, e.g the latest version has two non-Nucleo F407 variants with different oscillator frequencies (8 and 25 MHz). I assume it will be possible to build with PlatformIO for such configurations as well...?

Yes, that should be possible. Feel free to comment on that PR and add the required board/shield/oscillator combinations and I'll see what I can do.

[MeKeCNC]

@terjeio Did you see this the platformio.ini?

Yes, I already have these settings,

@noahwilliamsson I've updated PR #6 with new instructions in platformio.ini:

good job it worked

[terjeio]

Which option is that exactly, @terjeio?

Search for BL_0x4000 in the .cproject file. There are some related files in the linkscripts folder.

I agree that would be really nice. Sites that allow this -- such as https://www.sdsetup.com/console?switch -- are very user-friendly.

Thanks for that link. Interesting.

[StefanBruens]

Next, I couldn't get -D USB_SERIAL_CDC=1 to work. It seems there's a MOSFET transistor between SWCLK (PA14) and USB D+ (PA12) whose purpose or function I don't understand (except that it breaks SWD if you're powering the board via USB instead of 12/24V DCIN..).

This is required to signal a disconnect to the host. 1k5 pullup from D+ to 3V3 means "connected", no pullup (switched off MOSFET) means "disconnected".

[noahwilliamsson]

Thanks for the explanation, @StefanBruens! Much appreciated.

[dlarue]

I have a blue pill( stm32f103ct6 ) and running PlatformIO the project builds fine but I get no USB device upon powerup over USB cable. I use bluepill_f103c8_128k_USB.bin uploaded with openocd which was tested to work with a p13/LED blink program and I've used this to upload a bootloader to an stm32f103 board on Ortur laser engravers.

There's something going on over USB but there ends up being "Unable to enumerate USB device". arm gcc v7.2.1 and will try removing "-O s" compile optimization to see if that effects this. It was a problem with gcc 4.x but throwing darts at this point.

I checked that OVERRIDE_MY_MACHINE was set(platformio.ini) and looked down at the env for bluepill_f103c8_128k_USB was set for the CNC3040 and USB_SERIAL_CDC=1 was set.

I've seen people say that the stm32f103ct6 will run grblHAL but they all use other dev build envs. What am I missing?

openocd -d0 -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/share/openocd/scripts/target/stm32f1x.cfg init reset program ./bluepill_f103c8_128k_USB/firmware.bin 0x08000000 reset exit

outfile_platformio.txt

[dlarue]

It's building to 127K so no way this'll fit in 64K of the stm32f103c8... I could not get it to work and ended up getting CubeIDE and followed the online instructions. It too was too large for the 103c8 but after setting the code generator to Release and USB_ENABLE=0 it fit! This might work on platformIO. But since the devs recommend CubeIDE I will stick with it.