Infineon XMC1000, XMC4000

[Oliver Betz]

Hello All,

the Infineon ARM Cortex derivatives (XMC4000 CM4, XMC1000 CM0) look
very interesting. Advanced peripherals, good value for the money.

Is anybody actually working with them and wants to tell something
about what to observe?

TIA,

Oliver
--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:

[Uwe Bonnes]

Oliver Betz <ob...@despammed.com> wrote:
> Hello All,

> the Infineon ARM Cortex derivatives (XMC4000 CM4, XMC1000 CM0) look
> very interesting. Advanced peripherals, good value for the money.

> Is anybody actually working with them and wants to tell something
> about what to observe?

You should observe the request to accept an incredible restrictive licence
even when downloading the datasheet. For anything you tell in public, _you_
are required to prove that the fact was public know before or you may be sued.

Bye
--
Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

[j.m.gr...@gmail.com]

On Friday, November 15, 2013 12:46:55 AM UTC+13, Oliver Betz wrote:
> the Infineon ARM Cortex derivatives (XMC4000 CM4, XMC1000 CM0) look
> very interesting. Advanced peripherals, good value for the money.
>
> Is anybody actually working with them and wants to tell something
> about what to observe?

Yes, Nice parts, but XMC1xxx still showing 'coming soon' on the status lines.
They seem to be a long time hitting final release.

Meanwhile, there is also Cypress PSoC4, and Nuvoton, and Freescale MKE02Z all seem to be more available.

-jg

[Oliver Betz]

Uwe Bonnes wrote:

[...]

>> Is anybody actually working with them and wants to tell something
>> about what to observe?
>
>You should observe the request to accept an incredible restrictive licence
>even when downloading the datasheet. For anything you tell in public, _you_
>are required to prove that the fact was public know before or you may be sued.

I agree that it is extremly annoying, but although I'm not a lawyer,
I'm pretty sure that this is a paper tiger.

[Oliver Betz]

j.m.gr...@gmail.com wrote:

>> the Infineon ARM Cortex derivatives (XMC4000 CM4, XMC1000 CM0) look
>> very interesting. Advanced peripherals, good value for the money.
>>
>> Is anybody actually working with them and wants to tell something
>> about what to observe?
>
>Yes, Nice parts, but XMC1xxx still showing 'coming soon' on the status lines.
>They seem to be a long time hitting final release.

Correct. And the errata sheets for current silicon describe problems I
don't want to deal with.

>Meanwhile, there is also Cypress PSoC4, and Nuvoton, and Freescale MKE02Z all seem to be more available.

