XTAG2 firmware update?

Technical discussions related to any XMOS development kit or reference design. Eg XK-1A, sliceKIT, etc.
tonyshao
Junior Member
Posts: 6
Joined: Fri Jan 08, 2010 6:13 am

Re: XTAG2 firmware update?

Postby tonyshao » Thu Feb 18, 2010 3:27 pm

Do you have a full solution for this, we have a project same as this, we want to write a bootloader on XMOS board, and the app firmware is loaded at runtime.
User avatar
___
Member++
Posts: 30
Joined: Wed Feb 03, 2010 5:04 pm

Postby ___ » Fri Feb 19, 2010 3:13 pm

tonyshao wrote:Do you have a full solution for this, we have a project same as this, we want to write a bootloader on XMOS board, and the app firmware is loaded at runtime.
Pretty much, its is based on libusb and works on Linux / OSX and Windows. Currently we are supporting early access to USB projects through the official XMOS support system. If you submit a ticket explaining what you require then we would be happy to help.

https://www.xmos.com/rt3/SelfService/Cr ... Queue.html
User avatar
lilltroll
XCore Expert
Posts: 955
Joined: Fri Dec 11, 2009 3:53 am
Location: Sweden, Eskilstuna

Postby lilltroll » Sat Feb 20, 2010 9:47 pm

I think this is far beyond intresting - let's see this from a company - consumer - profit perspective.

Suppose I build a sound-card similair to the Audio 2.0 ref. design and start to sell the product.

First the customer needs to be able to reflash the flash memory with updates, whithout using the XTAG. (Afrer Win7 SP1 something needs to be changed, and on some laptops it crashes)
Also using a software USB-transciever - I (the company) can provide an Audio 2.1 update - the day Audio 2.1 becomes a standard. Other with Audio 2.0 hardware solutions cannot - and they will need to change the hardware as well.

Also - during firmware update x% of the customer will manage to crash there OS during the update - generating alot of unpaid support-time and send the device back to the "factory for updating with the programmer".
But with the possibillity with a bootloader in the OTP (Press a button and connect to the USB device) the end customer will be able to always connect to the card - making a new update or so.

Do I understand it correctly ?

Using a multi-kernel chip as G4 - how does the OTP work ??
Can I make a device that can be stand alone -booting from encrypted SPI-flash, connect it to USB from a PC and it staring to transfer data to the host, Press a button and connect to USB - boot from OTP and use a USB-bootloader where the customer can rewrite the flash in a Windows program, even after 5 computer crashes due to the fact that the cat watered the computer.
Probably not the most confused programmer anymore on the XCORE forum.
User avatar
___
Member++
Posts: 30
Joined: Wed Feb 03, 2010 5:04 pm

Postby ___ » Sun Feb 21, 2010 8:16 pm

lilltroll wrote: Do I understand it correctly ?
Yes :D

We are currently adding the standard USB firmware upgrade device class to our audio reference designs. See the document below if you are interested in the spec. You will be able to upgrade the device firmware via USB.

http://www.usb.org/developers/devclass_ ... bdfu10.pdf
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Postby Folknology » Sun Feb 21, 2010 11:14 pm

Wow thats usefull

Does this also effect my ticket #1385 request

Obviously this was in relation to XTag2 rather than the Audio USB ref board, but you seem to be indicating that this is generic for the USB class drivers.

I still very much want to close this ticket :)

regards
Al
User avatar
___
Member++
Posts: 30
Joined: Wed Feb 03, 2010 5:04 pm

Postby ___ » Mon Feb 22, 2010 11:02 am

The XTAG-2 is a custom device class, the firmware for the boot loader is programmed into the OTP and cannot be changed. The runtime firmware used by the debugger is loaded when required. The DFU mechanism is only currently being added to the audio designs.

Just to clear something up the firmware upgrade mechanism is not a boot loader as such, just a way of re-programming the flash to allow devices to be field upgraded. Most consumer products will not go out into the field with the JTAG enabled so a way of upgrading firmware is required.

The recommendation for 3rd party development boards for download and debug is that they use XSYS IDC connector. Putting the debug adaptor hardware on the development board is potentially a problem for the development tools. This needs to be standardised or else we run the risk of having to do tools development work for non-xmos development boards. This is not a good position for both xmos and the developer of the hardware.
User avatar
jonathan
Respected Member
Posts: 377
Joined: Thu Dec 10, 2009 6:07 pm

Postby jonathan » Mon Feb 22, 2010 11:53 am

