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.