XFlash question: including data file with DFU upgrade

Technical questions regarding the XTC tools and programming with XMOS.
User avatar
Caleb
Experienced Member
Posts: 82
Joined: Thu Apr 04, 2013 10:14 pm

XFlash question: including data file with DFU upgrade

Post by Caleb »

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


User avatar
Ross
XCore Expert
Posts: 968
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

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.
User avatar
Caleb
Experienced Member
Posts: 82
Joined: Thu Apr 04, 2013 10:14 pm

Post by Caleb »

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
User avatar
Ross
XCore Expert
Posts: 968
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

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.
User avatar
Caleb
Experienced Member
Posts: 82
Joined: Thu Apr 04, 2013 10:14 pm

Post by Caleb »

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
User avatar
Ross
XCore Expert
Posts: 968
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

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)
User avatar
Caleb
Experienced Member
Posts: 82
Joined: Thu Apr 04, 2013 10:14 pm

Post by Caleb »

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.
User avatar
Caleb
Experienced Member
Posts: 82
Joined: Thu Apr 04, 2013 10:14 pm

Post by Caleb »

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?
User avatar
Ross
XCore Expert
Posts: 968
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

Caleb wrote:#if undef FLASH_MAX_UPGRADE_SIZE handler in flash_interface.c.
is "undef" a typo?

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
User avatar
Caleb
Experienced Member
Posts: 82
Joined: Thu Apr 04, 2013 10:14 pm

Post by Caleb »

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