___ wrote:The recommendation for 3rd party development boards for download and debug is that they use XSYS IDC connector. Putting the debug adaptor hardware on the development board is potentially a problem for the development tools. This needs to be standardised or else we run the risk of having to do tools development work for non-xmos development boards. This is not a good position for both xmos and the developer of the hardware.
Equally, if XMOS sells the XTAG-2 for a ludicrous $50, that effectively applies an "XMOS-tax" to anyone wanting to develop their own low-cost boards. This increases the barrier to entry where XMOS should be lowering it.

If you want to standardize on XTAG-2, you need to get rid of this barrier. Give it away to distribution (so it can be packaged with new boards), and sell it yourselves for $10.

The programmer is useless without XMOS boards, so you are making money - and more importantly, new customers - anyway.
Image
User avatar
___
Member++
Posts: 30
Joined: Wed Feb 03, 2010 5:04 pm

Postby ___ » Mon Feb 22, 2010 12:24 pm

jonathan wrote:
___ wrote:The recommendation for 3rd party development boards for download and debug is that they use XSYS IDC connector. Putting the debug adaptor hardware on the development board is potentially a problem for the development tools. This needs to be standardised or else we run the risk of having to do tools development work for non-xmos development boards. This is not a good position for both xmos and the developer of the hardware.
Equally, if XMOS sells the XTAG-2 for a ludicrous $50, that effectively applies an "XMOS-tax" to anyone wanting to develop their own low-cost boards. This increases the barrier to entry where XMOS should be lowering it.

If you want to standardize on XTAG-2, you need to get rid of this barrier. Give it away to distribution (so it can be packaged with new boards), and sell it yourselves for $10.

The programmer is useless without XMOS boards, so you are making money - and more importantly, new customers - anyway.
The XTAG-2 is actually pretty good value for the functionality offered and it is not being sold with a massive markup to "tax" the user base as you cynically suggest. Unfortunately things cost money to make.

See the following
http://www.sparkfun.com/commerce/categories.php?c=1
http://www.amontec.com/jtagkey2.shtml

You forget the device offers more functionality that the standard programming model for other boards such as the arduino platform.

Also the programmer can be used as a dev board if required and could be retargeted at other embedded development platforms so to describe it as useless is a matter of opinion.

If somebody would like to manufacture and distribute the XTAG-2 for less than $50 then we would be delighted to support it.
User avatar
jonathan
Respected Member
Posts: 377
Joined: Thu Dec 10, 2009 6:07 pm

Postby jonathan » Mon Feb 22, 2010 12:46 pm

XMOS is supposed to be disruptive. It still uses the tagline "revolutionising electronics". Don't call me cynical! I'm not cynical, I'm saying it's an "effective" tax... I'm not suggesting there's anything innately evil on XMOS' part. I just think the strategy is wrong...

Companies that intend to disrupt need to innovate - and that doesn't just mean in product - it means in strategy too.

1. Does anyone care about the increased functionality?
2. Have you asked your "customers" whether they want to pay $50 for a programmer with a million bells and whistles, or get one for $10 that does the job?
3. Will a cheaper/open programmer make it more appealing for others to design new development boards? Will this help XMOS or hinder XMOS?

It's irrelevant whether things cost money to make. The true economic cost of your engineering samples that you quite happily give away to customers is thousands of dollars per chip, if not more. There is nothing wrong with a strategy that involves losing money on stuff that isn't core market in order to increase total core market size.

Again - I don't think there's anything cynical going on! :-) These are just my thoughts on another way to look at strategy. I'm not the bad guy!
Image
User avatar
___
Member++
Posts: 30
Joined: Wed Feb 03, 2010 5:04 pm

Postby ___ » Mon Feb 22, 2010 12:52 pm

jonathan wrote:XMOS is supposed to be disruptive. It still uses the tagline "revolutionising electronics". Don't call me cynical! I'm not cynical, I'm saying it's an "effective" tax... I'm not suggesting there's anything innately evil on XMOS' part. I just think the strategy is wrong...

Companies that intend to disrupt need to innovate - and that doesn't just mean in product - it means in strategy too.

1. Does anyone care about the increased functionality?
2. Have you asked your "customers" whether they want to pay $50 for a programmer with a million bells and whistles, or get one for $10 that does the job?
3. Will a cheaper/open programmer make it more appealing for others to design new development boards? Will this help XMOS or hinder XMOS?

It's irrelevant whether things cost money to make. The true economic cost of your engineering samples that you quite happily give away to customers is thousands of dollars per chip, if not more. There is nothing wrong with a strategy that involves losing money on stuff that isn't core market in order to increase total core market size.

Again - I don't think there's anything cynical going on! :-) These are just my thoughts on another way to look at strategy. I'm not the bad guy!
Commercial customers have requested JTAG as standard for programming XMOS devices, the functionality of the XTAG-2 is based on this.

Who is online

Users browsing this forum: No registered users and 0 guests