I'm hoping to determine if it's possible to add data to a DFU file. The purpose is to use DFU to upgrade the XMOS device's firmware and at the same time include a data file that the XMOS (once it re-boots) will use to upgrade firmware on another processor.
It seems me that it's only possible to xflash a data file only when programming the boot sector. I wonder if I'm missing something. Is there some way to use command-line xflash options so as to combine a data file into a DFU upgrade image?
Otherwise, perhaps there's a way to concatenate a data file with the XMOS binary prior to using xflash to create the DFU - in such a way that it doesn't interfere with proper booting.
I'll appreciate any help and suggestions. thanks
XFlash question: including data file with DFU upgrade
-
- Experienced Member
- Posts: 82
- Joined: Thu Apr 04, 2013 10:14 pm
-
- XCore Expert
- Posts: 968
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
Yes this can be done, you can cat the binary data onto the end of the image you are DFU'ing.
Make sure the MAX_IMAGE_SIZE is set high enough though, else the flash library will raise an exception.
Make sure the MAX_IMAGE_SIZE is set high enough though, else the flash library will raise an exception.
-
- Experienced Member
- Posts: 82
- Joined: Thu Apr 04, 2013 10:14 pm
Hi Ross,
This does seem to work. However, it seems a bit hacky. It seems that I'm relying on the fact that the dfucons doesn't evaluate the file that you ask to send to the device. Is there reason the expect that this behavior will continue with future revisions of tools, drivers, etc.; it's currently unspecified?
Thanks, Caleb
This does seem to work. However, it seems a bit hacky. It seems that I'm relying on the fact that the dfucons doesn't evaluate the file that you ask to send to the device. Is there reason the expect that this behavior will continue with future revisions of tools, drivers, etc.; it's currently unspecified?
Thanks, Caleb
-
- XCore Expert
- Posts: 968
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
Correct, the DFU host program doesn't look at the file contents. At the moment I can't think of a reason why this would change.
And yes, its bit hacky. Ideally a tool would move things around based on flash sector sizes etc.
And yes, its bit hacky. Ideally a tool would move things around based on flash sector sizes etc.
-
- Experienced Member
- Posts: 82
- Joined: Thu Apr 04, 2013 10:14 pm
I'm want be clear too - from what you wrote earlier:
"Make sure the MAX_IMAGE_SIZE is set high enough though, else the flash library will raise an exception."
By MAX_IMAGE_SIZE , you're referring to the third optional argument to xflash --upgrade?
XFLASH --upgrade <id> <file> [size] -o filename
What will the flash library fail on? Is this value encoded in the upgrade image - and if so (and if I set the image size equal to the sum of the upgrade image + the additional data) , will the Flash Loader load the additional data into the remaining RAM, perhaps overflow the RAM, cause some error?
Or, does this impact location of upgrade image #2 after DFU of image #1 where no upgrade image size was indicated?
It's not clear to me how the DFU endpoint decides where to start writing images following a previous image. Does it use a size that's encoded in the previous image or does it look for the first sector that's blank? And, does it check ahead for sectors to be blank before writing so that, for example, it does not corrupt a data partition located at the end of the flash?
thanks
"Make sure the MAX_IMAGE_SIZE is set high enough though, else the flash library will raise an exception."
By MAX_IMAGE_SIZE , you're referring to the third optional argument to xflash --upgrade?
XFLASH --upgrade <id> <file> [size] -o filename
What will the flash library fail on? Is this value encoded in the upgrade image - and if so (and if I set the image size equal to the sum of the upgrade image + the additional data) , will the Flash Loader load the additional data into the remaining RAM, perhaps overflow the RAM, cause some error?
Or, does this impact location of upgrade image #2 after DFU of image #1 where no upgrade image size was indicated?
It's not clear to me how the DFU endpoint decides where to start writing images following a previous image. Does it use a size that's encoded in the previous image or does it look for the first sector that's blank? And, does it check ahead for sectors to be blank before writing so that, for example, it does not corrupt a data partition located at the end of the flash?
thanks
-
- XCore Expert
- Posts: 968
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
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)
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)
-
- Experienced Member
- Posts: 82
- Joined: Thu Apr 04, 2013 10:14 pm
Great info - I get it now. However, the parameter is FLASH_MAX_UPGRADE_SIZE - at least in the last 2 versions of the USB audio projects anyway.
thanks very much for the help.
thanks very much for the help.
-
- Experienced Member
- Posts: 82
- Joined: Thu Apr 04, 2013 10:14 pm
It seems that I've found a bug related to this (in the USB Audio v6.1 project):
The build flag -DFLASH_MAX_UPGRADE_SIZE in makefile does not override the default / #if undef FLASH_MAX_UPGRADE_SIZE handler in flash_interface.c.
Although I modified makefile to -DFLASH_MAX_UPGRADE_SIZE=512*1024, a DFU operation will not write past flash address 0x20000 (for upgrade 1). However, it will write past flash address 0x20000 if I modify flash_interface.c this way:
//#define FLASH_MAX_UPGRADE_SIZE 128 * 1024 // 128K default
#define FLASH_MAX_UPGRADE_SIZE 512 * 1024 // 512K default
I know I don't fully grasp everything in makefile. I wonder if there is some override of BUILD_FLAGS for module_dfu or if there is a problem passing defines to .c files...or maybe I'm overlooking something much more obvious?
The build flag -DFLASH_MAX_UPGRADE_SIZE in makefile does not override the default / #if undef FLASH_MAX_UPGRADE_SIZE handler in flash_interface.c.
Although I modified makefile to -DFLASH_MAX_UPGRADE_SIZE=512*1024, a DFU operation will not write past flash address 0x20000 (for upgrade 1). However, it will write past flash address 0x20000 if I modify flash_interface.c this way:
//#define FLASH_MAX_UPGRADE_SIZE 128 * 1024 // 128K default
#define FLASH_MAX_UPGRADE_SIZE 512 * 1024 // 512K default
I know I don't fully grasp everything in makefile. I wonder if there is some override of BUILD_FLAGS for module_dfu or if there is a problem passing defines to .c files...or maybe I'm overlooking something much more obvious?
-
- XCore Expert
- Posts: 968
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
is "undef" a typo?Caleb wrote:#if undef FLASH_MAX_UPGRADE_SIZE handler in flash_interface.c.
modifying my flash_interface.c with an #error shows that FLASH_MAX_UPGRADE_SIZE is defined for me (since I get a build error)
Code: Select all
#ifndef FLASH_MAX_UPGRADE_SIZE
#define FLASH_MAX_UPGRADE_SIZE 128 * 1024 // 128K default
#else
#error
#endif
-
- Experienced Member
- Posts: 82
- Joined: Thu Apr 04, 2013 10:14 pm
Yes typo
Sorry, I ignored the fact that modifying makefile doesn't cause a rebuild of the project.
This is indeed working. I should take note of the usefulness of the #error.
thanks
Sorry, I ignored the fact that modifying makefile doesn't cause a rebuild of the project.
This is indeed working. I should take note of the usefulness of the #error.
thanks