You might file a CASE but I believe cause was settling time to
12 bits for a 5V step input could not be met.
To create a technical or issue case at Cypress -
“Create a Case”
You have to be registered on Cypress web site first.
I see that a choice of external Vref will allow 1 Msps (this probably is no
relief for you) -
I already have filed a case. There they told me to redo my projects.
We have not had problems. We need speed more than absolute accuracy.
And my feeling is that you then add a warning that performance might be degraded at high sample speeds. You do not cut of the customers foot just because the shoe you have made is half a size too small.
My designs have been signed off. I do not have the time to retune all the PID loops because the timing is changed.
Cypress has caused concern with my employer that chips change specification a year into our designs, so we have started looking at other CortexM0 suppliers with a "fixed" architecture.
Sorry about my venting, but Cypress' arrogance is shocking.
Maybe no consolation but over 40 years of industry involvement I
have witnessed vendors who did not believe in full disclosure until
caught with their britches down. Fortuately most of that seems to
have been put behind us.
Sorry to lose you as a customer.
Actually the revision notes for SAR_MUX_ADC_P4 data sheet say in version 2.09 that the maximum sample rate has been lowered for Vdda refs.
What you can do, actually, is to just use an older version of the component (or maybe of Creator). These are lesser known features of Creator - Creator versions can be installed in parallel, and the old versions of components are still part of it. So iof you depend on a certain behavior of a component in a certain component that gets changed, you just keep using the old one.
We are sorry that this change impacted you so badly. Unfortunately we discovered that, with the non-bypassed Vdda-based reference voltages, the SAR was out of spec at 1Msps. We did not arbitrarily de-spec the device (but I can see that it looks that way). In this situation we were required to make the change to the component so that new uses would not allow an out-of-spec use case. That had a bad impact on existing uses (your situation) where rate and range were more important than accuracy. Again, I apologise for that and we need to look at how we communicate changes like this in the future. Ideally, of course, we won't have to do them at all.
Back-revving the component, as hli proposes, will, indeed, allow you to build the configuration you need but it will not have the (previously) claimed accuracy.
Since I never down-graded a component: is there a guide how to do that?
A post you answered not too long ago -
Oh, I did not think of using the upgrade dialog to downgrade a component :) But its easier I guess than replacing it (since it should retain the configuration, if any).