XFlash question: including data file with DFU upgrade

[Caleb]

Well I thought this was doing what I needed but there is still a problem. DFU will write appended data after the end of the XFLASH-generated upgraded file. But, if I generate a new upgrade #1, executing a DFU will only erease the previous bootable image for upgrade #1. It will not erase the appended data that was written the first time. I haven't found a solution to this with the operation options for XFLASH. I suppose it must be possible to modify the DFU endpoint code on the device to erase the necessary area of flash when flash_cmd_erase_all executes. It's sortof funny that this command does not erase all.

The DFU code in the XMOS device first deletes the upgrade image then calls StartImageAdd with an parameter MAX_IMAGE_SIZE (defined in the makefile)

An exception will be raised in the flash lib if you try and write beyond this size (so to protect other images that may be in the flash)

[genap]

I am trying to solve the same problem of adding data to the DFU file.
I've resolved the erasing of a data partition by adding a function fl_eraseDataSector() to the flash_command_erase_all() function in flash_interface.c

Code: Select all

int flash_cmd_erase_all(void) 
{
    if (upgrade_image_valid) 
    {
        if (fl_deleteImage(&upgrade_image) != 0)
            FLASH_ERROR();
        upgrade_image_valid = 0;
        //*!
        fl_eraseDataSector(1);
    }
    return 0;
}

It erases the first sector of a data partition.
Nevertheless the concatenated data part of the DFU file is not written to the data partition on upgrade.
I modified the FLASH_MAX_UPGRADE_SIZE in both makefile and flash_interface.c to 512*1024.

In the comment to the function fl_startImageAddAt() in libflash API I've found that

Attempting to write into the data partition or the space of another upgrade image is invalid.

Is there any way to upgrade both image and data partition at the same time ?

[Ross]

I assume the data partition is going to be after FLASH_MAX_UPGRADE_SIZE, so you are not writing to the area you erased?

[genap]

Not only access, but writing of the factory image with data is going to be a problem, since the data part will be in the second part of an upgrade image.

[genap]

I assume the data partition is going to be after FLASH_MAX_UPGRADE_SIZE, so you are not writing to the area you erased?

The FLASH_MAX_UPGRADE_SIZE is confusing to me in this case.
My boot partition size is 128K. So, to write an upgrade image together with data (>64K) I have to set the FLASH_MAX_UPGRADE_SIZE to at least 128K, otherwise the whole upgrade file is not going to be written.
But from you comment I conclude that FLASH_MAX_UPGRADE_SIZE needs to be 64K, since data partition (the erased sector) has to start right after the upgrade image.

But since writing to the data partition at DFU upgrade is not valid, it probably doesn't matter anyway :(

[Ross]

Not only access, but writing of the factory image with data is going to be a problem, since the data part will be in the second part of an upgrade image.

You mean the initial xflashing of the image, or writing to the factory image during a DFU?

When you catted the image and the data, did you add any padding at all? Padding would be required to get the data up to the data-partition area I assume. The amount based on the -boot-partition-size you specified when doing the xflash.

Ideally the DFU code would be modified to properly write to the data-partition - anything else is a bit of a hack really..

[Ross]

since data partition (the erased sector) has to start right after the upgrade image.

But since writing to the data partition at DFU upgrade is not valid, it probably doesn't matter anyway :(

My understanding is that the data-partition starts after the size specified by boot-partition-size when you xflash the factory image.

[Ross]

The FLASH_MAX_UPGRADE_SIZE is confusing to me in this case.
My boot partition size is 128K. So, to write an upgrade image together with data (>64K) I have to set the FLASH_MAX_UPGRADE_SIZE to at least 128K, otherwise the whole upgrade file is not going to be written.

Correct, else you would hit the limitAddress check in the flash code:

Code: Select all

int fl_writeImagePage(const unsigned char page[])
{
  unsigned pageSize = fl_getPageSize();
  if (fl_imageWriteState.currentAddress + pageSize >
      fl_imageWriteState.limitAddress) {
    return -1;
  }

Where limit address is generated from the maxsize param of

Code: Select all

int fl_startImageAdd(fl_BootImageInfo *bootImageInfo, unsigned maxsize,
                     unsigned padding);

see https://github.com/xcore/sc_flash/blob/ ... flashlib.c

[genap]

ok, it seems to work.
Boot-partition-size is 128K (64K images).
For a factory image I write data at 0x20000 (by using --data option).
For an upgrade image I write data at 0x30000
I have upgrade data concatenated at 0x10000 of the upgrade image.

To erase data sector I've added call to fl_eraseDataSector(2) in a function flash_cmd_erase_all() in flash_interface.c
DFU routines are modified:
pages are written as image pages up to 256 pages, then I write them as data pages starting at page 256 (address 0x30000).

The interesting thing is that if I set FLASH_MAX_UPGRADE_SIZE to anything more than 64K, an upgrade image and data are not written, though DFU panel claims that flash upgrade is successful.

[genap]

Now with data written as I want it, I have another problem.
Before the program execution I need to read the data from a data partition and move it somewhere else (to the secondary flash, controlled from the different custom core);

All the flash operations are defined in the DFU module.
I can read the data in the DFU core and use channels to send it to my custom module for programming.
But it requires quite a lot of data exchange, and increases the program size which is very important.

Another way is to get access to the flash from a custom module (separate core).
This is a preferable way, since no data exchange is required.

So far I was unable to get access to the flash from my module.
Will appreciate any advice on this matter.