No Com port after flashing FYSETC S6 V2


Gerry Byrne
 

Despite using  the thread "No COM port after flashing FYSETC S6 V2 board" which commenced on 7 May last, as a checklist, I too have been unable to achieve a com port after flashing.

Here's what I think I did right.
I changed the address from 0x8000000 to0x8010000 in the Cube Programmer bat file.
I used OnStep version 4.24.
After what, on the face of it, appeared to be successful flashing I cycled the power and moved the jumper from the Boot0 position to run.
I used version 1.9.0 of the STM32Duino board manager. In addition I repeated the flashing several times, to no avail.

However, I'm not sure whether or not I am using the STM 32 cube programmer correctly.
Must I be connected to the board via the cube programmer? Must STM32 Cube Programmer be running?
Should I change the address from 0x08000000 to 0x08010000 in the cube programmer Address window?
Should I be flashing while the programmer is connected to the board in USB1 mode (it is not displaying any indication of DFU)?

Yet the commentary of the compilation and uploading appears to indicate success. See the following copy of the installation log after the STM Cube Programmer is called up. The full log is appended as an attached text file.


      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.6.0                  
      -------------------------------------------------------------------

USB speed   : Full Speed (12MBit/s)
Manuf. ID   : STMicroelectronics
Product ID  : STM32  BOOTLOADER
SN          : STM32FxSTM32
FW version  : 0x011a
Device ID   : 0x0421
Device name : STM32F446xx
Flash size  : 512 KBytes (default)
Device type : MCU
Device CPU  : Cortex-M4



Memory Programming ...
Opening and parsing file: OnStep.ino.bin
  File          : OnStep.ino.bin
  Size          : 179788 Bytes
  Address       : 0x08010000


Erasing memory corresponding to segment 0:
Erasing internal memory sectors [4 5]
erasing sector 0004 @: 0x08010000 done
erasing sector 0005 @: 0x08020000 done
Download in Progress:


File download complete
Time elapsed during download operation: 00:00:06.409

RUNNING Program ...
  Address:      : 0x8000000
Start operation achieved successfully

Gerry Byrne


--
Copernicus


Dave Schwartz
 

The output of the build and upload process looks OK.

You do not actually use the STM32CubeProgrammer directly, you only need to install it from ST.COM so that the Arduino IDE can invoke the command line version using the batch file that is installed by the STM32 board manager. That is, do not have it running or connected - you never have to do that unless you have to reinstall an overwritten bootloader.

The only thing that concerns me is you say you 'cycled the power and moved the jumper from the Boot0 position to run'. If you did exactly that it would have booted in the DFU mode, not the mode that runs the user (OnStep) code (via a bootloader which should have remained untouched because of the changed address in the batch file). Also, are you sure you had the options correct for the USB support? Without them, the user code won't be able to use the USB port.

You should be able to use the device manager to determine what mode the USB is in... a COM port for normal OnStep mode or a USB serial device for DFU (upload mode).

On 2021-10-07 5:27 p.m., Gerry Byrne wrote:
Despite using  the thread "No COM port after flashing FYSETC S6 V2 board" which commenced on 7 May last, as a checklist, I too have been unable to achieve a com port after flashing.

Here's what I think I did right.
I changed the address from 0x8000000 to0x8010000 in the Cube Programmer bat file.
I used OnStep version 4.24.
After what, on the face of it, appeared to be successful flashing I cycled the power and moved the jumper from the Boot0 position to run.
I used version 1.9.0 of the STM32Duino board manager. In addition I repeated the flashing several times, to no avail.

However, I'm not sure whether or not I am using the STM 32 cube programmer correctly.
Must I be connected to the board via the cube programmer? Must STM32 Cube Programmer be running?
Should I change the address from 0x08000000 to 0x08010000 in the cube programmer Address window?
Should I be flashing while the programmer is connected to the board in USB1 mode (it is not displaying any indication of DFU)?

Yet the commentary of the compilation and uploading appears to indicate success. See the following copy of the installation log _after_ the STM Cube Programmer is called up. The full log is appended as an attached text file.


-------------------------------------------------------------------
                       STM32CubeProgrammer v2.6.0
-------------------------------------------------------------------

USB speed   : Full Speed (12MBit/s)
Manuf. ID   : STMicroelectronics
Product ID  : STM32  BOOTLOADER
SN          : STM32FxSTM32
FW version  : 0x011a
Device ID   : 0x0421
Device name : STM32F446xx
Flash size  : 512 KBytes (default)
Device type : MCU
Device CPU  : Cortex-M4



