search

grblHAL / STM32F4xx

grblHAL driver for ST STM32F4xx (Nucleo-64, Blackpill)
Other
93 stars 86 forks source link

Board not detected #45

Closed bthird closed 2 years ago

bthird commented 2 years ago

I am having an issue uploading the firmware via a sdcard to the BTT SKR2 board. When the firmware is inserted via an sd card the board is not detected. In case it was a faulty board i uploaded Marlin 2.0 and it works again.

The only changes I have made is:

inc/my_machine.h removed comment

define BOARD_BTT_SKR_20 // F407 based 3D Printer board

and

platfomio.ini added:

[env:btt_skr_2] board = genericSTM32F407VGT6 board_build.ldscript = STM32F407VGTX_BL32K_FLASH.ld build_flags = ${common.build_flags} -D BOARD_BTT_SKR_20= -D HSE_VALUE=8000000 -D USB_SERIAL_CDC=1 -D VECT_TAB_OFFSET=0x8000 lib_deps = ${common.lib_deps} eeprom lib_extra_dirs = ${common.lib_extra_dirs}

I also tried a different board build using board_build.ldscript = STM32F407VGTX_FLASH.ld instead

I have high hopes for grblhal and I really want this to work as GRBL was great on my machine.

Executing task: C:\Users\brian.platformio\penv\Scripts\platformio.exe run --environment btt_skr_2 <

Warning! Ignore unknown configuration option -d board_btt_skr_20 in section [env:btt_skr_2] Warning! Ignore unknown configuration option -d hse_value in section [env:btt_skr_2] Warning! Ignore unknown configuration option -d usb_serial_cdc in section [env:btt_skr_2] Warning! Ignore unknown configuration option -d vect_tab_offset in section [env:btt_skr_2] Processing btt_skr_2 (board: genericSTM32F407VGT6; platform: ststm32; framework: stm32cube) --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Verbose mode can be enabled via -v, --verbose option CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/genericSTM32F407VGT6.html PLATFORM: ST STM32 (15.0.0) > STM32F407VG (128k RAM. 1024k Flash) HARDWARE: STM32F407VGT6 168MHz, 128KB RAM, 1MB Flash DEBUG: Current (stlink) External (jlink, stlink) PACKAGES:

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

Can anyone shed any light on what i might be doing wrong?

boboxx commented 2 years ago

I haven't worked on mine yet but I'm pretty sure you need to upload the image with a STLink.

terjeio commented 2 years ago

@boboxx There is a build configuration for a bootloader version for the F407.

See issue #44 for a discussion related to this. I do not use platformio and I do not have a SKR2 to test with so not much else I can do other than upload a binary compiled with STM32CubeIDE, which I have done. You can find it here. If this works then the binary produced by platformio is not good?

This is the memory use reported by the build:

image

bthird commented 2 years ago

I have a ST-link and can try that.

I must admit I am a bit lost when it comes to bootloaders , do I need to upload a new bootloader to make this happen or is it part of the build process? This is all new to me as I used an Arduino based grbl controller before and building marlins was just following instructions with no issues.

I don't really care what IDE I use, if it helps I can change over to another IDE. If I get this working I can write up a detailed list of instructions to help others that are focused on getting it working. I can purchase a second controller and build a test environment for future releases as well.

terjeio commented 2 years ago

Here is how I understand the bootloader concept:

A bootloader is a piece of code residing more or less permanently in the controller (some has it in ROM). It reads a binary from somewhere such as a SD card and flashes it, then sets up the processor (relocates the vector table) and starts it.

Flashable bootloaders are typically(?) placed at the start of flash memory where the vector table is located. For those who flashes code residing on a SD card it sets up the MCU to read from that and checks if there is a binary present (firmware.bin) and if found flashes it above itself in memory (you see that above that the start address is for the binary I provided is 0x08008000, not 0x08000000 where the flash starts). If not found it checks for valid code(?) and enters the code already flashed.

IIRC for ARM processors it is important that the linker generates code that matches the address where it is to run or it will crash.

Note that if the bootloader placed in flash it is possible to overwrite it when flashing with a debug probe, if that happens it has to be reflashed.

Did you try to run the binary I made? Note that it has to be renamed to firmware.bin on the SD card or the bootloader will not flash it.

bthird commented 2 years ago

Thanks for the breakdown on bootloaders, this is helpful.

I tried the precompiled binary , placed it on an sd card (renamed to firmware.bin) and rebooted the board. Unfortunately the same issue arises where the board is not detected by windows.

terjeio commented 2 years ago

The USB peripheral is very sensitive to incorrect clock setup. Somehow we should get any problem with that ruled out? Is it possible to check the voltage on some of the input pins, it should be 3.3V - if not pulled up externally this would indicate the code has been started. Or is there a LED that could be blinked? If you have a UART <> USB breakout and there is an UART port on the board that could also be used to check if the code is running.

bthird commented 2 years ago

My STLINK V2 has arrived, I managed to flash the controller with marlin bootloader (after wiping it out...oops) and marlin firmware, all via the stlink. I am still not getting windows to detect board after flashing grblhal, it may be due to my build. all voltages appear to be fine, it must be the bootloader and firmware in device memory. I must be doing something wrong.

Using stlink and associated software is there anything i can do to share the device info so that it can be diagnosed?

boboxx commented 2 years ago

Did you confirm that your SKR2 had a STM32F407VGT6 and not a STM32F429VGT6?

terjeio commented 2 years ago

I have just committed an update where I have cleaned up the debug configurations, hopefully this can help in getting this resolved. When programming with ST-Link first build the Debug F407 8MHz version and then debug that. Select the correct debug configuration from the debug dropdown menu if .the tooltip shown when hovering over the debug tool does not match.

