Building grblHAL with PlatformIO #4
Comments
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, |
|
Thanks! With an updated Example output: |
|
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: 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. |
|
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 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 FWIW, the 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 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
Also, it seems these ST-Link v2 clones doesn't come with an 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:
(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:
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
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. */
+#endifBy allowing both the compile time Another option would be to define a board specific 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.
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.
With these changes in place, you can: 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.elfI'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. |
No problem, it is great that you spent time on this.
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
I believe USB serial should be enabled by default as is now, to make it backwards compatible
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 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...? |
|
Did you enable the sd card option and compile it? it gives the following error
|
|
@MeKeCNC good catch, I forgot about I've updated PR #6 with new instructions in I also discovered that the declarations in |
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
I didn't know about
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.
Agreed, let me see what I can do now that I know about
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. |
Yes, I already have these settings,
good job it worked
|
Search for
Thanks for that link. Interesting. |
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". |
|
Thanks for the explanation, @StefanBruens! Much appreciated. |
|
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 |
|
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. |
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(PlatformIO expects source code in the
src/directory and libraries, such asgrblormotors, in their own directories belowlib/, but it's possible to workaround this withinclude_dir,src_dir,build_flagsandlib_extra_dirs.)So far I've come up with the following
platformio.inifile:With this file in the root of the project dir, PlatformIO core (CLI) installed, you can start building the project with:
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.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 (assumingv1.7.0based onGRBL 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
.mxprojectappears to list some (or maybe all?) of these files that appears to be missing:(I suspect that
usb_device.cis missing too, I just didn't come that far with the compilation)Any chance that you can help locate these files?
Thanks!
The text was updated successfully, but these errors were encountered: