Undefined behaviour VDAC8

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
user_58361
Level 2
Level 2

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:

NewFile0.png NewFile1.png

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

0 Likes
6 Replies
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Jim,

I've got some time right now to help.

I downloaded your project.   It can load on a CY8CKIT-059.   Superb choice!

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.

I recommend using the API call  ADC_SAR_1_GetResult8() instead of  a direct call to (ADC_SAR_1_SAR_WRK0_PTR)

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

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Hi Len,

Let me answer your question per point:

  • 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 recommend using the API call  ADC_SAR_1_GetResult8() instead of  a direct call to (ADC_SAR_1_SAR_WRK0_PTR)
    • 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

0 Likes

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 recommend using the API call  ADC_SAR_1_GetResult8() instead of a direct call to (ADC_SAR_1_SAR_WRK0_PTR)
    • 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

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

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.

Thank you in advance!

With kind regards,

Jim

0 Likes

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].

pastedImage_0.png

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

pastedImage_1.png

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.

pastedImage_2.png

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).

pastedImage_3.png

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

pastedImage_0.png

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.

pastedImage_1.png

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

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Hi,

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

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes