PSoC 5LP hardware issue

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

cross mob
MoPr_4537651
Level 4
Level 4
50 replies posted 25 replies posted 10 replies posted

Hello,

I recently built a custom PCB with the PSoC 5LP chip with an onboard SD card module and an external 1.25V LDO for the SAR and del-sig ADC reference. Everything is working fine except for one subtle issue which I am consistently seeing.

pastedImage_3.png

Whenever PSoC writes to the SD card I see tiny spikes in voltage. The spike is about 0.5mV. Since the signal I am looking at is so subtle, the spikes are prominently visible. I thought giving an external stable reference voltage to the ADC will fix the issue. But it didn't. I even isolated the ground plane of the SD card on the PCB.Still did not help to get rid of that spike. What could be causing this issue and how to fix it? 

0 Likes
1 Solution

MoPr,

I have done exactly what you told. I played around with the buffer sizes to see if the position of the spikes matches the number of samples stored before writing. It matched that everytime. I tried 250, 500, 750, 1000 samples and the spikes occured at 250, 500, 750, 1000 samples. I even disabled the SD card writes to see if the voltage spikes disappeared and it did.

You're doing excellent work in highlighting the source of the spikes.  A simple SW change in the SD dump trigger has determined the source beyond any reasonable doubt.  You were correct in your first assumption.

... I am not quantitatively sure how it affects the rise time. Is there a way to calculate rise time when only a series resistance is used? Addition of capacitance to ground will require a new iteration. I will include it in the next iteration.

There is a quick rule for the rise time. 

  • Multiply the total series R times the total parallel C.  This is the 'tau' of the exponential rise curve.  One 'tau' time factor will have the signal go from 0V to 62% of VDD (5V in this case).
  • Now multiply the 'tau' time value by 2.  This is the 90% point in the rise time.  Rise time is 'roughly' measured from 10% to 90% of 0V to VDD.

Could it be a termination issue? The PCB tracks are not impedance controlled and I don't have termination resistors.

Signal termination is more of an issue when the wiring is longer (excess inductance 'L').  Excess 'L' can cause signal overshoots which can be a problem for the signals that are clocks.

Since you are using the 74LVC125A, if you were to place any additional R or C on the signal it would be on the signal output from the 74LVC125A.

Before you add any more Rs or Cs in the signal path, I may have another solution.

The spikes show up when you are simultaneously performing a read with the delta-Sigma ADC AND a SD write using the SPI comm.  Solution: Avoid performing an ADC measurement when writing to the SD. Simple to say.  Maybe harder to do.

Can you coordinate each ADC conversion to cause a 'pocket'  of time where the dump of data to the SD can be accomplished between conversions?

The delta-Sigma ADC usually takes longer for a conversion.  The SAR ADC can convert faster.  Using the SAR ADC will create a bigger 'pocket' of time for the SD write.

If you need higher resolution, the delta-Sigma may be necessary.

When performing the SD write, faster is better (less need for a large 'pocket').  Therefore reduce the R and C of the signal path circuits and try to clock the SPI data at the faster rates tolerable.  Using a scope, check the signal quality on both sides of the level translator to make sure there is no significant overshoot (or undershoot) to the signal.

