Using GnuK with DFU bootloader
gniibe at fsij.org
Thu Dec 13 01:00:54 CET 2018
Peter Lebbing <peter at digitalbrains.com> wrote:
> It appears the DFU-code in GnuK is faulty?
The code of DFU support in Gnuk was written in very early stage of Gnuk
development, for people with STBee and STBee mini. No surprises if not
> I tried to fix these things in commit 2e2d68d, which you can find at my
> GitLab: .
I will have a look at this.
> Instead, have a custom reGNUal erase the whole flash including the
> first 4KiB, and then have it program the whole flash including the
> first 4 KiB, with a bog-standard GnuK without DFU support.
I think that if you want to do that, in the first stage, flash ROM
should not be protected.
The first 4KiB cannot be written by running program (when protected).
Since I interpreted so, I keep my practice of filling the first pages of
4KiB for SYS routines (and a part of table for AES).
In the PM0075 Programming manual of STM32F10xxx Flash memory
microcontrollers, it says (section 2.4.1 in page 17):
Once the protection byte has been programmed:
* Main Flash memory read access is not allowed except for the user
code (when booting from main Flash memory itself with the debug
mode not active).
* Pages 0-3 (for low- and medium-density devices), or pages 0-1 (for
high-density and connectivity line devices) are automatically
write-protected. The rest of the memory can be programmed by the
code executed from the main Flash memory (for IAP, constant
storage, etc.), but it is protected against write/erase (but not
against mass erase) in debug mode or when booting from the
Well, it doesn't describe the specific case of IAP (in-application
programming) booting from flash ROM and running code in SRAM, but
it is likely the pages 0-3 are write-protected.
More information about the Gnuk-users