Memory Programming ...
Opening and parsing file: OnStep.ino.bin
  File          : OnStep.ino.bin
  Size          : 179788 Bytes
  Address       : 0x08010000


Erasing memory corresponding to segment 0:
Erasing internal memory sectors [4 5]
erasing sector 0004 @: 0x08010000 done
erasing sector 0005 @: 0x08020000 done
Download in Progress:


File download complete
Time elapsed during download operation: 00:00:06.409

RUNNING Program ...
  Address:      : 0x8000000
Start operation achieved successfully

Gerry Byrne


--
*Copernicus*
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


Gerry Byrne
 

Dave,
The problem continues. I flashed Onstep again without preloading STM32CubeProgrammer and it seems to have gone well. Before flashing, the board was showing up as a Bootloader in the Device Manager under System Bus Devices. After flashing I reset the jumper from Boot Zero to Run and repowered the board. The Bootloader entry disappeared from Device Manager but there was no corresponding new entry under Com Ports. When I attempted to open Serial Monitor to check on the installation it refused to open and the IDE responded with the message "Board at Com 7 is not available."

The flashing options used are exactly as they are in the wiki. When I asked Device Manager to show me the hidden devices, Com 7 showed as Arduino Uno but I think this reflects a historical connection: Com 3 indicates a CP2010x and it is almost a year since I used one.
Gerry

On 07/10/2021 22:49, Dave Schwartz wrote:
The output of the build and upload process looks OK.

You do not actually use the STM32CubeProgrammer directly, you only need to install it from ST.COM so that the Arduino IDE can invoke the command line version using the batch file that is installed by the STM32 board manager. That is, do not have it running or connected - you never have to do that unless you have to reinstall an overwritten bootloader.

The only thing that concerns me is you say you 'cycled the power and moved the jumper from the Boot0 position to run'. If you did exactly that it would have booted in the DFU mode, not the mode that runs the user (OnStep) code (via a bootloader which should have remained untouched because of the changed address in the batch file). Also, are you sure you had the options correct for the USB support? Without them, the user code won't be able to use the USB port.

You should be able to use the device manager to determine what mode the USB is in... a COM port for normal OnStep mode or a USB serial device for DFU (upload mode).

On 2021-10-07 5:27 p.m., Gerry Byrne wrote:
Despite using  the thread "No COM port after flashing FYSETC S6 V2 board" which commenced on 7 May last, as a checklist, I too have been unable to achieve a com port after flashing.

Here's what I think I did right.
I changed the address from 0x8000000 to0x8010000 in the Cube Programmer bat file.
I used OnStep version 4.24.
After what, on the face of it, appeared to be successful flashing I cycled the power and moved the jumper from the Boot0 position to run.
I used version 1.9.0 of the STM32Duino board manager. In addition I repeated the flashing several times, to no avail.

However, I'm not sure whether or not I am using the STM 32 cube programmer correctly.
Must I be connected to the board via the cube programmer? Must STM32 Cube Programmer be running?
Should I change the address from 0x08000000 to 0x08010000 in the cube programmer Address window?
Should I be flashing while the programmer is connected to the board in USB1 mode (it is not displaying any indication of DFU)?

Yet the commentary of the compilation and uploading appears to indicate success. See the following copy of the installation log _after_ the STM Cube Programmer is called up. The full log is appended as an attached text file.


-------------------------------------------------------------------
                       STM32CubeProgrammer v2.6.0
-------------------------------------------------------------------

USB speed   : Full Speed (12MBit/s)
Manuf. ID   : STMicroelectronics
Product ID  : STM32  BOOTLOADER
SN          : STM32FxSTM32
FW version  : 0x011a
Device ID   : 0x0421
Device name : STM32F446xx
Flash size  : 512 KBytes (default)
Device type : MCU
Device CPU  : Cortex-M4



Memory Programming ...
Opening and parsing file: OnStep.ino.bin
  File          : OnStep.ino.bin
  Size          : 179788 Bytes
  Address       : 0x08010000


Erasing memory corresponding to segment 0:
Erasing internal memory sectors [4 5]
erasing sector 0004 @: 0x08010000 done
erasing sector 0005 @: 0x08020000 done
Download in Progress:


File download complete
Time elapsed during download operation: 00:00:06.409

RUNNING Program ...
  Address:      : 0x8000000
Start operation achieved successfully

Gerry Byrne


--
*Copernicus*
--
*Copernicus*


Dave Schwartz
 

