Oscillator troubles (was: Re: SID as a drum machine?)

[TK.]

Hi Kokoon,

thank you for the patches - there are really nice ones! :)

But to a more important topic:

one thing i noticed - the osc envelope gets retriggered randomly when using WT. is that a known error?

ARGH!!!

I also noticed this with your patches, and to say it short: it's not a software, but a design bug!

Fortunately it can be easily fixed.

To make it short: the SID is clocked asynchronously to the PIC. Depending on the clock phase between the SID and the PIC, a setup or hold violation can happen at the chip select line if the bus access is done at the "wrong moment" (rising edge on both clocks at the same time). It seems that this effect can only be noticed with the voice control register, which sets the waveform, sync, ringmod and the gate.

Statistically it happens very seldom, but if the voice control register is written with a very high frequency (e.g. 1.2kHz), it happens each 2..5 seconds (so after each 2500...6000th access) - and then it's really "noticable"

But fortunately there is cure: clocking the SID synchronous to the PIC. And this can be easily done by removing the oscillator, and by connecting the CLK pin of the SID (pin #6), with the 1MHz clock output of the CORE module (RC2, Pin #17, available at J7:SO - the middle pin)

Could you please try this? If you notice the same like me (no random gate triggers anymore), then you've uncovered one of the biggest bugs this year (even bigger than missing bypass caps ;-)

Here also an explanation why I haven't noticed this yet - I'm sure that I made some tests with asynchronous bus accesses years ago with the PIC16F877 based MIDIbox SID. A very easy check is just to write to the SID registers permanently - it worked. Now I did the same test with the PIC18F452, and it fails very often! (Test can be done by removing the "rgoto SID_SR_Next" instruction in sid_sr.inc). The main difference between both chips which could lead to such effects is 1) that the PIC18F452 is clocked 2 times faster, and that 2) the PIC18F452 works with an internal PLL, which delivers a more unstable frequency. Therefore the propability that the violation happens is much higher.

So, I hope that the proposed solution works in all cases. If not, the PIC clock could be delayed by a R-C pair. If this also doesn't help, then I'm in trouble ;-)

Best Regards, Thorsten.

[kokoon]

okay - i guess i'll have to read your post a few more times to understand what's going on :)

but i can probably find time to remove the crystals from SIDs and wire them to the core. i'll report ASAP.

[TK.]

fingers crossed!

Best Regards, Thorsten.

[illogik]

regardless of the outcome, i'm curious;

what is the advantage of using a different oscillator on the sid module; maybe we should just always use the core as clock, or no?

cheerss

[kokoon]

yay it's fixed now. i wired the clock from the core instead of the crystal. like you said.

problem solved  :D

[TK.]

Kokoon: these are great news! :)

Illogik: the intention behind the on-board oscillator was to have a backup solution for the case that pin RC2 of the PIC has to be used for something else. Another advantage is (or better was...), that the SID module could be accessed by other micros (or PCs) without the need for a clock generator (which is not easy to realize, especially with a PC)

So, the oscillator was never really required...

Today I made some experiments with SID bus transfer synchronization - since I'm not sure if the proposed solution works properly in all cases (e.g. independent from cable impedance and ambient temperatur), I've modified the SID bus driver in sid_sr.inc, so that it takes care for the falling clock edge, at which the data will be taken. Here a diagram (for people who are still interested...)

This old code in sid_sr.inc:

        ;; initiate a write and wait for 1.4 us (> one clock cycle)
        bcf     SID_SR_LAT_WR, SID_SR_PIN_WR
        movlw   0x03
        clrf    MIOS_PARAMETER3
SID_SR_WriteLoop3
        incf    MIOS_PARAMETER3, F
        IFNEQ   MIOS_PARAMETER3, ACCESS, rgoto SID_SR_WriteLoop3
        bsf     SID_SR_LAT_WR, SID_SR_PIN_WR
[/code]


has been replaced by:

[code]
        ;; synchronize with rising edge of SID clock to avoid setup or hold violation
        ;; note: due to pipeline effects, the "bcf" will be executed 3 instruction cycles after
        ;; the polling loop. Therefore we are waiting for the falling edge
        IFCLR   PORTC, 2, bra $-2               ; wait for falling clock edge
        IFSET   PORTC, 2, bra $-2
        bcf     SID_SR_LAT_WR, SID_SR_PIN_WR    ; enable write (MBHP_SID: chip select)
        bra     $+2                             ; to ensure compatibility with on-board oscillator,
        bra     $+2                             ; wait for 1.2 uS (> one SID clock cycle)
        bra     $+2
        bra     $+2
        bra     $+2
        bra     $+2
        bsf     SID_SR_LAT_WR, SID_SR_PIN_WR    ; disable write (MBHP_SID: chip select)

