6 Replies Latest reply on Apr 8, 2019 8:27 AM by LePo_1062026

Undefined behaviour VDAC8

Dear community,

For the final part of my internship I have coded an algorithm from floating point operation to fixed-point integer math. At the end of my algorithm I convert the fixed-point 32bit number to an input for the VDAC. After programming the PSoC, the values are as expected. However, if I reset the PSoC with the button on the programmer board, the values are not as they should. This looks as the following:

The value of the yellow line should be around 2.6V. Does anyone have a clue as to how this behaviour could be generated? I already reset all my variables to 0 at the top of the algorithm. Setting the VDAC to 0 would be silly, as that destroys the entire idea I am trying to achieve.

I have added my project as an archive.

With kind regards,

Jim

• 1. Re: Undefined behaviour VDAC8

Jim,

I've got some time right now to help.

I compiled the app.  No problem.

However, you're missing some information:

• Is there specific input stimulus for P0[5]  and P0[7]?  The SOC of the SAR will occur when P0[5] crosses P0[7] in either direction.
• What is the input requirements for P3[1]?  I assume the P3[1] derives the results of outputs on P0[0] or  P3[7] through some formula.

Without some guidance about the proper input stimulus, I can't get any outputs on P0[0] or  P3[7].

I noticed you're using a raw call to the ADC register.  Unless absolutely necessary  I recommend  against it.

Here's another potential issue:  Your assigned Reference = External Vref using a bypass cap on P0[2].  The Vref value is 2.048V.  Are you sourcing an external reference voltage of 2.048V?

Len

• 2. Re: Undefined behaviour VDAC8

Hi Len,

• Is there specific input stimulus for P0[5]  and P0[7]?  The SOC of the SAR will occur when P0[5] crosses P0[7] in either direction.
• Yes, this is true, as this is a requirement in my internship
• What is the input requirements for P3[1]?  I assume the P3[1] derives the results of outputs on P0[0] or  P3[7] through some formula.
• To use the full range of the SAR, the input has to be a sinusoidal signal with 4Vpp and a bias of 2V. This gives maximum use of the 8 bits and hence more accuracy in the algorithm written in C.
• I saw the suggestion to use a register call in the datasheet of SAR, but I will test your suggestion.
• Are you sourcing an external reference voltage of 2.048V?
• Yes, I supply this externally.

Hopefully you are able to get an output now and give me more insight in the undefined behaviour.

Jim

• 3. Re: Undefined behaviour VDAC8

Jim,

I'm  starting on your issue with the new info.  I can use a little more refinement:

• Is there specific input stimulus for P0[5]  and P0[7]?  The SOC of the SAR will occur when P0[5] crosses P0[7] in either direction.
• Yes, this is true, as this is a requirement in my internship

For simplicity sake, I'm going to have the PSoC generate a digital output toggling at 500 Hz.    It will send this signal to P0[5] and I will invert this signal and send it to P0[7].  This will generate a SOC event every 1 ms.

• What is the input requirements for P3[1]?  I assume the P3[1] derives the results of outputs on P0[0] or  P3[7] through some formula.
• To use the full range of the SAR, the input has to be a sinusoidal signal with 4Vpp and a bias of 2V. This gives maximum use of the 8 bits and hence more accuracy in the algorithm written in C.

For simplicity sake, I'm going to use a WaveDAC8 and set it to generate a sine wave at 333Hz with 4V peak to peak and a 2V DC center bias.

• I saw the suggestion to use a register call in the datasheet of SAR, but I will test your suggestion.

The reason for using the Cypress-supplied API calls is because of standard practice of coding "abstraction".  It is always best to minimize direct calls to HW resources (ie. internal registers).  This is so that if your HW resource gets changed between different builds of your project, you don't have to go through a laborious debugging session to find ALL the instances of the 'old' reference to the HW resource to fix why the code is not working.

Using the Cypress API calls provides this abstraction because they are managing the intricacies of the HW abstraction layer (refer to the ISO specs about coding).  Additionally if Cypress finds a 'bug' or a better way to handle the HW resource, they can issue a new component version release that you can incorporate into your design.

• Are you sourcing an external reference voltage of 2.048V?
• Yes, I supply this externally.

For simplicity sake, I'm going to use a VDAC8 and set it for 2.048V and route it to P0[2].

If my above assumptions will have issues, let me know.

For the purposes of your issue, I'm avoiding using external resources to limit the hookup problems.

Len

• 4. Re: Undefined behaviour VDAC8

Len,

Your implementation sounds fine. The frequency of the SOC does not matter for the operation.

I have also been testing a little more. After implementing the API call, I did not encounter the changing output VDAC's P0[0] or P3[7]. I do not fully understand why.

If you could indeed verify that after a reset of the PSoC the output VDAC's P0[0] or P3[7] does not change, we can close this off.

With kind regards,

Jim

• 5. Re: Undefined behaviour VDAC8

sJim,

First off,  changing the direct register call to the GetResult8() call work just as well.  No improvements.  No degradation.

Here is a schematic of my changes.  Note: the ext_vref_2_048V at pin P0[3]  is routed externally to pin P0[2].

Here's a trace of the input stimuli at pins P1[5]  and P3[1].

Here is a trace of  outputs P0[0] and P3[1] in the first few seconds after reset.  I believe this is your intended outputs.

After about 1 to 3 seconds, these outputs get scaled to a lower gain (it appears to be a 1/2 with a bias about 2V).

I captured the transition between the full gain and lower gain.

A reset repeats this artifact after 1 to 3 seconds.

I have captured a similar artifact, but this time the gain is about 1/2 and the offset is about 0.5V.

I think you need to check of your math in the ISR.  There is a gain factor and offset factor apparently being corrupted.

Len

• 6. Re: Undefined behaviour VDAC8

Hi,

I provided some observed plots using your code.  Was my input useful?  Have you been able to solve your dilemma?

Len