Must be some local problem then. I got a new laptop a few months ago and hadn't had it connected to this one yet but when I plugged it in, Windows 10 popped up a message saying it was setting it up (a message about setting up some device in some mode that I hadn't seen before) but it assigned it COM6 and DevMan says its using Microsoft drivers so no requirement to download something unique (like I had to do with a CH340 device). Connected using putty at 9600 baud and it responds 'On-Step' to ':GVP#:'

On 2021-10-08 10:29 a.m., Gerry Byrne wrote:
Dave,
The problem continues. I flashed Onstep again without preloading STM32CubeProgrammer and it seems to have gone well. Before flashing, the board was showing up as a Bootloader in the Device Manager under System Bus Devices. After flashing I reset the jumper from Boot Zero to Run and repowered the board. The Bootloader entry disappeared from Device Manager but there was no corresponding new entry under Com Ports. When I attempted to open Serial Monitor to check on the installation it refused to open and the IDE responded with the message "Board at Com 7 is not available."

The flashing options used are exactly as they are in the wiki. When I asked Device Manager to show me the hidden devices, Com 7 showed as Arduino Uno but I think this reflects a historical connection: Com 3 indicates a CP2010x and it is almost a year since I used one.
Gerry


On 07/10/2021 22:49, Dave Schwartz wrote:
The output of the build and upload process looks OK.

You do not actually use the STM32CubeProgrammer directly, you only need to install it from ST.COM so that the Arduino IDE can invoke the command line version using the batch file that is installed by the STM32 board manager. That is, do not have it running or connected - you never have to do that unless you have to reinstall an overwritten bootloader.

The only thing that concerns me is you say you 'cycled the power and moved the jumper from the Boot0 position to run'. If you did exactly that it would have booted in the DFU mode, not the mode that runs the user (OnStep) code (via a bootloader which should have remained untouched because of the changed address in the batch file). Also, are you sure you had the options correct for the USB support? Without them, the user code won't be able to use the USB port.

You should be able to use the device manager to determine what mode the USB is in... a COM port for normal OnStep mode or a USB serial device for DFU (upload mode).

On 2021-10-07 5:27 p.m., Gerry Byrne wrote:
Despite using  the thread "No COM port after flashing FYSETC S6 V2 board" which commenced on 7 May last, as a checklist, I too have been unable to achieve a com port after flashing.

Here's what I think I did right.
I changed the address from 0x8000000 to0x8010000 in the Cube Programmer bat file.
I used OnStep version 4.24.
After what, on the face of it, appeared to be successful flashing I cycled the power and moved the jumper from the Boot0 position to run.
I used version 1.9.0 of the STM32Duino board manager. In addition I repeated the flashing several times, to no avail.

However, I'm not sure whether or not I am using the STM 32 cube programmer correctly.
Must I be connected to the board via the cube programmer? Must STM32 Cube Programmer be running?
Should I change the address from 0x08000000 to 0x08010000 in the cube programmer Address window?
Should I be flashing while the programmer is connected to the board in USB1 mode (it is not displaying any indication of DFU)?

Yet the commentary of the compilation and uploading appears to indicate success. See the following copy of the installation log _after_ the STM Cube Programmer is called up. The full log is appended as an attached text file.


-------------------------------------------------------------------
                       STM32CubeProgrammer v2.6.0
-------------------------------------------------------------------

USB speed   : Full Speed (12MBit/s)
Manuf. ID   : STMicroelectronics
Product ID  : STM32  BOOTLOADER
SN          : STM32FxSTM32
FW version  : 0x011a
Device ID   : 0x0421
Device name : STM32F446xx
Flash size  : 512 KBytes (default)
Device type : MCU
Device CPU  : Cortex-M4



Memory Programming ...
Opening and parsing file: OnStep.ino.bin
  File          : OnStep.ino.bin
  Size          : 179788 Bytes
  Address       : 0x08010000


Erasing memory corresponding to segment 0:
Erasing internal memory sectors [4 5]
erasing sector 0004 @: 0x08010000 done
erasing sector 0005 @: 0x08020000 done
Download in Progress:


File download complete
Time elapsed during download operation: 00:00:06.409

RUNNING Program ...
  Address:      : 0x8000000
Start operation achieved successfully

Gerry Byrne


--
*Copernicus*

--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


Gerry Byrne
 

Trying to chase down possible causes of this issue I encountered two methods for setting Boot0 to achieve DFU. Which is correct?

