STM32H747 and stldr for external NAND Flash. Why is the size not correct?

[RMich.2]

Hi,

I have written a STM32H747 external loader for a NAND Flash on the FMC bus of the CM7. The test software of the loader functions (Init, MassErase, SectorErase, ...) works perfectly. The functions are called correctly by the STM32CubeProgrammer. As a test of the functions, I forward the parameters of the function calls and the results to a UART and can thus debug the "internal" processes. The initialization and erase works perfectly. When programming a page there is now an unsolvable problem. The function

int Write( uint32_t Address, uint32_t Size, uint8_t *buffer )

gets values for Size that are much too large. The hex file to be programmed is about 303kB. The 303kB are divided into only two programming cycles:

1. Page programming address: 0x80000800 size: 0x0002502C

2. Page Programming Address: 0x8002582C Size: 0x00025000

Why is the size 0x0002502C or 0x00025000 and not 0x800 as defined?

The ext. NAND Flash starts at 0x8000'0000, the actual start is at 0x8000'0800.

Here the StorageInfo:

struct StorageInfo const StorageInfo = {

"MT29F1G08_HMI-MODEL-4",

NAND_FLASH,

0x80000000,

0x8000000,

0x800,

0xFF,

{ 0x00000400UL, 0x00020000UL,

0x000000UL, 0x000000UL }

};

Additional information about the environment:

• Keil IDE and Compiler V5 (Necessary, because V6 can't handle Scatter File Alignment 0x20000004, Alignment / 4 is not allowed).
• The loader is about 40kB in size, it has some software in it for bad block management of a NAND Flash.
• The similar loader (same backend) works perfectly with the Keil loader.
• I have tried ST-Link V2 and V3, it is the same behavior.

Why is the size not correct for page write access?

Thank you for your help.

[Tesla DeLorean]

>>Why is the size not correct for page write access?

You are expected to de-block the write to manage the underlying requirements of the device.

The loader/app is moving a memory buffer to RAM, this is done using the largest available RAM, for efficiency. You get to manage any alignment, block and size issues.

[RMich.2]

Hi Tesla,

yes that is logical and for the performance this is a big advantage. I was here clearly fixed on Keil... 

But there comes a big "but":

The first block is not a multiple of the Flash page size 0x800. How should the the loader firmware manage this? I have a flash block size of 0x800, I expect from the CubeProgrammer a multiple of this block size. The loader does not know if more data follows or not.

Is there a workaround for this?

[Tesla DeLorean]

Let's say I've not been terribly successful at communicating with ST about how these things should work or be tested / validated.

Like I said, it gets to handled the de-blocking, in much the same way as a random-access file system would expect to write data, ie merge or splice new data in / over the old data.

I guess getting clean/easy data to manage would start by making sure the object file generated by the linker is cleanly aligned/blocked. So perhaps linker scripts, or scatter files.

[RMich.2]

I am not happy with your answer. I don't have a filesystem with random access, that would reduce the system performance too hard.

The data are BLOB's binary large objects, it is difficult to script or scatter them. The loading software of ST is not one of the nicest I have seen from ST so far. It has good approaches, but this thing with the un-alignment is bad. If there is a possibility to adjust this in a software of the loader, this would help me. 

Thank you for your quick reply and clarification. 

[RMich.2]

I still see one possibility.

Is it possible to define the maximum memory (RAM) available for the loader?

Then I could easily define the alignment.