XMOS Silicon Problems?

Technical discussions around xCORE processors (e.g. General Purpose (L/G), xCORE-USB, xCORE-Analog, xCORE-XA).
kster59
XCore Addict
Posts: 162
Joined: Thu Dec 31, 2009 8:51 am

XMOS Silicon Problems?

Postby kster59 » Wed Jan 26, 2011 10:15 am

I'm programming a production product and programmed over 300 XMOS L1-64 devices using the XTAG2.

However, approximately 5% of these fail to lock and burn the AES encryption key.

I have several batches and have always had this problem. The device works fine unlocked but cannot take the AES encryption lock/blow the fuses.

Is this a known problem on the XMOS L1-64 silicon?
User avatar
leon_heller
XCore Expert
Posts: 546
Joined: Thu Dec 10, 2009 10:41 pm
Location: St. Leonards-on-Sea, E. Sussex, UK.

Postby leon_heller » Wed Jan 26, 2011 11:51 am

I'd contact customer support directly about a problem like that, it'll save time.
bearcat
Respected Member
Posts: 277
Joined: Fri Mar 19, 2010 4:49 am

Postby bearcat » Thu Jan 27, 2011 1:51 am

Glad that you posted your experience with this.

Do you have any tips or pointers with using AES encrypted firmware? Did you follow the user tools guide exactly, or is there some deviations. Hate to ruin many parts / boards trying this in the near future.
Looks like I definately need to plan on a hot air rework station.

Did you create a custom bootloader by chance? I am interested in this topic also.
kster59
XCore Addict
Posts: 162
Joined: Thu Dec 31, 2009 8:51 am

Postby kster59 » Thu Jan 27, 2011 3:58 am

AES encryption works great when the chip takes the burn.

I generated the program as shown in the manual:
xburn --target-file target.xn --lock keyfile -o aes-programmer.xe

I run:
xrun --id 0 aes-programmer.xe

Usually it works but probably somewhere between 2-5% of the times it doesn't.

I can tell it doesn't work because this is supposed to disable the JTAG and programming.

When it works, I cannot execute the chip again. When it doesn't work, I can program the chip over and over again but of course it can never execute the encrypted lock.

Seems like XMOS is having Silicon problems and I am working with them and will send them my samples.

Maybe the solution is to buy preprogrammed boards with the key already burned in and get an external SPI flash programmer.
User avatar
segher
XCore Expert
Posts: 843
Joined: Sun Jul 11, 2010 1:31 am

Postby segher » Thu Jan 27, 2011 2:14 pm

kster59 wrote:When it works, I cannot execute the chip again. When it doesn't work, I can program the chip over and over again but of course it can never execute the encrypted lock.
So you are saying OTP isn't programmed, or at least the config line isn't? Have you
tried looking at the OTP after it failed, see if anything is there?
Seems like XMOS is having Silicon problems and I am working with them and will send them my samples.
That sounds like a good plan.
Maybe the solution is to buy preprogrammed boards with the key already burned in and get an external SPI flash programmer.
Maybe the problem is something else entirely, for example your power supply might be
marginal.

Please let us know when you have any news; and good luck.
kster59
XCore Addict
Posts: 162
Joined: Thu Dec 31, 2009 8:51 am

Postby kster59 » Fri Jan 28, 2011 9:16 am

I was using an older version of the tools and upgraded to 10.4.2 and was able to recover a number of unflashable boards. XMOS tells me there was a new algorithm to program the OTP in 10.4.2.

Actually I was using 10.4.2 but I had compiled the xburn AES encryption program using the old tools and running the .xe file with the new tools. After recompiling with the new tools a majority of the unflashable boards flashed :)

Power supply was good and 1.0V better than +/-0.01% with .9v undervoltage detector.

Still have a few bad boards but probably ~1% and not 5%. Still I think it should be 1 in 1,000,000 yields if XMOS wants to compete against the major players.

Who is online

Users browsing this forum: No registered users and 4 guests