Error: Last page at 0xac05fac3 is not writeable

Troubleshooting and Support
1

Hello,

I am currently trying to use the APP_TYPE = SRAM with a slightly modified _sram.lds file.

I am trying an experiment where I put my file system interface and the file access into flash memory.

Here is the code insdie my main file:

#define DSY_TEXT __attribute__((section(".flash_text")))
DSY_TEXT FIL            audio_desc_file; /**< Can't be made on the stack (DTCMRAM) */
DSY_TEXT FatFSInterface fsi;

I added this to the bottom of the _sram.lds file, directly above the DISCARD section:

    .flash_text :
        {
               _flash_text = 0x08000000;
               . = ALIGN(4);

               PROVIDE(__flash_text_start = _flash_text);
               build/AudioDesc.o (.flash_text)
               build/AudioDesc.o (.flash_text*)
/*           *(.flash_text)
               *(.flash_text*) */
               . = ALIGN(4);
               _eflash_text = .;

               PROVIDE(__flash_text_end = _eflash_text);
        } > FLASH

Looking at the memory regions:

Memory region         Used Size  Region Size  %age Used
           FLASH:        1700 B       128 KB      1.30%
         DTCMRAM:      112368 B       128 KB     85.73%
            SRAM:      129732 B       480 KB     26.39%
      RAM_D2_DMA:       18780 B        32 KB     57.31%

It does put the elements into Flash.

With the Daisy bootloader in DFU mode and trying to run “make program-dfu” I end up with this set of errors:

Device returned transfer size 4096
DfuSe interface name: "Flash "
Downloading element to address = 0x90040000, size = 469891780
Last page at 0xac05fac3 is not writeable

Any thoughts on how I can solve this?

Thanks,
Brett

2

Hi Brett!

That error at the end looks like the one you encountered and eventually resolved in this thread: (resolved) Error when using program-dfu with Diasy bootloader and the APP_TYPE = SRAM

So I recommend revisiting it and double check that you didn’t miss any steps. Let me know if there’s still an issue.

And I don’t know if this is related but it could be a workaround: dfu-util: Last page at 0xfc08ffff is not writeable - initialized arrays in QSPIFLASH · Issue #545 · electro-smith/libDaisy · GitHub

3

Hi @Takumi_Ogata ,

I thought I had it figured out in the my other thread, but it turns out I had only set some of the code up to run in a different part of the SDRAM section.

I will read through the other link you sent in more detail,. but at a glance they noted the issue may be in the Daisy Bootloader but that is not clear to me.

My goal is to be able to use the Daisy Bootloader when I get to my final product, but for now, it looks like I may have to forgo the Daisy Bootloader to be able to use the Flash memory in conjunction with the SRAM and QSPI without the use of the BootLoader and the _sram.lds script.

Right now it seems very unexpected to have the address of: “0x90040000.” given that is the start of the QSPI memory, so I’m not sure how adding in info to the Flash section would cause a QSPI memory write issue with the DFU loader when I am not putting anything in the QSPI memory location.

If you and/or others on the team have any more insights here, I would greatly appreciate it as the repro is pretty easy to recreate.

Please let me know if I can provide you and the team with any more information here.

Thank you for your time and help,
Brett

4

Is there any particular reason for wanting to put parts of your code in the internal flash? It certainly won’t work with the bootloader, since that’s where the bootloader itself is stored, but I’m curious what problem you’re looking to solve with this approach.

1 Like
5

Hi @Corvus_Prudens ,

Great question: Here are my main goals:

  1. Not be 100% dependent on having an SDCard in the device, although it should be there for the 99% use case.
  2. Split Read only and Execute only code to accomplish:
    a) putting fast and not as fast into appropriate flash locations
    b) splitting up the codes as I’m currently at 99.6% usage with the optimize flag on. thus, looking to expand the footprint as I extend the device to use more functionality.
    Example: external MIDI, something I removed as I was running out of flash space and would like to restore this work.
  3. Storing a base set of wave files in QSPI Flash for when the SDCard is not present.
  4. Using the Persistent Storage Class to save data on power loss and restart from power loss.
  5. Examples of larger static tables:
    a) wave file lookups
    b) LED color lookup tables, kind of large (I have an idea on how to reduce the size)
    c) MIDI commands look up tables (mappings from CC to actions)

Those are some of the goals, but maybe I can accomplish them in a different way and I’m OK with that as well.

In full transparency this is the first embedded project where I’m looking at splitting out code like this, so I am new to all of it and may be incorrect in how i’m thinking about what I am doing here.

Any help is greatly appreciated.

Most of all thank you for taking the time to help out through asking for more clarity.

Thanks,
Brett

6

@Corvus_Prudens ,

It is good to know the bootlaoder is in the Flash, but does it only take up some specific amount of the Flash? Example if it only takes up the few k of data, can I use data after that point in time?

Thanks,
Brett

7

Unfortunately, it currently takes up almost all of it. To be clear, this is specifically the STM32’s internal flash, not the QSPI chip’s flash. However, I don’t see why using the QSPI chip’s flash would be meaningfully different. There’s a lot of space in there, and you should be able to fit a fairly large program there just fine. Splitting up your program across different memory regions can be tricky to balance.

8

@Corvus_Prudens ,

Thank you.

One more thing then: Can I still store in the QSPI flash and use the Persistent Storage class? As I understand it, the persistent storage class uses the QSPI Flash.

Thanks,
Brett

9

Yes! You just have to make sure the parts of QSPI you’re using don’t overlap. You have 8MB in there, so there should be plenty of space. The persistent storage class initializer has an address offset you can provide.

1 Like
10

@Corvus_Prudens , Thanks!

I was just looking more closely at the persistent storage class and that all makes better sense to me now.

Thank you for the help.
Brett