stand-alone xflash utility

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
genap
Experienced Member
Posts: 86
Joined: Sat Aug 31, 2013 11:23 pm

stand-alone xflash utility

Postby genap » Fri Feb 28, 2014 5:21 pm

Is there xflash utility I can install and use without installing Composer Studio ?
Also is it anything special about Composer Studio C Prompt or I can use regular Windows command prompt ?

Thank you,
Gennady
User avatar
Bianco
XCore Expert
Posts: 754
Joined: Thu Dec 10, 2009 6:56 pm

Postby Bianco » Fri Feb 28, 2014 5:39 pm

I doubt that xflash can run standalone because it will generate a new flasher firmware every time.
It problably also depends on xgdb.

There is nothing special about the XMOS command prompt, other than that it will call a bat or shell file to set up the environment. You can use any command prompt and execute the SetEnv.{bat/sh} file that can be found in the root directory of the xTIMEcomposer studio installation dir.
User avatar
Bithium
Newbie
Posts: 1
Joined: Wed Aug 13, 2014 7:01 pm

Postby Bithium » Fri Sep 12, 2014 4:48 pm

Hello,

I have kind of the same question...
If I want someone to just program the flash with the XMOS application is there any simple application other than having to install the entire xTimecomposer?

Thanks in advance.

Best regards,
André

@genap, sorry for hijacking your post.
User avatar
Bianco
XCore Expert
Posts: 754
Joined: Thu Dec 10, 2009 6:56 pm

Postby Bianco » Fri Sep 12, 2014 5:41 pm

There is no standalone xflash because this is a fairly complicated process involving running a flash application on the chip itself communicating with the host.

Other options are: in/out of circuit SPI flash programmer.

For in-field updates you can use a bootloader or something like DFU.
AlexAdvice
Experienced Member
Posts: 125
Joined: Sun Feb 23, 2014 11:30 am

Postby AlexAdvice » Wed Sep 17, 2014 10:02 am

Bianco wrote:T
Other options are: in/out of circuit SPI flash programmer.

For in-field updates you can use a bootloader or something like DFU.
Burning EEPROM separately is a good solution, but, if we want copy protection - in any case we must use xflash to burn CPU's OPT, as I understood.
AlexAdvice
Experienced Member
Posts: 125
Joined: Sun Feb 23, 2014 11:30 am

Postby AlexAdvice » Sat Oct 11, 2014 11:53 am

Two questions:

1) EEPROM consists of:
- Bootloader+Factory Firmware
- FW Upgrade 1
- FW Upgrade 2
...
- FW Upgrade n

Q: what will me when the memory ends? Next upgrade FW will be written at 1st position ?


2) Is it possible in standard bootloader, that it will write CPU' OTP once (during the 1st start)?
(to avoid CPU burning during production, burning just EEPROM, before assembly at PCB.)

I do not undestrand for what "--make-exec" option of xburn is intended?

Thank you.
colin
Experienced Member
Posts: 74
Joined: Mon Dec 16, 2013 12:14 pm

Postby colin » Mon Oct 13, 2014 3:51 pm

In answer to question 1, the XFLASH utility will fail, indicating there is no more memory available for the upgrade image. You can alternatively use the flashlib API to create your own DFU process where you can erase / replace upgrade images.

In answer to question 2, the booloader does not currently provide the ability to write to the OTP on first boot. A two step process is required using XBURN and XFLASH.

The --make-exec option for XBURN allows for the program generated by XBURN to be saved. This program can then be run using XRUN on each device where the information written to OTP does not change.
AlexAdvice
Experienced Member
Posts: 125
Joined: Sun Feb 23, 2014 11:30 am

Postby AlexAdvice » Tue Oct 14, 2014 2:03 pm

For Q2 I understood :(
For Q1 - not.
the XFLASH utility will fail,
Upgrade is making not with XFLASH utility, so it is Booloader, which can fail, but I cannot imagine that the developers of the Bootloader makes this upgrade possible few times only.

Smallest flash, like 25x010 has 128Kbytes memory, bootloader+factory_image maximum needs ~64KB, bootloader = 8KB. If the upgrade binary is 48K, there is only one upgrade is possible!
I do not beleive!
Maybe somebody from the bootloader developer can clear this issue?
AlexAdvice
Experienced Member
Posts: 125
Joined: Sun Feb 23, 2014 11:30 am

Postby AlexAdvice » Thu Oct 23, 2014 7:25 am

So, can anybody from XMOS to clarify this issue ?
colin
Experienced Member
Posts: 74
Joined: Mon Dec 16, 2013 12:14 pm

Postby colin » Fri Oct 24, 2014 10:31 am

The xflash utility is used to program factory and upgrade images to flash. If there is no more flash space available then xflash will not write any more upgrade images.

If using a small flash where only one factory image and one upgrade image fits into memory, then you will need to erase and replace the sector containing the upgrade image to perform additional upgrades. You can do this as many times as you wish however you will need to produce your own DFU process using flashlib to achieve this. Guidance on doing this is provided in the document Design and manufacture systems with flash memory under the section header "Perform an in field upgrade".

The bootloader scans flash memory and boots the image with the highest version number. Assuming that it finds a valid upgrade image, then it will boot this image, otherwise it will fall back on the factory image. This process can also be changed by using the --loader option with xflash. Guidence is also provided in the same document under the heading "Customize the flash loader".

Who is online

Users browsing this forum: No registered users and 5 guests