casts some doubt on the prevalent opinion that the boot code is
controlled by separate hardware, making the units "unbrickable".
Since you are a retired engineer, like me, perhaps this quote from
introduction of the bootloader app note (AN2606) for the STM32 ARM
processors (which the nanoVNA is based on), will confirm for you the
assertion that you cannot overwrite the bootloader, and thus cannot brick
the nanoVNA with a firmware update:
"The bootloader is stored in the internal boot ROM (system memory) of STM32
devices, and is
programmed by ST during production. Its main task is to download the
application program to the
internal Flash memory through one of the available serial peripherals (such
as USART, CAN,
USB, I2C, SPI)."
Table 5 also clarifies that the System Memory block where the boot loader
is stored is ROM and supports only read operations, not write or erase.
The bootloader is in hardware ROM which cannot be altered by any software
method. This design is why such a program as DFuseDemo by the vendor can be
used to bootload any of their microcrontroller devices - it is independent
of user programming.
Stan
On Mon, Jan 23, 2023 at 9:29 PM Al Waschka <awaschka@...> wrote:
QUOTE
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Tim
Dawson
Sent: Tuesday, January 24, 2023 12:03 AM
To: [email protected]
Subject: Re: [nanovna-users] New Problem (Bricked?) Re: Trouble Setting Up
DFuSE Driver
The firmware does *NOT* contain the bootloader, so the ability to det to
dfu mode should not be altered or impeded by what you flashed . . .
UNQUOTE
Thanks Tim, but the scenario I was proposing was not that the firmware
contained the bootloader, but that the nboot1 bit controls where in memory
the processor goes to find boot code or an address to boot from, depending
on what is stored in the location and how the fw responds to the data. As
I read it if a fw load has a different value for nboot1 than the original
code, the machine will not boot as intended.
Whether this is my problem or not is unknown, but it seems that the value
that a fw load sets the nboot1 bit at could change boot operations.
