XTAG2 firmware update?
-
- Junior Member
- Posts: 6
- Joined: Fri Jan 08, 2010 6:13 am
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.
-
- Member++
- Posts: 30
- Joined: Wed Feb 03, 2010 5:04 pm
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.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.
https://www.xmos.com/rt3/SelfService/Cr ... Queue.html
-
- XCore Expert
- Posts: 956
- Joined: Fri Dec 11, 2009 3:53 am
- Location: Sweden, Eskilstuna
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.
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.
-
- Member++
- Posts: 30
- Joined: Wed Feb 03, 2010 5:04 pm
Yes :Dlilltroll wrote: Do I understand it correctly ?
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
-
- XCore Legend
- Posts: 1274
- Joined: Thu Dec 10, 2009 10:20 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
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
-
- Member++
- Posts: 30
- Joined: Wed Feb 03, 2010 5:04 pm
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.
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.
-
- Respected Member
- Posts: 377
- Joined: Thu Dec 10, 2009 6:07 pm
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.___ 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.
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.
-
- Member++
- Posts: 30
- Joined: Wed Feb 03, 2010 5:04 pm
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.jonathan wrote: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.___ 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.
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.
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.
-
- Respected Member
- Posts: 377
- Joined: Thu Dec 10, 2009 6:07 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!
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!
-
- Member++
- Posts: 30
- Joined: Wed Feb 03, 2010 5:04 pm
Commercial customers have requested JTAG as standard for programming XMOS devices, the functionality of the XTAG-2 is based on this.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!