Luminary Micro

There is also one specifically for the Luminary Micro Cortex M3 ARM chips.

Takes some time to fix all the peripherals, but I think many (most/all?) will be fixed, My guess, (but I dont know) is that the fixes will be applied to new parts and to older parts when it is time to do a shrink.

I would be willing to bet that some of your errata on the SAM7S parts is costing you design wins. The one where using the JTAG port causes damage to a pin which raises the static Icc has got to be a problem for some customers who want to use the JTAG in a very low power design.

It bothers me when any manufacturer has errata and no clear plans to fix it. In that case I think they should change the data sheet to show the degraded specs and update it again when they do the fix.

It irks me even more when a sales person touts a spec that he knows is compromised by the errata. That is nothing other than dishonest.

I imagine a fix is a complicated process, requiring retesting of everything, it's a resources issue, do I work on the brand new chip or fix secondary problems on an existing chip (well secondary to most, primary for some)

most designers already assume datasheet is really datasheet + errata

yes if he knows

Yes, that is why they need to be fixed.

You do not need to use JTAG unless you want to debug. It is not common to debug a production unit. I think that higher ICC can be tolerated by most for prototyping Boundary Scan testing is of course a problem. If you really want the SAM7S, then there are parts available without the bug. Maybe not the right memory configuration, but then there may be features you really like in the chip, and are prepared to pay for those features.

I am not sure that you know which plans Atmel has. The JTAG bug is already fixed for some SAM7S parts and when a spin is done on the chip, I am pretty confident that the fix will be introduced in those chips as well. It is quite expensive to do a spin of a chip, not only the cost of doing the chip. (Which can cost $1-2M or more)

You have to lose a lot of orders to finance this money. I am sure that if you cough up an order for a couple of million parts you will get the fix promptly.

There is also the cost of not doing another chip. For instance, I think that if Atmel froze the design of the AT91SAM9260 and instead fixed the AT91SAM7Sxx JTAG issue, then the company would be hurt significantly.

Does that mean that Atmel is happy about the problem? I don't think so. I am sure this will be fixed, but maybe someone wants to fix a number of other bugs as well before the chip gets a new rev.

No, Atmel had this approach, and the decision was made to abandon this. The Datasheet is a collection of chapters describing peripherals. The chapters are shared between datasheets for different parts. If there is any deviation from the definition, then this will be listed in the errata. This means that the errata will be longer than if the approach to integrate bugs as features remained.

This decision allows datasheets to become available earlier than if Atmel has kept the previous approach. It is considered more important that information is available early than available late (or very late) as an integrated part of the datasheet.

Lying and unknowledgeable sales persons is always a problem, but as long as the errata is available, you have all info you need to make a decision. Only when the errata is not published promptly when found, you can claim that the "company" is really at fault.

I say you have no clear plans to fix it, you criticize me for not knowing your plans and then you justify the fact that you don't have a plan to fix it. Clearly Atmel has no plans to fix this bug (and many others). It will get fixed when Atmel has the opportunity. Also, I will note, I was told that Atmel does not know how to fix it. They have a couple of chips that work ok and a couple that have the bug. Seems it is a bit of a crap shoot whether a new design will have it or not. Does the 7S321 have the problem? That might be why they don't fix it.

Why does "happy" have any bearing here? The bottom line is that if you want to use the JTAG port on the parts in production, the quiescent current is not what is published in the data sheet. It has been buried in the errata which allows salesmen to brag about the low quiescent current. Since there is no actual plan to fix the problem the engineers have to live with it.

This is a red herring. You can provide the data sheet just as quickly if you add the errata or update the body. Either way requires writing, reviewing and approval before publication. But burying it in the errata gives a vendor an opportunity to "present" false facts about things like quiescent current that can't be achieved easily in a production environment.

Yes, we must always remember, "Caveat Emptor". It would be nice if vendors were honest with their intentions, but instead they promise that they are "commited" when they really should be saying, "we have no idea when we will fix this bug".

This circular logic is a little lost on me. Isn't errata information that should be available early ?

I note that the AVR data sheets DO have included errata, and errata history, (which I've thought is a good idea) - are you saying Atmel is now dropping this, or are you saying that the ARM division of Atmel uses different rationale on their errata, than the AVR division ?

-jg

Atmels AT91 team makes decisions totally independent from the AVR team. I believe both teams have a policy to published errata once they are verified.

The question is if what happens if a problem in a peripheral is detected.

A good example is the PLL in the AT91RM9200. You have to program the PLL in a certain sequence. This is a problem in the PLL block which eventually may be fixed. (AFAIK: It will not be fixed in the AT91RM9200, since Atmel swapped its rights for the ARM920T core to ARM926EJ-S)

Rickman wants the *PLL chapter* to be modified and Atmel has decided not to modify the chapter, but instead include the restrictions in the *errata*.

If the PLL is fixed in a new part, then exactly the same chapter can be used as is in the new datasheet, but the errata will be removed. This approach saves a lot of time, and if the earlier approach would be used, then the datasheet would be delayed significantly. No need to argue, this is a fact.

Atmel may have clear plans which are not public.

Like in every other company, It will be fixed if and when Atmel believes it makes sense.

Maybe your source was misinformed?

The Errata IS published in the datasheet and alwasy overrides anything else in the datasheet. It is the most important part of the datasheet for any designer.

You seem to think that it is OK to do designs without looking at the errata. Very dangerous in my opinion.

Very simple: Atmel has not hidden the fact, As long as the information is publicly available anyone can make an intelligent decision about if they can or cannot live with the errata. You may be irritated that you thought the SAM7S was an ideal part and spent a lot of time investigating / designing with the part and then found out later that because of this issue,it is unusable. Then you might want to consider changing your purchasing channel.

No, the idea is that chapters are approved once and for all, and then reused for every chip using the module. If there are discrepancies between the part and the chapter, then they are published in the errata. Saves tons of time, especially for people using lots of parts.

The fact is that while many prefer to use JTAG Boundary scan for production it is not neccessary. If you are using the JTAG purely for flash programming, the SAM7S has many other options.

Again, this may or may not be true. Maybe there are 20 bugs that should be fixed, before a new spin is made, and it can take a lot of time to fix all those 20 bugs. There may be plans to fix bugs, even though there may be no official release date.

You shouldn't put words in my mouth. I said that if you don't have plans to fix the bug, you should update the chapter. You say you have "plans", but I have been watching the power consumption for nearly a year and still can not get a date for a fix. Are you saying that they are working on a fix? Does Atmel understand why this bug exists?

The fact is that you can reuse the chapter and change the errata, or you could reserve eratta for things you plan to fix and keep the chapters realistic (saving your customers design time). No need to argue, this is a fact.

BTW, I don't appreciate all the assumptions you made about my thinking regarding my other post. I won't reply in detail since you clearly don't know what I have done in my designs or my thinking. Enough said? I have not been burned, I just know what I have been told about Atmel's "commitment" to fixing errata and what I am observing, not to mention your comments.