PSoC4 analog functions are somewhat disappointing, a PGA would be very
useful for me (currently I'm using an external chip for this). No low
pin count packages.

Nuvoton also lacks LPC packages, besides this it's oscillator
stability isn't good enough. Well, as long as Infineon doesn't get
their oscillator temperature compensation working (read: documented),
it's not better.

MKE02Z is IMO a compatibility kludge. Who wants to use still the old
9S08P peripherals, not even a fractional baud rate generator? Well, I
had less porting effort, because I have a siginificant 9S08 code base.
No LPC packages.

[MK]

On 15/11/2013 08:18, Oliver Betz wrote:
> Uwe Bonnes wrote:
>
> [...]
>
>>> Is anybody actually working with them and wants to tell something
>>> about what to observe?
>>
>> You should observe the request to accept an incredible restrictive licence
>> even when downloading the datasheet. For anything you tell in public, _you_
>> are required to prove that the fact was public know before or you may be sued.
>
> I agree that it is extremly annoying, but although I'm not a lawyer,
> I'm pretty sure that this is a paper tiger.
>
> Oliver
>

The legal nonsense that Infineon try to apply before you read a data
sheet may or may not have an real force but mainly it tells you about
the attitude of the supplier. I don't get this nonsense from NXP or ST
or TI or Freescale or SL - why should I bother with Infineon if they
start out by chucking legal bricks at me ?

Michael Kellett

[Simon Clubley]

I agree with you about NXP/ST/Freescale (I don't use SiLabs) but I don't
agree with including TI in that list.

If you try to download the example bare metal source kit from TI (called
StarterWare) you have to go through export control procedures. That's
insane for some example code which other vendors freely provide their
versions of on their own website. :-(

You have to wait several days for a download link to be emailed to you
and when it doesn't arrive and you contact TI, they want your full
contact details (including full home address and telephone number)
in order to establish that it's ok to download some sample code. :-(

I've no wish to be subjected to full export control checking and
stamping over my privacy just for some example code which can be
created anyway (with enough time) using the information publicly
available on TI's website. :-(

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[MK]

Thanks for the info Simon - I haven't got past data sheets with TI in
the last year or more.

Michael Kellett

[Simon Clubley]

You are welcome. This was for the version of StarterWare for the Beaglebone
Black, BTW.

Here's a copy of the email I was sent by TI when I asked why I didn't
receive the download link:

|Thank you for your inquiry submitted to Texas Instruments Semiconductor
|Technical Support. Due to export compliance and to help safeguard national
|security, Texas Instruments must know to whom they are providing information.
|This will only be necessary for your initial contact. Please use the link below
|to complete the contact information:
|
|http://www-k.ext.ti.com/sc/technical-support/email-tech-support.asp
|
|The following is a link to TI's privacy policy:
|http://www.ti.com/corp/docs/legal/privacy.htm

Note how the phone number, full postal address and email address are all
mandatory. Since I do my embedded work as a hobby this means they want
all my personal identification details, not some corporate identification
(hence the home address reference in my last message).

Absolutely and totally insane when required in the context of some "export
control", especially since what's been revealed over the last few months
about the US's misuse of their capabilities and how completely innocent
people are monitored just because they can be.

On the plus side, TI's TRM for the MCU on the Beaglebone Black is very
detailed indeed. I wish all manuals were this detailed.

I wish the Allwinner MCUs came with this level of detailed documentation.

[j.m.gr...@gmail.com]

On Friday, November 15, 2013 9:19:38 PM UTC+13, Oliver Betz wrote:
>And the errata sheets for current silicon describe problems I
>don't want to deal with.

You could ask Infineon what 'coming soon' really means, and when fixed silicon is due ?

> MKE02Z is IMO a compatibility kludge. Who wants to use still the old
> 9S08P peripherals, not even a fractional baud rate generator?

I have to agree that anyone supplying a 32 bit controller, they then decide to put 16 bit timers into (?!), needs their head read.

-jg

[Oliver Betz]

j.m.gr...@gmail.com wrote:

>>And the errata sheets for current silicon describe problems I
>>don't want to deal with.
>
>You could ask Infineon what 'coming soon' really means, and when fixed silicon is due ?

I did so, seems to be difficult to get information.

>> MKE02Z is IMO a compatibility kludge. Who wants to use still the old
>> 9S08P peripherals, not even a fractional baud rate generator?
>
> I have to agree that anyone supplying a 32 bit controller, they then decide to put 16 bit timers into (?!), needs their head read.

I guess they want to provide a painless path to more computing power
for 9S08P users. There are also Kinetis derivatives with better
peripherals.

Oliver
--
Oliver Betz, Munich http://oliverbetz.de/

[j.m.gr...@gmail.com]

On Saturday, November 16, 2013 9:44:17 AM UTC+13, Oliver Betz wrote:

> j.m...@gmail.com wrote:

> >You could ask Infineon what 'coming soon' really means, and when fixed silicon is due ?
>
> I did so, seems to be difficult to get information.

> unich http://oliverbetz.de/

I found this earlier projection, now ~11 months old
"Volume production is planned for Q4 2013"
so that looks to have slipped to Q1 2014, if they are still 'vague'.

Not the first time a vendor has slipped on a Micro roll out.

-jg

[Richard Damon]

The issue of "export control" is real. The US government has classified
certain technologies (like higher end computer chips, and boards using
them) as dangerous to be freely exported, and thus the questions. (and
the level of technology needed to reach this point isn't that high). The
key factor in making this determination is would it make it easier to
make some type of munitions, and with the restriction not just available
to anyone (i.e, do the non-US controlled manufactures make this type of
part or not) TI asks for the info because if they don't, they are
subject to significant sanctions.

[Jochen]

responding to
http://www.electrondepot.com/embedded/infineon-xmc1000-xmc4000-129942-.htm ,
Jochen wrote:
Hi all,

That chat is really interesting but I don愒 see your problems to be honest.

Asking for experiences of Infineon愀 ARM Cortex devices and ending up in a
chat about normal/standard disclaimer topics is strange.
Of course they put in this disclaimer, but you惻l find those limitation with
nearly every vendor of semis and they are forced to do so ? see Richard Damon
comment.

Coming to the real think ? the families of M0 & M4 is already available and
Infineon is offering samples, development kits and their IDE tool since a
long time.

We got a small kit during the trade show and we ordered several via our local
Distributor and I have to say, that our results met our expectations so far.
Also I like their set up of Dave ? quite useful to get started.

Why don愒 you contact them directly and raise your concerns to them ? I guess
they would like to get the feedback directly and will solve that

c u

Jochen

[Simon Clubley]

On 2013-11-15, Richard Damon <Ric...@Damon-Family.org> wrote:
>
> The issue of "export control" is real. The US government has classified
> certain technologies (like higher end computer chips, and boards using
> them) as dangerous to be freely exported, and thus the questions. (and
> the level of technology needed to reach this point isn't that high). The
> key factor in making this determination is would it make it easier to
> make some type of munitions, and with the restriction not just available
> to anyone (i.e, do the non-US controlled manufactures make this type of
> part or not) TI asks for the info because if they don't, they are
> subject to significant sanctions.

Oh, I totally agree the issue of export control is real and I fully support
the use of export controls when the items in question justify it.

However, it seems really strange to place a _very_ detailed Technical
Reference Manual on the TI website for unrestricted download and then
apply export control to a piece of example software which just allows
you to get up to speed more quickly on the material already publicly
available in the TRM.

The real blocker on being able to use the MCU in your own projects is
access to the knowledge contained in the TRM, not the convenience factor
of having access to some example code.

Blocking access to the example source code without blocking access to
the TRM doesn't achieve anything in the long term so it just gives the
illusion of having done something without actually achieving a real goal.

If TI wanted to do export control in a meaningful way, they would also
block access to the TRM. However, I suspect that would just damage their
MCU business because people would probably just switch to products from
vendors which didn't have such restrictions.

It's also hard to understand how anything to do with a commodity MCU
based around the widely available Cortex-A8 architecture could ever be
considered eligible for export control.

[Anders....@kapsi.spam.stop.fi.invalid]

Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:

> It's also hard to understand how anything to do with a commodity MCU
> based around the widely available Cortex-A8 architecture could ever be
> considered eligible for export control.

Hardware crypto acceleration?

-a

[Simon Clubley]

15 years ago that _may_ have been a viable answer but not today as it
seems to be becoming a standard feature on today's MCUs.

As a aside, there's a very serious question (in light of recent revelations)
about if hardware crypto support can still be trusted. I know I'm going to
steer clear of it from now on if at all possible.

[David Brown]

On 19/11/13 13:46, Simon Clubley wrote:
> On 2013-11-19, Anders....@kapsi.spam.stop.fi.invalid <Anders....@kapsi.spam.stop.fi.invalid> wrote:
>> Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
>>
>>> It's also hard to understand how anything to do with a commodity MCU
>>> based around the widely available Cortex-A8 architecture could ever be
>>> considered eligible for export control.
>>
>> Hardware crypto acceleration?
>>
>
> 15 years ago that _may_ have been a viable answer but not today as it
> seems to be becoming a standard feature on today's MCUs.
>
> As a aside, there's a very serious question (in light of recent revelations)
> about if hardware crypto support can still be trusted. I know I'm going to
> steer clear of it from now on if at all possible.
>
> Simon.
>

Hardware cryptographic accelerators are fine to trust - they just carry
out certain mathematical operations faster than the cpu would do. It is
the algorithms, the implementation of them, and the parameters involved
that need extra paranoia. Some standard algorithms such as RSA, AES and
3-DES are fine, and any implementation (whether it uses a hardware
accelerator or not) should be simple enough to make any backdoors stand
out in the source code. (Things like differential power analysis, cache
timing attacks, etc., are always very difficult to control.)

For other algorithms such as elliptical curve cryptography, the maths
appears sound but the parameters used are questionable (especially where
the NSA or NIST has been involved), and the some of the PRNG generators
are highly suspicious.

If you are paranoid enough, then you should be wary of hardware RNG's
and PRNG's - these can have hidden backdoors to make predictable
sequences. Always try to mix in some real entropy (delays in timers,
keypresses, resistor thermal noise, etc.).

[Anders....@kapsi.spam.stop.fi.invalid]

Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
> On 2013-11-19, Anders....@kapsi.spam.stop.fi.invalid <Anders....@kapsi.spam.stop.fi.invalid> wrote:
>> Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
>>
>>> It's also hard to understand how anything to do with a commodity MCU
>>> based around the widely available Cortex-A8 architecture could ever be
>>> considered eligible for export control.
>> Hardware crypto acceleration?
> 15 years ago that _may_ have been a viable answer but not today as it
> seems to be becoming a standard feature on today's MCUs.

AFAIK, some algorithms are still under export control in the US, at
least with sufficient key length. Restrictions do seem to be looser, eg.
Microchip's application libraries contains only stub implementations of
the crypto functions, and you used to have to order them separately. Now
it seems you can just download them, but the download page still carries
a notice about export control (<http://tinyurl.com/nfp9wfd>)

> As a aside, there's a very serious question (in light of recent
> revelations) about if hardware crypto support can still be trusted. I
> know I'm going to steer clear of it from now on if at all possible.

Even without the snooping hoopla, a well-known software implementation
is probably safer than unknown hardware. Now it's just impossible to
discriminate honest hardware bugs from malicious interference.

-a