According to the GD32F303 reference manual, to boot into the Bootloader, Boot0 should be 1 and Boot1 should be 0.
The schematic shows Boot1 (PB2) as tied to Vdd.
This means that powering up with Boot0 high boots into SRAM mode.

If I power up with Boot0 high (White screen) none of the applications (DFUSE, NonaVNA-App) can find any DFU-mode devices.
However... if I set DFU mode via the Config Menu (DFU Mode message on screen), then my SAA-2N is recognised as being in DFU mode and I can reflash the firmware.

The other oddity is that on my -H and -H4 NanoVNAs, in Normal Mode they show up in Device Manager as a Serial Port under Com Ports, and when I change to DFU mode they show as STM Bootloader under USB Devices... BUT... the SAA-2N always shows as a Serial Port under Com Ports, whether it's in Normal Mode or DFU mode.

Is this normal, or is it a clue as to why I can't reflash the Bootloader?

I'd appreciate any explanation for what behaviour to expect from these things.

Many thanks,
Mike - M0MLM

Bootloader only can be updated with an st link... Stm discovery board..
Whatever

But not via usb...

Only fw update work via usb.. With button pressed and power on

Only where you need bl change is when upgrade to a plus version

Then 3 steps needed

Bl change (ST LINK!!)

Hw modding (SOLDER WORK!)

And fw change (LIKE NORMAL VIA USB)

Greetz sigi dg9bfc





Am 05.01.2021 21:25 schrieb Mike Millen <mike.millen.uk@gmail.com>:

> According to the GD32F303 reference manual, to boot into the Bootloader,
Boot0 should be 1 and Boot1 should be 0.
> The schematic shows Boot1 (PB2) as tied to Vdd.
> This means that powering up with Boot0 high boots into SRAM mode.
>
> If I power up with Boot0 high (White screen) none of the applications
(DFUSE, NonaVNA-App) can find any DFU-mode devices.
> However... if I set DFU mode via the Config Menu (DFU Mode message on
screen), then my SAA-2N is recognised as being in DFU mode and I can reflash
the firmware.
>
> The other oddity is that on my -H and -H4 NanoVNAs, in Normal Mode they show
up in Device Manager as a Serial Port under Com Ports, and when I change to
DFU mode they show as STM Bootloader under USB Devices... BUT... the SAA-2N
always shows as a Serial Port under Com Ports, whether it's in Normal Mode or
DFU mode.
>
> Is this normal, or is it a clue as to why I can't reflash the Bootloader?
>
> I'd appreciate any explanation for what behaviour to expect from these
things.
>
> Many thanks,
> Mike - M0MLM



_._,_._,_

* * *

Yes... I understand all of that.  :-)
I know that DFU mode is normal USB connection, but to reflash Bootloader
requires a SWD connection (ST-Link, for example)

But... my ST-Link cannot connect to the GD32F303, so I'm looking for
clues as to why.
I noticed that the SAA-2N USB interface behaved differently from the -H
and -H4 versions, and I wondered why.

I'm sure the problem is on my PC and not in the SAA-2N... I'm just
looking for moe clues.

Mike
M0MLM
------------------------------------------------------------------------
*From:* Siegfried Jackstien [mailto:siegfried.jackstien@freenet.de]
*Sent:* Tuesday, 5 January 2021, 9:06 pm
*Subject:* [nanovnav2] DFU mode on V2_2

> Bootloader only can be updated with an st link... Stm discovery
> board.. Whatever
> But not via usb...
> Only fw update work via usb.. With button pressed and power on
> Only where you need bl change is when upgrade to a plus version
> Then 3 steps needed
> Bl change (ST LINK!!)
> Hw modding (SOLDER WORK!)
> And fw change (LIKE NORMAL VIA USB)
> Greetz sigi dg9bfc
>
>
> Am 05.01.2021 21:25 schrieb Mike Millen <mike.millen.uk@gmail.com>:
>
> According to the GD32F303 reference manual, to boot into the
> Bootloader, Boot0 should be 1 and Boot1 should be 0.
> The schematic shows Boot1 (PB2) as tied to Vdd.
> This means that powering up with Boot0 high boots into SRAM mode.
>
> If I power up with Boot0 high (White screen) none of the
> applications (DFUSE, NonaVNA-App) can find any DFU-mode devices.
> However... if I set DFU mode via the Config Menu (DFU Mode message
> on screen), then my SAA-2N is recognised as being in DFU mode and
> I can reflash the firmware.
>
> The other oddity is that on my -H and -H4 NanoVNAs, in Normal Mode
> they show up in Device Manager as a Serial Port under Com Ports,
> and when I change to DFU mode they show as STM Bootloader under
> USB Devices... BUT... the SAA-2N always shows as a Serial Port
> under Com Ports, whether it's in Normal Mode or DFU mode.
>
> Is this normal, or is it a clue as to why I can't reflash the
> Bootloader?
>
> I'd appreciate any explanation for what behaviour to expect from
> these things.
>
> Many thanks,
> Mike - M0MLM
>
>
>

DFUSE and I think NanoVNA-App are not able to update SAA2. Ony the VNA-QT can update it. The SAA2 has a different processor to NanoVNA.

DFUSE and I think NanoVNA-App are not able to update SAA2. Only the VNA-QT can update the SAA2. The SAA2 has a total different processor to the NanoVNA.

