Missing USB when grblHAL is started by native BTT SKR3 bootloader

[bjerrep]

I think it would be super nice to have the option to always be able to update grblHAL with a SD card, bootloader style.

I relocated STM32H7xx grblHAL to start in second flash sector and I can start it directly in cubeide and it works nicely, and so does the USB. If I then reset the board and let the bootloader launch grblHAL then the USB is missing. I have no experience with USB, but based on some naive debugging it seems that there is a TxState that is now set and never cleared, giving a forever hanging USB transmission.

I have no idea if the blame is on the bootloader that might make a messy handover, or if it is the STM32H port that could just make a itsy bitsy extra init or something that would allow the USB to get going.

If I could build and debug a SKR3/H743 bootloader then that would in itself be super cool, would anyone know if that is an option ? I asked BTT the same and they sent me a binary copy of the bootloader :-)

[dresco]

Hi, I agree! Would be nice to have the option for a binary that works with the bootloader (I think some of the F4 targets have with/without bootloader build options).

Are you able to share your changes? Will have a go & see whether I can spot anything....

Thanks!

[bjerrep]

That would be very cool. Please have a look at https://github.com/bjerrep/STM32H7xx.

There are some new SKR3 launch scripts and a new linker script ending in _LD. Once that is used there should be a firmware.bin ready for the SD card in the build dirs. Best of luck trying to figure out how to make the USB happy.

[dresco]

Hi, sorry has taken me a while to get around to this!

In my testing, debug builds were working fine from the bootloader, but release builds were not. Attaching a debugger showed they were hanging in the first HAL_Delay() call. After a bit of digging, I found that SCB->VTOR wasn't being changed as expected in a release build.

Commenting out the _Automatic_Relocate_Vector_Table check, so that g_pfnVectors is always used, fixes the issue for me. I can't really see a downside to always using this?

Would be cool if you are able to verify this behaviour at your side?

Cheers, Jon.

[bjerrep]

I guess I tried to make the change pretty (whatever that means) but I really would have liked to nuke some of all the ifdefs and simply just set VTOR from g_pfnVectors unconditionally and getting rid of the _Automatic_Relocate_Vector_Table as you suggest. So your suggestion sounds very fine with me, this should work regardless of the actual flash start sector.

It is not clear to me if you got a working USB or just got to the point of having a booting grblhal from the bootloader ? (you are using the original BTT bootloader ?)

I must admit I now have the card working very nicely in my homemade CNC and since I am a complete CNC noob then right now my focus is to figure out all the other stuff there is to figure out. There will probably come a day where I want to tinker with grblhal again but it wont be right now I am afraid. Perhaps sooner if the bootloader/USB is working :-)

Cheers ~Claus

[dresco]

It is not clear to me if you got a working USB or just got to the point of having a booting grblhal from the bootloader ? (you are using the original BTT bootloader ?)

Yep, using the original BTT bootloader.