The FYSETC WIKI (https://wiki.fysetc.com/FYSETC_S6/#s6-v20) for the S6 board states:

"First power off the board , then jumper the Boot0 to 3.3V ,  then connect the USB to the board and your computer , it will enter DFU mode."

There is a different method proposed in Github (https://github.com/FYSETC/FYSETC-S6/tree/main/bootloader):

"First power off the board , then jumper the Boot0 to GND , then connect the USB to the board and your computer , it will enter DFU mode . "

Also, I wonder if the software/address changes made by FYSETC in June have any impact when flashing Onstep. (See https://wiki.fysetc.com/FYSETC_S6/#s6-v20). My Board was ordered on July 5 and only arrived recently.

Note: The bootloader boot address have been change to 0x8000 since 2021/06/23, you can check bootloader details here (FYSETC-S6/bootloader at main · FYSETC/FYSETC-S6 · GitHub), and you can check the Marlin PR here (FYSETC S6 small bootloader target by GerogeFu · Pull Request #22207 · MarlinFirmware/Marlin · GitHub).

Gerry Byrne

On 08/10/2021 16:07, Dave Schwartz wrote:
Must be some local problem then. I got a new laptop a few months ago and hadn't had it connected to this one yet but when I plugged it in, Windows 10 popped up a message saying it was setting it up (a message about setting up some device in some mode that I hadn't seen before) but it assigned it COM6 and DevMan says its using Microsoft drivers so no requirement to download something unique (like I had to do with a CH340 device). Connected using putty at 9600 baud and it responds 'On-Step' to ':GVP#:'

On 2021-10-08 10:29 a.m., Gerry Byrne wrote:
Dave,
The problem continues. I flashed Onstep again without preloading STM32CubeProgrammer and it seems to have gone well. Before flashing, the board was showing up as a Bootloader in the Device Manager under System Bus Devices. After flashing I reset the jumper from Boot Zero to Run and repowered the board. The Bootloader entry disappeared from Device Manager but there was no corresponding new entry under Com Ports. When I attempted to open Serial Monitor to check on the installation it refused to open and the IDE responded with the message "Board at Com 7 is not available."

The flashing options used are exactly as they are in the wiki. When I asked Device Manager to show me the hidden devices, Com 7 showed as Arduino Uno but I think this reflects a historical connection: Com 3 indicates a CP2010x and it is almost a year since I used one.
Gerry


On 07/10/2021 22:49, Dave Schwartz wrote:
The output of the build and upload process looks OK.

You do not actually use the STM32CubeProgrammer directly, you only need to install it from ST.COM so that the Arduino IDE can invoke the command line version using the batch file that is installed by the STM32 board manager. That is, do not have it running or connected - you never have to do that unless you have to reinstall an overwritten bootloader.

The only thing that concerns me is you say you 'cycled the power and moved the jumper from the Boot0 position to run'. If you did exactly that it would have booted in the DFU mode, not the mode that runs the user (OnStep) code (via a bootloader which should have remained untouched because of the changed address in the batch file). Also, are you sure you had the options correct for the USB support? Without them, the user code won't be able to use the USB port.

You should be able to use the device manager to determine what mode the USB is in... a COM port for normal OnStep mode or a USB serial device for DFU (upload mode).

On 2021-10-07 5:27 p.m., Gerry Byrne wrote:
Despite using  the thread "No COM port after flashing FYSETC S6 V2 board" which commenced on 7 May last, as a checklist, I too have been unable to achieve a com port after flashing.

Here's what I think I did right.
I changed the address from 0x8000000 to0x8010000 in the Cube Programmer bat file.
I used OnStep version 4.24.
After what, on the face of it, appeared to be successful flashing I cycled the power and moved the jumper from the Boot0 position to run.
I used version 1.9.0 of the STM32Duino board manager. In addition I repeated the flashing several times, to no avail.

However, I'm not sure whether or not I am using the STM 32 cube programmer correctly.
Must I be connected to the board via the cube programmer? Must STM32 Cube Programmer be running?
Should I change the address from 0x08000000 to 0x08010000 in the cube programmer Address window?
Should I be flashing while the programmer is connected to the board in USB1 mode (it is not displaying any indication of DFU)?

Yet the commentary of the compilation and uploading appears to indicate success. See the following copy of the installation log _after_ the STM Cube Programmer is called up. The full log is appended as an attached text file.


-------------------------------------------------------------------
                       STM32CubeProgrammer v2.6.0
-------------------------------------------------------------------

USB speed   : Full Speed (12MBit/s)
Manuf. ID   : STMicroelectronics
Product ID  : STM32  BOOTLOADER
SN          : STM32FxSTM32
FW version  : 0x011a
Device ID   : 0x0421
Device name : STM32F446xx
Flash size  : 512 KBytes (default)
Device type : MCU
Device CPU  : Cortex-M4



Memory Programming ...
Opening and parsing file: OnStep.ino.bin
  File          : OnStep.ino.bin
  Size          : 179788 Bytes
  Address       : 0x08010000


Erasing memory corresponding to segment 0:
Erasing internal memory sectors [4 5]
erasing sector 0004 @: 0x08010000 done
erasing sector 0005 @: 0x08020000 done
Download in Progress:


File download complete
Time elapsed during download operation: 00:00:06.409

RUNNING Program ...
  Address:      : 0x8000000
Start operation achieved successfully

Gerry Byrne


-- 
*Copernicus*








--
Copernicus


Khalid Baheyeldin
 

You don't know which version of the bootloader was on your board.
So assume that it needs 0x801000, flash that bootloader, then flash OnStep.

The other important point is that if you don't get the USB device, you most
likely did not use the right flashing options that ensure the software defined
USB port works as it should. Refer to the Wiki page, and make sure the options
are the right ones.


Gerry Byrne
 

I believe I had the correct flashing options. However the No Com Port problem appears to have been present even before I attempted flashing the board. The attached snapshot of my flashing parameters shows the Com port is greyed out even before I start. and I cannot get board information.
Gerry

On 12/10/2021 00:19, Khalid Baheyeldin wrote:
You don't know which version of the bootloader was on your board.
So assume that it needs 0x801000, flash that bootloader, then flash OnStep.

The other important point is that if you don't get the USB device, you most
likely did not use the right flashing options that ensure the software defined
USB port works as it should. Refer to the Wiki page, and make sure the options
are the right ones.


--
Copernicus


Dave Schwartz
 

'Port' does not show up for the S6 when it is in DFU mode. It shows up as a Universal Serial Bus Device in the Device Manager and the STM32CubeProgrammer knows how to find it by name - there is no user selection required.

That still doesn't explain why the COM port does not show up when not in DFU mode. I still think its some local problem. As I said, I hadn't previously connected to this new laptop but when I did, Windows 10 PnP detected the new device and installed a proper driver for it from its own resources - nothing special with a third-party website was required.

On 2021-10-12 8:12 a.m., Gerry Byrne wrote:
I believe I had the correct flashing options. However the No Com Port problem appears to have been present even before I attempted flashing the board. The attached snapshot of my flashing parameters shows the Com port is greyed out even before I start. and I cannot get board information.
Gerry

On 12/10/2021 00:19, Khalid Baheyeldin wrote:
You don't know which version of the bootloader was on your board.
So assume that it needs 0x801000, flash that bootloader, then flash OnStep.

The other important point is that if you don't get the USB device, you most
likely did not use the right flashing options that ensure the software defined
USB port works as it should. Refer to the Wiki page, and make sure the options
are the right ones.

--
*Copernicus*
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


Ken Hunter
 

I'd tru shutting down OnStep, remove the USB connector.Power cycle the PC and start over. I see this at times when I am flashing multiple ESP32's.
Typical WINDOZE behaviour.


vedran.dobos@...
 

Hi Everybody,

I'm struggling with the same problem.
Think I got my settings correct. I patched the .bat file, as required. Re-flashed a new bootloader through STMProgramCube just in case. The programmer finishes successfully. I have 2x S6 boards (HX and MX, not that it matters) with the same result. Tried on 2 different Windows PCs. Might spin up a Linux VM if all else fails.


Any suggestions please?
Thanks in advance!




Dave Schwartz
 

I think the LTO option may be your problem. I recall someone using it unsuccessfully a few months ago. Use the -O3 option but not with LTO.

On 2021-11-05 9:22 a.m., vedran.dobos@gmail.com wrote:
Hi Everybody,

I'm struggling with the same problem.
Think I got my settings correct. I patched the .bat file, as required. Re-flashed a new bootloader through STMProgramCube just in case. The programmer finishes successfully. I have 2x S6 boards (HX and MX, not that it matters) with the same result. Tried on 2 different Windows PCs. Might spin up a Linux VM if all else fails.


Any suggestions please?
Thanks in advance!




vedran.dobos@...
 

Thanks, didn't help though :(

I tried randomly changing some of the options, to see what happens, the LTO was probably the latest try.
Too many combinations of options (1215) to try them all sequentially :)


drak
 

I had the same problem with my FYSETC S6 V2... It appears that the referenced bootloader in the documentation is out of date. As of June, the FYSETC S6 bootloader will now load from 0x8008000 instead of 0x8010000. Everything in the Wiki documentation is correct except now the old bootloader (the one that supports address 0x8010000) must be downloaded from here: https://github.com/FYSETC/FYSETC-S6/blob/main/bootloader/Bootloader-FYSETC_S6_10000.hex instead of the one referenced in the Wiki. The one referenced in the Wiki now points to the new bootloader which loads from 0x8008000. 

As soon as I wiped the S6, uploaded the old bootloader, compiled and updloaded OnStep again (to 0x8010000), everything started to work.

Hope this helps,
Jeremy


Dave Schwartz
 

I've updated the Wiki... they didn't have detailed information like that when the Wiki was written.

On 2021-11-06 5:30 p.m., drak wrote:
I had the same problem with my FYSETC S6 V2... It appears that the referenced bootloader in the documentation is out of date. As of June, the FYSETC S6 bootloader will now load from 0x8008000 instead of 0x8010000. Everything in the Wiki documentation is correct except now the old bootloader (the one that supports address 0x8010000) must be downloaded from here: https://github.com/FYSETC/FYSETC-S6/blob/main/bootloader/Bootloader-FYSETC_S6_10000.hex instead of the one referenced in the Wiki. The one referenced in the Wiki now points to the new bootloader which loads from 0x8008000.

As soon as I wiped the S6, uploaded the old bootloader, compiled and updloaded OnStep again (to 0x8010000), everything started to work.

Hope this helps,
Jeremy


vedran.dobos@...
 

Yes! This did it finally:
:GVP#
On-Step#


I was uploading the wrong bootloader indeed. :)
I saw all the details on the Fysetc page, but couldn't comprehend exactly what was expected of me to do. I thought newer=better :)

Can also confirm that loading the new bootloader, and setting the boot address to 0x08008000 instead of 0x08010000 for the sketch upload does _NOT_ work (no COM comes up port).
Old bootloader _MUST_ be used.

I also have the 2.1.0 version of the STM32 board library in the Arduino IDE, and so far it seems to work fine.
https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.json

Thanks Jeremy & Dave and everybody else.


Khalid Baheyeldin
 

On Sun, Nov 7, 2021 at 04:01 AM, <vedran.dobos@...> wrote:
Can also confirm that loading the new bootloader, and setting the boot address to 0x08008000 instead of 0x08010000 for the sketch upload does _NOT_ work (no COM comes up port).
Old bootloader _MUST_ be used.
I am bit confused by this new boot loader stuff.
Say I got a new FYSETC S6 V2 in November 2021. It has the new boot loader.
If I flash the old bootloader (which is known to work) on it at address 0x08000000.
Then flash OnStep to 0x8010000 to it, would it work?

Or do the new boards require the new boot loader and the different addresses?

Asking this because if we know the old boot loader works, we might as well document this,
and make it a step in the instructions.

I also have the 2.1.0 version of the STM32 board library in the Arduino IDE, and so far it seems to work fine.
https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.json
That is interesting. Version 2.0.0 had issues. I will try 2.1.0 some time.


vedran.dobos@...
 

On Sun, Nov 7, 2021 at 11:44 PM, Khalid Baheyeldin wrote:
I am bit confused by this new boot loader stuff.
Say I got a new FYSETC S6 V2 in November 2021. It has the new boot loader.
If I flash the old bootloader (which is known to work) on it at address 0x08000000.
Then flash OnStep to 0x8010000 to it, would it work?

Or do the new boards require the new boot loader and the different addresses?

Asking this because if we know the old boot loader works, we might as well document this,
and make it a step in the instructions.
Cannot really say, sorry. One of the boards was ordered on May 13 2021. and the other is newer, but could be old stock too.
I already messed with the bootloaders on both, so cannot check what was on them when shipped..?
Currently, both work with the bootloader for 0x08010000.

I got problems with the motors not turning now, but that is an issue for a different thread... :)


Guy Brandenburg
 

Is this problem what I’m seeing as well?

I think I have connected our larger stepper correctly, and powered on everything and chosen the correct parts of the software. However, when I try to open up the serial monitor, it complains there is no COM port. But the option to choose a COM port was never displayed and still remains grayed out. Puzzling.

Sent from my iPhone, which capitalizes Weirdly & misinterprets words just To keep you on your toes