I am also using a line driver 74LVC125A (https://assets.nexperia.com/documents/data-sheet/74LVC125A.pdf) between the PSoC and the SD card. This draws 100mA current. Could this be an issue as well?

I really doubt if you're drawing 100mA from this level translator.  It's probably more like 50uA tops.

Len

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

View solution in original post

0 Likes
9 Replies
EvPa_264126
Level 7
Level 7
500 replies posted 250 replies posted 100 likes received

on the X-axis - ADC counts?

Something fires every 500 samples.

It looks like current surges.

it seems SD noise looks different.
Can you provide a stripped-down project where this problem is visible?

0 Likes

Hi evgeniy,

X-axis is ADC sample count.

It is the SD card write which gets triggered every 500 samples. I am using a ping pong buffer to write to the sd card. The size of the buffer is 500 samples.

This problem appears whenever SD card write happens. It looks to me like whenever the PSoC writes to the SD card there is a big current draw which causes the spike in voltage I am consistently seeing.

0 Likes
odissey1
Level 9
Level 9
First comment on KBA 1000 replies posted 750 replies posted

MoPr,

I suggest to switch to the ADC internal reference for a test. If the spikes disappear, it would be indication of noise pickup on the external voltage reference path.

/odissey1

0 Likes

Hi BoTa,

I was initially operating using the internal reference voltage itself. These spikes were even more significant. Hence I added a stable LDO externally for the reference voltage.

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

MoPr,

How have you determined that the spikes are due to the SD card writes?

Design of Experiment (DoE):  Disable all SD writes (stub the SD write function to do nothing).  If you can, use the USBFS_UART port to push the ADC data to a terminal.  See if the spikes in the data are still present.

If you're interested, I placed a C# program for a PC terminal program up in the Code Sharing forum.   PC Terminal Program with C# Source Code

This code includes a means to plot data to a separate window on the PC if you use my packetizing protocol.

Another serial plotting program can be found at: SerialPlot: interface to real-time data charts

If spikes happen to be because of the SPI comm to the SD card, you might want add some series resistance in the SPI_CLK and SPI_MOSI and SPI_MISO lines.   It might also be beneficial to add a minor amount of parallel capacitance to these lines.

By adding the series resistance and the parallel capacitance to GND, this will reduce the rise and fall slew rates of the signals.  Reducing the slew rates will lower current surging on the SPI lines which might be cross-coupled to the ADC front-end or the ADC itself.

The rule-of-thumb I always target when I want to limit the slew rates of digital signals is that I increase the R and C values (tau of the low-pass filter) so that the rise + fall times to be no more than 10% total of the signal's minimum period.  Ie.  If the signal of SPI_CLK is 100KHz (period = 10us) then the rise+fall times should be no more than 1us.

If you've prove conclusively that the SPI comm to the SD card is the probably because the spikes are at the same rate as the SD write (500 samples), then write every 1000 samples.  The spikes should occur 1/2 times as often.   If this is the case, use the above slew rate control and lower the SPI clock rate.   Writing as slow as you can tolerate with the slowest slew rate you can tolerate will reduce the dv/dt and di/dt of the circuit lowering the possibility of effecting the the ADC measurement.

Len

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

Hi LePo,

I have done exactly what you told. I played around with the buffer sizes to see if the position of the spikes matches the number of samples stored before writing. It matched that everytime. I tried 250, 500, 750, 1000 samples and the spikes occured at 250, 500, 750, 1000 samples. I even disabled the SD card writes to see if the voltage spikes disappeared and it did.

Right now, on the PCB I have 3.3k series resistance on the MISO, MOSI, SCK and CS lines. This should limit the current to about 1.5mA. I am not quantitatively sure how it affects the rise time. Is there a way to calculate rise time when only a series resistance is used? Addition of capacitance to ground will require a new iteration. I will include it in the next iteration.

Could it be a termination issue? The PCB tracks are not impedance controlled and I don't have termination resistors.

I am also using a line driver 74LVC125A (https://assets.nexperia.com/documents/data-sheet/74LVC125A.pdf​) between the PSoC and the SD card. This draws 100mA current. Could this be an issue as well?

0 Likes

MoPr,

I have done exactly what you told. I played around with the buffer sizes to see if the position of the spikes matches the number of samples stored before writing. It matched that everytime. I tried 250, 500, 750, 1000 samples and the spikes occured at 250, 500, 750, 1000 samples. I even disabled the SD card writes to see if the voltage spikes disappeared and it did.

You're doing excellent work in highlighting the source of the spikes.  A simple SW change in the SD dump trigger has determined the source beyond any reasonable doubt.  You were correct in your first assumption.

... I am not quantitatively sure how it affects the rise time. Is there a way to calculate rise time when only a series resistance is used? Addition of capacitance to ground will require a new iteration. I will include it in the next iteration.

There is a quick rule for the rise time. 

  • Multiply the total series R times the total parallel C.  This is the 'tau' of the exponential rise curve.  One 'tau' time factor will have the signal go from 0V to 62% of VDD (5V in this case).
  • Now multiply the 'tau' time value by 2.  This is the 90% point in the rise time.  Rise time is 'roughly' measured from 10% to 90% of 0V to VDD.

Could it be a termination issue? The PCB tracks are not impedance controlled and I don't have termination resistors.

Signal termination is more of an issue when the wiring is longer (excess inductance 'L').  Excess 'L' can cause signal overshoots which can be a problem for the signals that are clocks.

Since you are using the 74LVC125A, if you were to place any additional R or C on the signal it would be on the signal output from the 74LVC125A.

Before you add any more Rs or Cs in the signal path, I may have another solution.

The spikes show up when you are simultaneously performing a read with the delta-Sigma ADC AND a SD write using the SPI comm.  Solution: Avoid performing an ADC measurement when writing to the SD. Simple to say.  Maybe harder to do.

Can you coordinate each ADC conversion to cause a 'pocket'  of time where the dump of data to the SD can be accomplished between conversions?

The delta-Sigma ADC usually takes longer for a conversion.  The SAR ADC can convert faster.  Using the SAR ADC will create a bigger 'pocket' of time for the SD write.

If you need higher resolution, the delta-Sigma may be necessary.

When performing the SD write, faster is better (less need for a large 'pocket').  Therefore reduce the R and C of the signal path circuits and try to clock the SPI data at the faster rates tolerable.  Using a scope, check the signal quality on both sides of the level translator to make sure there is no significant overshoot (or undershoot) to the signal.

I am also using a line driver 74LVC125A (https://assets.nexperia.com/documents/data-sheet/74LVC125A.pdf) between the PSoC and the SD card. This draws 100mA current. Could this be an issue as well?

I really doubt if you're drawing 100mA from this level translator.  It's probably more like 50uA tops.

Len

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

Hi LePo

LePo_1062026 wrote:

MoPr,

I have done exactly what you told. I played around with the buffer sizes to see if the position of the spikes matches the number of samples stored before writing. It matched that everytime. I tried 250, 500, 750, 1000 samples and the spikes occured at 250, 500, 750, 1000 samples. I even disabled the SD card writes to see if the voltage spikes disappeared and it did.

You're doing excellent work in highlighting the source of the spikes.  A simple SW change in the SD dump trigger has determined the source beyond any reasonable doubt.  You were correct in your first assumption.

Thanks

... I am not quantitatively sure how it affects the rise time. Is there a way to calculate rise time when only a series resistance is used? Addition of capacitance to ground will require a new iteration. I will include it in the next iteration.

There is a quick rule for the rise time. 

  • Multiply the total series R times the total parallel C.  This is the 'tau' of the exponential rise curve.  One 'tau' time factor will have the signal go from 0V to 62% of VDD (5V in this case).
  • Now multiply the 'tau' time value by 2.  This is the 90% point in the rise time.  Rise time is 'roughly' measured from 10% to 90% of 0V to VDD.

This is pretty neat! Thank you, I will use this to calculate the required values.

Could it be a termination issue? The PCB tracks are not impedance controlled and I don't have termination resistors.

Signal termination is more of an issue when the wiring is longer (excess inductance 'L').  Excess 'L' can cause signal overshoots which can be a problem for the signals that are clocks.

Ohh ok cool.

Since you are using the 74LVC125A, if you were to place any additional R or C on the signal it would be on the signal output from the 74LVC125A.

True.

Before you add any more Rs or Cs in the signal path, I may have another solution.

The spikes show up when you are simultaneously performing a read with the delta-Sigma ADC AND a SD write using the SPI comm.  Solution: Avoid performing an ADC measurement when writing to the SD. Simple to say.  Maybe harder to do.

This is a nice idea. Will check this out. Thanks

Can you coordinate each ADC conversion to cause a 'pocket'  of time where the dump of data to the SD can be accomplished between conversions?

The delta-Sigma ADC usually takes longer for a conversion.  The SAR ADC can convert faster.  Using the SAR ADC will create a bigger 'pocket' of time for the SD write.

If you need higher resolution, the delta-Sigma may be necessary.

Yeah. Currently I am using all 3 onboard ADCs. I have a ping pong buffer for each of them.

When performing the SD write, faster is better (less need for a large 'pocket').  Therefore reduce the R and C of the signal path circuits and try to clock the SPI data at the faster rates tolerable.  Using a scope, check the signal quality on both sides of the level translator to make sure there is no significant overshoot (or undershoot) to the signal.

Will do this.

I am also using a line driver 74LVC125A (https://assets.nexperia.com/documents/data-sheet/74LVC125A.pdf) between the PSoC and the SD card. This draws 100mA current. Could this be an issue as well?

I really doubt if you're drawing 100mA from this level translator.  It's probably more like 50uA tops.

True. I got confused with the absolute maximum ratings.

Len

Thanks a lot for your help. Will try your suggestions.

0 Likes

MoPr,

did you find a solution?

/odissey1

0 Likes