Hey, #Electronics folks!
Has anyone seen such an output for a ramp coming out of a DAC?
This is produced by a simple counter counting from 0 to 4095 and then wrapping.
The sharp dips are absolutely stable and deterministic. They occur at bit switches but I don't seem to get my head around why.
Identical curves on two different DAC peripherals on the same μC and even across different chips/boards (I'm almost certain it's a software problem).
@Pat @cstanhope @Segebodo @timjan @alinanorakari
Addendum:
Manufacturers make you jump through hoops ... by faulty silkscreen:
* PB4 marked as PA4
* PB5 (ADC) marked as PA5 (DAC)
Coz' it's not a biggie to mix up input and output </irony>
@Pat @cstanhope @Segebodo @timjan @alinanorakari
So, never trust the silkscreen, I guess...
@cweickhmann
Based on the dips and the different steepnesses I'm guessing there's maybe some swapped bit things going on?
I guess you could check this by running the following series (binary numbers):
...0001
...0010
...0100
...1000
If bits are swapped the peaks won't be entirely sorted by size.
@Segebodo
I'll check. Thanks!
@cweickhmann A little disclaimer: I have almost no experience with digital electronics.
@Segebodo
No worries. I was bug tracking for hours and ran out of ideas. So mainly trying to get some independent thoughts here.
To me it looks very much like a purely digital problem.
@cweickhmann You could also export the image from the oscilloscope and overlay a straight line onto the ramp. This could make it easier to detect more caracteristics of the problem.
@cweickhmann I just saw this and honestly I don't know if this will really help you with debugging:
https://chaos.social/@blinry/108296285154361215
@cweickhmann Is this a DAC with a parallel interface or serial?
@cstanhope
Do you mean bus-wise or analog front end?
It's a ATSAME51J20A and sort of vague on either of that. It is on-chip though, it supports DMA, I'd assume it's serial.
Front-end side there's nothing in the datasheet. At 12 bit it's certainly something more elaborate than a simple resistor ladder, but not clear what.
@cweickhmann Okay, I was thinking it was its own device. My first thought is that maybe bits are somehow being swizzled. A parallel interface wired up wrong could easily do that. But I suppose it's possible to also get a serial interface wrong too, with either bit order or word order etc. But since it's on device, it's has to be something else. Somehow driving it incorrectly or having it in the wrong mode or something.
@cweickhmann That's a very fancy DAC on there. It has dithering modes and other kinds of things.
@cweickhmann I can't quite tell looking at your scope picture and based on my ignorance of your setup, so I'm going to ask a very obvious question, which I'm sure you've already thought about so I do not mean any offense by it. You've ruled out aliasing on the scope display? In other words, you've got the right time base for what it is you're looking at?
🇳🇱
@cweickhmann How sure are you its a software issue?
These types of behaviors used to be possible a long while back, as DACs (and ADCs) where not necessarily guaranteeing that each bit increment was larger than previous value. HOWEVER, this large I have never seen.
This looks more like incorrect bits being sent to the DAC. Common issues are; shifting wrong number of bits, bits in wrong position, little/big endians, polarity, bit shifting out of phase, ...
Which DAC is it? (Maybe you solved it by now...)
@cweickhmann The DAC is built in in the uC? What's the uC, and what's the specs on the DAC? By the look of it, you have a fairly badly non-monotonic DAC:
https://www.planetanalog.com/dac-non-linearity-non-monotonicity-and-midpoint-glitches/
https://www.planetanalog.com/dac-basics-part-3-static-specifications/
@timjan
Yeah, it is and the docs are... meagre.
I was thinking nonmonotonous already, but this iss off the charts.
@cweickhmann just a wild guess as I'm a software person but it looks to me as if the problem could be in hardware (every bit results in a bit higher voltage than it should). Quick example: 0001 should be 0.1V, 0010 should be 0.2V and 0100 should be 0.4V so 0011 would correctly sum to 0.3V – but if the voltages are a offset by +0.15V each it could mean 0001 is 0.25V, 0010 is 0.35V and 0100 is 0.55V so 0011 would then wrongly sum to 0.6V which is higher than 0100's wrong 0.55V
@cweickhmann you as an electronics person could probably figure out where a higher voltage might come from … wrong voltage supplied to the chip? IDK I'm out of my depths there
Looks like a digital issue, but to rule out analog issues try inserting SW delays in the loop to really slow it down and varying the speed. Also, check the load on the ouput to make sure it's not pulling too much current (you can also vary the load to see if that effects the shape). It's running pretty slow already so it's probably not a capacitance/inductance issue and if there are no changes in the shape when you vary those things then that would rule that out.
On the digital side, that chip has a 2000-page data sheet and I'm not familiar with it, but a quick glance shows that it has two DACs that can be used together in differential mode, so make sure you set it up to use only one of them.
And make sure you're using it in 12-bit mode, not 16-bit mode, to eliminate that as a cause.
Also make sure your VREFA is a well conditioned DC without spikes or dips.
Also, it can use interrupts, so make sure it isn't periodically interrupting.
And of course as others have mentioned make sure the scope sample rate is quick enough (probably not the issue).
@Pat
On the analogue side, I varied the base frequency of the sawtooth and even double-wrote the DAC values in SW to make sure it's not some memory glitch.
Timing (i did not mention that, sorry) is IRQ driven. No other IRQs interfere, that's made sure.
Current-wise, the output is loaded with the oscilloscope directly, which I thought may cause capacitance issues or not allow a high enough current. I've got to verify that. Thanks for that hint!
The DAC is in single-ended mode, actually the two curves are the two DAC channels each in SE. I wonder if that problem would just cancel out in diff-mode. But, wow, that would be useless hardware nevertheless 😅
It's in 12bit mode, dithering and oversampling are explicitly deactivated. And I'm using the internal bandgap VRef. Using a rather unstable external voltage (from USB) as ext. VREF causes fancy psycodelic warping of the curve, but the pattern stays intact.
Scope is >100 MS/s, the signal is ~100kHz.
Thanks again for the brainstorming. I know it's fishing in murky waters, but I just needed input.
I'll check the load and see if that helps.
I still suspect the framework to do something weird in software. My hopes were that maybe someone struggled with a similar chip already and would tell me: Look, there's that one setting/bug and that solved it. So I hope I can be that one in the future 😉
@cweickhmann I'm glad you found it! That must be a relief. And thanks for reporting back. I've been wondering if you'd been able to track down the problem.
@cweickhmann thank you for this short post-mortem. I hope to one day have the tools and skills to debug my own circuits in a similar way. Cheap oscilloscope and logic analyzer have been on my buy list for some time, and soon I'll have a dedicated space where I can leave my hobby projects and the associated tools and devices
So, first of all, thanks for the input, @Pat, @cstanhope, @Segebodo, @timjan, @alinanorakari !
It turns out it was sort of digital but mostly clock related. For some reason, the GCLK Generator 1 was set to 120 MHz (div 1) while in other examples it was set to a lower value of 12 MHz, i.e. higher div (10 for example). Well: now the sawtooth is smooth as a baby's butt.
The thing is: I only found this by going through a dozen graphical representations of the configurations - which were buggy. Not sure why it was GCLK1, by the way. The datasheet says GCLK_DAC must be lower than 12 MHz casually under 47.6.3 Operating conditions ^^ (I set it to 20 MHz (div 6) and it still worked though).
So, at least my hunch was right: This was indeed not a nonmonotonous DAC (because, wow, that would've been awful!).
My second hunch was right too: There's way more experience to gather.
**Lessons learned:**
1. Always make sure your clock settings are okay.
1. Get used to looking for crucial info on speed and timing under sub-paragraph 6.3+ 😵
1. If you can, chose a product with a clean, functional and stable IDE+toolchain (or use your own).