Now it looks perfectly at the scope! Now the practice test starts - if I don't notice failures anymore, I will publish the required changes (and the updated firmwares) at my website

Best Regards, Thorsten.

[mattias]

Is it best to clock the sid from core then? Or what???

[moebius]

Is it best to clock the sid from core then? Or what???

Yup,

in the current setup it's the only way to ensure PIC -> SID data transfers are in sync.

Bye, Moebius

[TK.]

Btw.: I will update the MBHP_SID page soon - references to the onboard-oscillator will be removed (especially in the schematic), interconnection diagrams will be changed, SmashTV will create a new PCB

But to say it clearly: there is no reason for throwing away an old PCB, if you already own one (or more) - just don't stuff the oscillator, and clock the SID from the core module instead like already described at the MBHP_SID page.

Best Regards, Thorsten.

[zenlogic]

Did this ever get resolved?

 

I've just discovered *exactly* the same phenomena - I was trying to get some SIDs working (driven from an Arduino as a teaching project). The code I used works perfectly with 6581 SIDs but the gate register has absolutely *no* effect on any 8580 I can lay my hands on...

 

 

Please help!!!

 

Mike

[TK.]

Yes, this has been resolved in November 2005 (so, almost 9 years ago) with exactly the solution that I described above.

 

Best Regards, Thorsten.

[ilmenator]

:rofl:

[zenlogic]

Yes, this has been resolved in November 2005 (so, almost 9 years ago) with exactly the solution that I described above.

 

Best Regards, Thorsten.

 

Hi Thorsten,

 

I only discovered electronics engineering fairly recently, and the MidiBox platform even more recently so it's not entirely surprising that this has been solved before!!!

 

Is the 8580 *that* sensitive to timing then in comparison to the 6581? 

 

Thanks,

 

Mike

[TK.]

Not really - but remote diagnosis is difficult without knowing your hardware setup + software.

 

The effect happened sporadically when a free-running (not synchronized) oscillator was used; conclusion:

a) the SID clock shall be generated by the microcontroller

b) each write access to a SID register shall be synchronized to the SID clock as described above to avoid timing violations.

 

If the effect always happens, it could also be related to your hardware setup.

E.g. defective SIDs, wrong voltage, wrong filter caps.

 

Best Regards, Thorsten.

[zenlogic]

Hi Thorsten,

 

hmm, this doesn't appear to be that issue - this isn't a sporadic or random failure, I have not managed to get a single 8580 to respond to a gate bit change. The same code works on the 6581s I have.

 

To be fair, my hardware setup is pretty rudimentary - I've built a (veroboard) circuit based on the schematic here: http://www.ucapps.de/mbhp/mbhp_sid_v3.pdf

 

The main difference is that I haven't used your controller - I've just got it hooked up to an Arduino which is delivering a 1Mhz clock off one of the pins, the 3 lines to the shift registers and one line to CS on the SID. I'll be honest, I'm an experimenter and a geek - I got into this because I found it interesting, not because I really know what I'm doing :-)

 

The code I've written works pretty well (on the 6581s) but absolutely fails on the 8580 because:

1) as soon as I write to any of the SID control registers setting a waveform, the SID plays the note even if the gate bit is set to 0.