When pausing the program it should the stop at random places in the code, not in a fault handler. Verify that. If this is ok stop debugging and unplug/reinsert the USB cable, if the board does not show up then there is likely a USB clock issue we have to solve. If it shows up there is something wrong with the bootloader version.

Note that this overwrites the bootloader and that has to be reflashed before trying the bootloader version.

bthird commented 2 years ago

I can confirm the chip is the F407 and not the STM32F429VGT6

I am just learning how to use the STM32CUBE IDE so it might take a day or so before I reply,

I might get some development boards to practice with. I am more familiar with the 8bit world and this is my first real experience with 32bit (tools have come on a long way)

bthird commented 2 years ago

I think I have made some good progress.

Before taking all the steps below I deleted the eclipse workspace that existed

step 1 - Install STM32CUBEIDE step 2 - install STM32CUBEProgrammer Step 3 - Follow instructions to download via git git clone --recurse-submodules https://github.com/grblHAL/STM32F4xx Step 4 - Add folder to STM32CUBEIDE Step 5 - Alter My_machine.h and select board by uncommenting #define BOARD_BTT_SKR_20 // F407 based 3D Printer board Step 6 - load firmware using STM32CUBEProgrammer Step 7 - confirmed GRBL was installed by checking comm port and sending $$ command in UGS Step 8 - opened beer and celebrated

I am very new to STM32CUBEIDE so I don't think I was debugging it correctly but it would be useful to publish a guide.

Even with all the issues I had, I am still keen to use this board. This does not have a bootloader but I don't care, as long as it works.

As commas to board is now working I can move onto building a working config which matches my home made cnc. oh and build a control board for manual control.

I have one question would getting a second board and testing new builds be helpful to this community? I will test new builds anyway as the cnc is in constant use and i don't want to test on a production system?

terjeio commented 2 years ago

@bthird Great, that means the clock setup is correct.

I assume you flashed the Debug F407 8MHz version? There must be something wrong with the bootloader build then.

I am very new to STM32CUBEIDE so I don't think I was debugging it correctly but it would be useful to publish a guide.

There are guides to be found on the net, do a search and you will find many.

I have one question would getting a second board and testing new builds be helpful to this community?

Yes, that could be helpful. I mainly test changes with the STM32F401, STM32F756 and the iMXRT1062 drivers before releases depending on what has been changed. However, I do not retest all the different configurations with the different board maps available. That would be a herculean task and also impossible as I do not have, and do not want, the boards needed. Automated tests could be set up but that would only trap compilation issues, not run time issues like this.

boboxx commented 2 years ago

How are you loading the firmware from STM32CUBEProgrammer? I'm able ro see my ST-Link but I cant get it to connect to the SKR board. I tried the reset button and different ST-Link config bit I can't seem to get it a connected state to be ale to upload the firmware.

Edit: I managed to be able to upload the firmware using STM32 St-Link Utility!

bthird commented 2 years ago

@terjeio I believe the setup is correct. As for the bootloader that will be my next task (I will not use it for my production system). I am not saying the bootloader is broken, it might be my lack of knowledge that was causing an issue. I am ordering a second board and will complete a detailed help file with screenshots (not sure where to upload to as its not an issue). I think board specific help is needed as it can be a bit different process for getting it to work.

@boboxx First step should really be update the firmware of your ST link, I had stability issues but I am using a clone. Once the firmware is updated then you should be able to perform a "read" of the memory of the board, doesn't matter what's been uploaded as you are checking connectivity. If you have made up your on cable make sure it is wired and crimped correctly, test with a multimeter.

If you are able to upload firmware you can check if the uploaded file has been uploaded correctly by comparing two files.

bthird commented 2 years ago

@boboxx How did you fix the issue?

terjeio commented 2 years ago

I am ordering a second board and will complete a detailed help file with screenshots (not sure where to upload to as its not an issue).

I have made the Wiki for this repo open for everyone to edit so please add it to that.

The bootloader is ok, it is the binary that is not correct - maybe wrong start address? It might be possible to debug the binary but I am not sure how to do that. Perhaps the start address has to be changed in the debug configuration? Or that it is debuggable with the current settings? I have never tried to load and run a binary from an address different from the start of the flash so I simply do not know.

Below I have marked the settings that may need to be set:

image

IMO the binary itself is good since it runs when flashed at the start of the flash.

Edit: I managed to be able to upload the firmware using STM32 St-Link Utility!

Were you able to connect after that?

boboxx commented 2 years ago

I'm still unable to get this working with the latest pull. I tried it from the STM ide and Platform. I can upload the FW via the stlink but the board doesn't bootup.

[ env:btt_skr_2 ] board = genericSTM32F407VGT6 board_build.ldscript = STM32F407VGTX_BL32K_FLASH.ld build_flags = ${common.build_flags}

See Inc/my_machine.h for options

-D BOARD_BTT_SKR_20= -D HSE_VALUE=8000000 -D USB_SERIAL_CDC=1

Boot loader offset (32K)

-D HAS_BOOTLOADER lib_deps = ${common.lib_deps} eeprom lib_extra_dirs = ${common.lib_extra_dirs}

terjeio commented 2 years ago

@boboxx If you flash with ST-Link and a bootloader version you have to change the target adress or you will overwrite the bootloader and the MCU will crash. IMO it will be simpler for you to flash a "normal" build with ST-Link.

boboxx commented 2 years ago

How could I find out and what should be set for a normal flash? I have flashed this board a few times so it's likely lost it's original bootloader

terjeio commented 2 years ago

Try with changing the loader script to board_build.ldscript = STM32F407VGTX_FLASH.ld and removing this line -D HAS_BOOTLOADER

boboxx commented 2 years ago

perfect thank you that worked :)