My local dev branch now appears to be fully functional when started from bootloader (as far as I've tested), with USB and SDCard working as expected. From my debugging, I think it was just hanging in the first HAL_Delay() call it came to - as was the first thing that relied on the incorrectly mapped interrupt vectors..

There will probably come a day where I want to tinker with grblhal again but it wont be right now I am afraid.

Understood, no worries :wink:

Cheers, Jon.

[joaobarros]

The latest build 20231005 does not start with the bootloader version. Flashing the "normal" version works fine.

[dresco]

The latest build 20231005 does not start with the bootloader version. Flashing the "normal" version works fine.

Hi, just looking for clarification (the latest H7 driver build is 230816)..

Is the issue that the 'normal' web builder firmware works when flashed using DFU (or SWD), but that the 'bootloader' web builder firmware doesn't work when flashed using the native BTT SDCard bootloader?

[Michaels5155]

Hi, I recently picked up several different boards to tinker with and test out. I am running into a similar problem with the USB on two of the boards. I am trying to install GRBLHAL, onto btt octopus max ez and btt octopus pro v1.0. I have tried flashing, both boards with bootloader and non-bootloader from the web builder. I am flashing the boards via SD card, because I don't know how to get them into DFU.I have tried different configurations. The non-bootloader configuration once the board finishes flashing I lose USB connection. The bootloader configuration on both boards the USB will drop out and then come back as a USB identifier error. I have tried to tinker around with stm32cubeide and platformI/O. However, I am apparently not smart enough to figure out how to solve the problem. I have tried to use your solution of committing out, automatic relocate vector table, and it did not work for me, more than likely I am Doing something wrong. Now for kicks and giggles, I flashed both boards with your btt SKR 3 bootloader from the web builder. Upon preliminary inspection both boards are working, now I haven't tested out all the pin configuration or the drivers. Whatever your fix was for btt SKR3. I am not able to replicate For the btt octopus boards.

[dresco]

Hi @Michaels5155,

Flashing via the SD Card will definitely need the bootloader versions of the firmware, else will just hardfault after restarting.

I'd be wary of trying to run a build for different hardware, as the pinout will likely be wrong, and there's always a risk of damaging some MCU outputs if they're not wired as expected.

That said, is interesting that the SKR3 build gets further for you, as there is not a lot of difference between the two in terms of startup (just configured with less flash & using eeprom for settings storage, is all the same clock setup and USB code).

If you want to try programming via DFU, you would hold the boot button down while pressing reset & it should restart into DFU mode. Note that if you program it this way, you will overwrite the bootloader, so you may want to back it up first.

The only BTT board I have is a H743 variant of the SKR3, but I've not been able to replicate the issue here.

[Michaels5155]

Thanks for the fast reply. Once you told me how to get the boards into DFU mode everything clicked. I got the DFU drivers and used platformio to flash the firmware and so far the btt octopus max ez is working well. I also used this method to flash the btt octopus pro. It also appears to be working however, as per your concern, I double checked the schematics and the pinout is completely different, so I will probably come back later and try to go through all the Io pens and try to reassign them, but for right now, there are several other boards I want to play with And test out. Thanks again.

[hambudi]

I am stuck with the same issue. I am unable to get any USB after flashing the firmware on my BTT SKR3 EZ board. This is the one with the h723 chip. I tried building with platformio and stm32cube.

Flashing with DFU fails with "Error during download get_status *** [upload] Error 74"

Flashing with USB causes the firmware.cur file to show up on the SD card but the board is unresponsive. If the board stays plugged into my computer it will give me an error after a minute. Device manager shows the following error.

"Windows has stopped this device because it has reported problems. (Code 43) A request for the USB device descriptor failed."

[dresco]

Unfortunately I'm unable to replicate this bootloader issue with my H743 SKR3 board.

If someone is able to dump their H723 bootloader out of flash for me, I'll see whether I can replicate & debug on another H723 board here...

[hambudi]

Im pretty sure I nuked my bootloader when doing the DFU install. After this I restored it using this https://www.dropbox.com/s/34be7gcoft3bwck/SKR3_Bootloader.bin?dl=0 Source: https://www.reddit.com/r/BIGTREETECH/comments/wpzh1a/skr_3_ez_bootloader_fw/

However I did manage to get serial on the device by installing the bugfix marlin branch. I dont think the issue is with the bootloader, i think it has to do with how serial is setup.

Note the pin definitions for serial that are required. https://www.reddit.com/r/BIGTREETECH/comments/13l9l23/skr_3_ez_not_showing_up_in_device_manager/

This is a full firmware dump of my board now showing COM port with marlin. If it helps. stm32cubedumpskr3h723v.zip

[hambudi]

I should also mention that ive only attempted to flash the bootloader version of grblhal. There are no PIO build scripts for non bootloader verison (not sure if that makes a diff).

Also the web builder is broken and gives the error, when attempting to build this.

"Command failed: pio run -etest -cjob.ini Error: Unknown board ID 'generic_stm32h743vi''

[dresco]

After this I restored it using this

Thanks, will try to test further this week..

[dresco]

@hambudi A few things to unpick here..

Starting with the most important, am hopeful I've found the underlying problem. There was an unrelated index underflow that caused a hard fault on any new board (without settings already saved to NVS). If you let me know your build configuration (number of axis, which TMC driver etc), I'll post a test binary here for you to try.

Interestingly, that bootloader link was for the original H743 board, but it does also seem to work fine on H723. I contacted BTT support for the H723 bootloader (which is a different binary), but it made no obvious difference.

You will need to use the correct bootloader vs non-bootloader firmware. I've included a PIO environment for the non-bootloader H723 variant with my latest changes, which should help as a starting point if configuring & building this way.

I also see the same Web Builder error, suspect it is missing some files from the latest update (I changed/simplified the custom board definitions). I'll let Terje know when I push these latest updates..

Cheers, Jon.

[hambudi]

Hey Jon,

Very sorry, but I returned the SKR 3 EZ board after tinkering with it for a little bit. I wanted to use this to setup my mini lathe for CNC, but I didnt think that I could connect an encoder to the board. I think ill try the flexihal board instead which has an encoder connection.

If it helps the community, I will ship you an SKR 3 EZ board from amazon for your testing, and you can ship it to me back when you are done.

[dresco]

Very sorry, but I returned the SKR 3 EZ board after tinkering with it for a little bit.

No worries!

If it helps the community, I will ship you an SKR 3 EZ board from amazon for your testing, and you can ship it to me back when you are done.

Thanks for the kind offer, but isn't necessary. I'm working on my own H723 based controller board, and have been able to install the BTT bootloader onto that for testing.