Thanks, Klaus... I'd forgotten that.

That explains why it always shows as a Serial device in Device Manager.

BTW, NanoVNA-App *does* reflash the SAA-2 (my version v1.1.192)

Regards,
Mike

------------------------------------------------------------------------
*From:* Klaus Wörner [mailto:dl5kv@darc.de]
*Sent:* Wednesday, 6 January 2021, 6:39 am
*Subject:* [nanovnav2] DFU mode on V2_2

> DFUSE and I think NanoVNA-App are not able to update SAA2. Only the
> VNA-QT can update the SAA2. The SAA2 has a total different processor
> to the NanoVNA.

NanoVNA-App (v1.206) from OneOfEleven is able to update a V2_2, and even in a more reliable way compared to QT. I have tested it succesfully several times.

As a reminder : entering DFU mode with a V2_2 just requires to press and hold left push button, and turn on power switch. Full white screen depicts it is in DFU mode.

Regards,
Jean-Roger / F6EGK

Except that it's not "DFU" mode, because the GD processor doesn't have a
DFU mode... it's Bootloader mode.

The same idea, though.

Mike

------------------------------------------------------------------------
*From:* Jean-Roger Roy [mailto:F6EGK@hotmail.com]
*Sent:* Wednesday, 6 January 2021, 1:22 pm
*Subject:* [nanovnav2] DFU mode on V2_2

> NanoVNA-App (v1.206) from OneOfEleven is able to update a V2_2, and
> even in a more reliable way compared to QT. I have tested it
> succesfully several times.
>
> As a reminder : entering DFU mode with a V2_2 just requires to press
> and hold left push button, and turn on power switch. Full white screen
> depicts it is in DFU mode.
>
> Regards,
> Jean-Roger / F6EGK

Hi all,
Regarding connecting STLink to GD32F303, it's doable but it depends what STLink you have. If you have a genuine one that uses the voltage sense pin you have to yourself apply 3V to that. If you have a clone type STLink looking like a USB flash drive it works out of the box.

I learned this the hard way when upgrading my V2.2 to V2.2 Plus.
Br
Marcus

That's what I'm attempting to do. (Update to Plus)

I'm using a genuine ST-Link V3MINI.
I've connected nRST, the SWD pins, GND & Vcc.
Both ST-Link Utility and STM32Cube programmer show me the Vcc level but
say "No STM32 target found"

I'm waiting for delivery of a V2 ST-Link and also a "Blue Pill" board,
in the hope that one of them will allow me to re-flash the bootloader.

I'm also exploring OpenOCD, but the learning curve is very steep. :-)
OpenOCD can communicate OK via SWD to the NanoVNA, but I've yet to
figure out how to get it to re-flash it.

Mike


------------------------------------------------------------------------
*From:* Marcus Gustafsson [mailto:mankan@lysator.liu.se]
*Sent:* Friday, 8 January 2021, 10:36 am
*Subject:* [nanovnav2] DFU mode on V2_2

> Hi all,
> Regarding connecting STLink to GD32F303, it's doable but it depends
> what STLink you have. If you have a genuine one that uses the voltage
> sense pin you have to yourself apply 3V to that. If you have a clone
> type STLink looking like a USB flash drive it works out of the box.
> I learned this the hard way when upgrading my V2.2 to V2.2 Plus.
> Br
> Marcus
>

A quick follow up to this, so that others might avoid the same problem...

I'd been trying to rewrite the Bootloader using an ST-Link V3MINI
(genuine), but no matter what I tried, it refused to connect with the
NanoVNA V2_2
Today the ST-Link V2 (maybe genuine, maybe clone) I ordered arrived. It
connected immediately and let me load the Bootloader and then the new
Plus firmware.

The moral of the story... newest isn't always best!

Regards,
Mike


------------------------------------------------------------------------
*From:* Marcus Gustafsson [mailto:mankan@lysator.liu.se]
*Sent:* Friday, 8 January 2021, 10:36 am
*Subject:* [nanovnav2] DFU mode on V2_2

> Hi all,
> Regarding connecting STLink to GD32F303, it's doable but it depends
> what STLink you have. If you have a genuine one that uses the voltage
> sense pin you have to yourself apply 3V to that. If you have a clone
> type STLink looking like a USB flash drive it works out of the box.
> I learned this the hard way when upgrading my V2.2 to V2.2 Plus.
> Br
> Marcus
>

I cannot help you with your non-functional ST-Link connection, but I did successfully upload a new bootloader and firmware yesterday, using the ST-Link that is part of my STM32F3DISCOVERY board. I soldered header pins onto the DISCO board and removed the two jumpers to disconnect it from the onboard target. An adapter cable routed Ground, SWCLK, SWDIO and nRST (not Vcc!), and it just works. The NanoVNA must be powered on using its own battery. It's possible that the NanoVNAv2 cannot be powered from your adapter?

Don't use openocd. It is a vast rabbit warren of cruddy old TCL code that will give you nightmares for decades.

Use the STLink software tool. Get the latest and build it from source. The version currently available in OSX HomeBrew complains that it doesn't recognise the chip.

Load the bootloader first at address 0x8000000, then the firmware at address 0x8004000, and you should be good to go. Here are the command lines I used:
>
>
> st-flash --reset --area main write bootloader/binary.bin 0x8000000

>
> st-flash --reset --area main write firmware_version.bin 0x80004000