2) setting or resetting bit 0 on the control register has absolutely *no* effect, the note does not stop and no envelope is triggered (because it's always playing).

 

There's another thread () where the guy seems to be describing *exactly* this issue - he's not talking about random gate triggering, he's saying that as soon as he sets a waveform on the 8580 it triggers the sound. This is what I am seeing.

 

Now, I have tested this with 3 6581 chips and 6 8580 chips and the behaviour is consistent - the gate works on the 6581s and not on the 8580s. I'm totally convinced it is my code, but I can't for the life of me work out why (which bugs the hell out of me).

 

I'm going to have to build a proper MIDIbox core and SID module just so I can see what the difference is with my tinkering I think!

[TK.]

It's interesting, that the other guy was using an Atmel chip as well, and had (or still has?) the same issue.

 

I would propose to check the shift register transfers.

Write a routine which allows you to set different data values at the shift register output, e.g. controlled via incoming CCs or MIDI Note events (so that you don't need to change your program while testing different values).

Check that you can control each individual bit of the address and data lines, and that there are no interdependencies.

 

E.g. if it turns out, that the gate flag (D0) doesn't work reliable, then you know that something might be wrong with the SPI transfer routine.

 

It wouldn't explain why this doesn't affect transfers to a 6581, but on such mysterious effects it's always a good idea to ensure the basic infrastructure first.

 

Best Regards, Thorsten.

[zenlogic]

I threw together a quick test board and tapped all the shift register output pins with LEDs (using a couple of darlington arrays so as not to interfere with the signal too much).

 

I haven't built any control circuitry yet, so just ran a program pushing 0-24 to the first shift register and 0-255 to the second on a slow timed loop so I can physically see the signals. All bit combinations appear to work as expected, so I think I can exclude that as the issue. The SPI code is doing it's job.

 

I'm not sure where to go next, but I'm going to order a PIC18F4685 so I can run your code - I'm thinking I'll have to check the timings with my scope and see if there's any clues there... (unless anyone has any better ideas???).

[zenlogic]

OMG!!!

 

I've solved it :-)

 

I was probing the board with my oscilloscope (started by focussing on the data, however this turned out to be wrong). I thought I'd look at timings vs the clock when I spotted that the clock pin (OC1A running a 1Mhz pulse set up using PWM) when turning on or off actually overshoots before settling back down to 5 or 0 volts.

 

This produces a (very, very) short peak on the rising and falling edge of the clock signal - I measured an almost imperceptible  peak to peak voltage of 8v...... I'd never have seen it without the scope.

 

Probably not the best approach, but I put a 1n capacitor to ground to filter out the first part of the signal, and BANG - the 8580 is now responding to gate changes and the envelope generator is working properly!!

 

I don't know if this is a known thing, but I suspect that this might be common to Atmel processors when delivering PWM at that sort of frequency? I"m guessing that the PWM coming from the PIC is much closer to a square wave and the edges don't overshoot 0 or 5 volts?

 

I should probably do something other than sticking a random cap to ground to fix the clock signal, but for now that will get me going!

 

Thanks for your help Thorsten, I just hope this info helps someone else out at some point.

[ilmenator]

Good find!

[TK.]

Well done!  :thumbsup:

 

I don't know if this is a known thing, but I suspect that this might be common to Atmel processors when delivering PWM at that sort of frequency? I"m guessing that the PWM coming from the PIC is much closer to a square wave and the edges don't overshoot 0 or 5 volts?

 

It seems that the Atmel microcontroller has much "stronger" pad drivers compared to the PIC which can lead to such EMC issues.

 

This might also explain why the 6581 was working: it's produced in a different technology which consumes more power. Probably the input resistance of the clock input is lower, and this causes the same effect like the cap that you've added.

 

The proper solution would be (if my assumption is correct) to add a resistor in serial, e.g. 100 Ohm should be fine.

It will limit the current drawn during signal transitions so that the nominal voltage isn't exceeded.

 

Using a cap is also possible, but not the best choice, because it will cause higher current drawn during transitions (no dramatic drawn, not really noticeable, but if you ask for the preferred solution, take the resistor)

 

Best Regards, Thorsten.

[zenlogic]

Hi Thorsten,

 

a serial current limiting resistor didn't work - I tried a few values up to 1k to no effect.

 

If you look at the two screenshots below you will see the waveform before and after I added the capacitor. Can anyone think of a better way to *fix* the output to make a more pure square wave than sticking a cap to ground? I mean, the solution works but it just feels a bit wrong...

 

Before:

 

 

 

After:

 

[TK.]

Interesting!

 

Where did you probe the signal, at the PWM output of the microcontroller, or at the CLK input of the SID?

 

However, since the resistor doesn't help, using a cap against ground seems to be the right way to solve the issue.

 

Best Regards, Thorsten.

[zenlogic]

The oscilloscope screens above were taken straight off the PWM pin - when I took those I'd actually completely disconnected everything from the arduino board so that would basically seem to be an issue internal to the Atmel controller, none of my circuit was involved in that test!

 

It's quite amazing that you seem to be able to get over 9V peak to peak out of it though!

Edited June 19, 2014 by zenlogic

[TK.]

I can generate similar peaks with the PIC when I take a long cable (> 5 m) ;)
 

 
How long are your cables to the CLK and Ground pins?
 
Best Regards, Thorsten.

[zenlogic]

Just the oscilloscope probes - straight onto the pins!

 

10.9V!!!! woah!

Edited June 19, 2014 by zenlogic