Using GnuK with DFU bootloader

[NIIBE Yutaka]

Peter Lebbing <peter at digitalbrains.com> wrote:
> It appears the DFU-code in GnuK is faulty?

Possibly.

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
working.

> I tried to fix these things in commit 2e2d68d, which you can find at my
> GitLab: [3].

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
      embedded SRAM.

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.
--