The pagesize should be the same as the erase block size.. 4k.

You will probably want 512b sectors (pages, or whatever we call them now) at the file system interface. You can also read-modify-write operations to "simulate" smaller erase blocks.  Most MTD drivers do that.  In that case they report the simulated erase block size.  The overhead is an internal, large 4Kb buffer.

You can also use drivers/mtd/sector512.c to get a "generic" read-modify-write implementation and 512 b "simulated" erase blocks like:

   FAR struct mtd_dev_s *raw_mtd = progmem_initialize();
   FAR struct mtd_dev_s *s512_mtd = s512_initialize(raw_mtd);


On 7/8/2021 7:30 AM, Fotis Panagiotopoulos wrote:
Still looking at this driver, and how to improve it.

The LPC1769 needs data to be written in 256 bytes chunks, but Flash sectors
are erased in 4k or 32k sizes.

So, a couple of questions:

1. What should up_progmem_pagesize return , 256 or 4k/32k?
By the description I suppose it should be 256.
This is not true however for the STM32 arch.

2. What should up_progmem_getpage return?
I guess 256 again...?

But how up_progmem_eraseblock is expected to work?
There is no up_progmem_getblock, so there is no way that the application
knows which block to pass.
In STM32 I used up_progmem_getpage, but by checking the functions
descriptions now, I guess this shouldn't be correct?

Or should "page" here refer to the 4k/32k sectors?



Στις Παρ, 2 Ιουλ 2021 στις 2:08 μ.μ., ο/η Fotis Panagiotopoulos <
f.j.pa...@gmail.com> έγραψε:

Oh, that's great. That should definitely make the interface better.

But nevertheless, I tried to "ignore" the terms, and still I can't make
any sense of it.

This is what I try to do (which works fine on an STM32F4):

int write_data(intptr_t addr, BootData_t * data){
        if (memcmp((BootData_t*)addr, data, sizeof(BootData_t)) == 0)
                return 0;

        if (up_progmem_eraseblock(up_progmem_getpage(addr)) < 0)
                return -EIO;

        return up_progmem_write(addr, data, sizeof(BootData_t));}


I see that up_progmem_getpage() makes an unreasonable calculation.
It calculates the "page" as if it is 256 bytes, while in fact LPC1769 has
4k and 32k sectors...



Στις Παρ, 2 Ιουλ 2021 στις 1:39 μ.μ., ο/η Xiang Xiao <
xiaoxiang781...@gmail.com> έγραψε:

Here has some discussion about the naming:
https://github.com/apache/incubator-nuttx/pull/3834

On Fri, Jul 2, 2021 at 6:28 PM Fotis Panagiotopoulos <f.j.pa...@gmail.com
wrote:

Hello,

I am porting an old application to NuttX.
This is running on a hardware board that uses the NXP LPC1769 MCU.
I am in need of the up_progmem interface.

Unfortunately, I see that this driver is broken. It is not working,
always
returning an error.
I checked its internals, but it is quite a mess. It makes wrong
calculations on the sector sizes, it confuses the terms "page" and
"sector"
etc.
I see that it makes some calculations on the addresses, that to my
knowledge do not reflect the hardware in any way.

Is it actually that broken, or am I using it so incorrectly?
Has anyone used it before successfully?

I would appreciate a MWE of this driver. Or someone to confirm that it
is
not working before I start to rewrite it.


Reply via email to