Dfu-util - page not writeable

Software Development
1

Hello,
I’ve recently moved my dev machine from Manjaro to Fedora but now I’m having trouble using the bootloader, namely uploading the binary through dfu-util.
I’m getting: “Last page at 0x0802120f is not writeable”

full output from make program-dfu:

dfu-util -a 0 -s 0x08000000:leave -D build/app.bin -d ,0483:df11
dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util / Tickets

dfu-util: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device…
Device ID 0483:df11
Device DFU version 011a
Claiming USB DFU Interface…
Setting Alternate Interface #0 …
Determining device status…
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Flash "
Downloading element to address = 0x08000000, size = 135696
dfu-util: Last page at 0x0802120f is not writeable
make: *** […/libDaisy/core/Makefile:330: program-dfu] Error 64

Any help would be greatly appreciated.
Cheers!

2

Blockquote
Downloading element to address = 0x08000000, size = 135696

Isn’t this too big? The STM32H750 has 128Kb of flash, from 0x08000000 to 0x8020000.
Max size in decimal is 131072, so your binary is about 4k too big to fit…

Cheers

3

Thanks for your reply but maybe you didn’t understand that I’m using the bootloader. This same program used to upload fine. In any case the same happens with a stripped down program, in this case a DAC test:

#include “daisy_seed.h”

using namespace daisy;

using InBuf = daisy::AudioHandle::InputBuffer;
using OutBuf = daisy::AudioHandle::OutputBuffer;

DaisySeed hw;

static void AudioCallback(InBuf in, OutBuf out, size_t size)
{

for(size_t i = 0; i < size; ++i) {
float sig = 0.0f;
out[0][i] = out[1][i] = sig * 0.5f;
}
}

int main(void)
{
hw.Configure();
hw.Init();

hw.adc.Start();
hw.StartAudio(AudioCallback);

uint32_t now = System::GetNow();
uint32_t last_update = System::GetNow();

float dac1_value = 0.0f;
float dac2_value = 0.0f;

for(;:wink:
{
now = System::GetNow();

if (now - last_update > 1000)
{
  dac1_value += 0.01;
  dac2_value += 0.01;

  if (dac1_value > 1.0f) {dac1_value = 0;};
  if (dac2_value > 1.0f) {dac2_value = 0;};
  last_update = now;
}

hw.dac.WriteValue(DacHandle::Channel::ONE , (uint16_t)(dac1_value * 4095.f));
hw.dac.WriteValue(DacHandle::Channel::TWO , (uint16_t)(dac2_value * 4095.f));

}
}

output from make:
Memory region Used Size Region Size %age Used
FLASH: 0 GB 128 KB 0.00%
DTCMRAM: 15160 B 128 KB 11.57%
SRAM: 64932 B 480 KB 13.21%
RAM_D2_DMA: 16 KB 32 KB 50.00%
RAM_D2: 0 GB 256 KB 0.00%
RAM_D3: 0 GB 64 KB 0.00%
ITCMRAM: 0 GB 64 KB 0.00%
SDRAM: 0 GB 64 MB 0.00%
QSPIFLASH: 0 GB 7936 KB 0.00%

Thanks!
(sorry for the funky formatting)

4

Ok, I don’t have any experience with using the bootloader. The log output from dfu-util would seem to indicate that it was trying to write to flash where the bootloader was kept, so I’d start by looking into that. You may need to reflash the bootloader itself if you’ve inadvertently stomped on it.

Cheers

5

OK, I just realized what was happening. Apparently the addresses are now being set on the core Makefile using the APP_TYPE variable. This wasn’t the case the last time I updated libDaisy. Setting APP_TYPE to BOOT_SRAM on my Makefile fixed the problem.

Thanks to your comment, I spotted the problem from the memory region it was trying to use. So, cheers for that!

1 Like