Enabling Extended cache fails when a flash starting address of 0 is provided to LevelX

[simonebonetti987]

The issue has already been reported here:

#13

but no fix has been produced in years.

The issue is still present in version v6.5.0 and it's blocking the possibility to use the extended NOR cache to improve LevelX performances.

[miracoli]

I can confirm this.

[fdesbiens]

Hi @simonebonetti987. Thank you for raising the issue. I will do my best to look into it soon.

[miracoli]

As a possible workaround until this is fixed in LevelX itself: it is possible to avoid using 0 as lx_nor_flash_base_address and instead provide a self-defined, non-zero synthetic base address.

For example, in our NOR driver we use a constant base address only for LevelX address calculations:

static constexpr uintptr_t LEVELX_BASE_ADDRESS = 0x10000000UL;

static inline ULONG* offsetToFlashAddress(uint32_t offset) {
    return reinterpret_cast<ULONG*>(LEVELX_BASE_ADDRESS + offset);
}

static inline uint32_t flashAddressToOffset(ULONG* flash_address) {
    return static_cast<uint32_t>(
        reinterpret_cast<uintptr_t>(flash_address) - LEVELX_BASE_ADDRESS
    );
}

During LevelX initialization:

nor_flash->lx_nor_flash_base_address =
    reinterpret_cast<ULONG*>(LEVELX_BASE_ADDRESS);

Then, inside the driver callbacks, the passed flash_address is converted back to a physical flash offset before sending commands to the external NOR device:

UINT driver_read(ULONG* flash_address, ULONG* destination, ULONG words) {
    uint32_t offset = flashAddressToOffset(flash_address);
    // use offset for the actual SPI/QSPI NOR read
}

This avoids the extended-cache problem caused by a zero cache_entry_start, while still allowing the driver to address the external flash from offset 0.

Of course this is only a workaround, not a real fix. The chosen synthetic base address must not overflow when the flash size is added, and the application/driver must treat it only as a LevelX logical address, not as a directly dereferenceable memory-mapped address.

[fdesbiens]

I submitted PR #79 to address this issue. @simonebonetti987 and @miracoli: can you please have a look?

If my fix is good, I will merge to dev, and this would ship with our Q3 2026 release.