This year's x-mas gift from Mikroelektronika: A compiler bug

I have spent the last month chasing down an extremely strange bug. When I added a new global variable to my DCO, calibration stopped working.

I first spent a long time trying to figure out what was going on, and after a couple of weeks I ended up posting a rather vague description to the MikroC forums. 

What I was seeing was very weird - I had a double loop, and the inner loop ran fine the first time around but the second time the inner loop ran it skipped the first part. The outer loop was never re-executed but sometimes the program continued in the mail function afterwards.

I did a lot of testing but the results were always similar, some code was skipped and sometimes everything crashed. It felt like the program pointer moved to a different address. I started suspecting some kind of memory leak.

After the post in the forums I was asked to provide a minimal example - I normally do this anyway but this time I had a hard time doing so, as everytime I changed the program it started working.

Finally, I resorted to placing all variables and functions at absolute positions, as I suspected that some kind of memory collision was the problem. It took a looong time to get this right, and it wasn't always possible, but at last I managed to get a fully absolute-position program that still bugged in a similar way.

Now I gradually stipped the program down, re-running the code for every small change to make sure it still had the bug and that it could be brought back to working by moving something. I placed empty variables at absolute positions to prevent other, used variables from moving around, and also made sure that the empty spacers were not called upon anywhere in the code that was executed BEFORE the spot where the bug showed up.

This took me every spare moment from the 17th of December and the 13 days. Finally, yesterday, I had a minimal program with only a single function call inside the loop. Removing a single spacer variable made a single library variable (FLASH_write.savedINTCON) move too, and the program would start working. 

I was totally exhaused and posted a new question to the forums.

As I waited for answers, I used a diff tool to see if the two generated asm outputs from the working and non-working programs were different. They were not. I then did the same for the machine code listing file (.lst). Now I could see a single changed line! In the non-working version, a single instruction - MOVLB 0 - was missing. I took a screenshot and prepared to write a follow-up question.

When I logged in to the forum again, the user Janni had just posted an answer - and that was the exact same thing that I found. Janni confirmed that this was actually the error, the instruction changes RAM banks and when it is missing the function returns to the wrong part of the program, exactly what I was seeing.

Adding 'asm movlb 0;' after the call to FLASH_write fixes everything.

So here we are - it turned out to be a compiler bug after all. I am completely drained but incredibly happy that the error was found as I can't have any errors in the DCO.

Unfortunately, it seems Mikroelektronika stopped developing the MikroC compiler in 2019 so it is unlikely that the bug will ever be fixed. At least now I know what to look for if this ever happens again!

Happy new year everybody!

MikroC: Absolute positioning

I've spent the last weeks debugging a strange problem in MikroC, and to do that I had to absolute position every function and variable to make sure the program did not change in RAM and ROM.

Here is how to do that:

Global and local variables

Add absolute 0xXXXX to place at address 0xXXXX. If you have an initialiser it must be placed BEFORE the absolute. E.g.:

    unsigned short a absolute 0x0123;

    unsigned short a = 1 absolute 0x0123;

    unsigned short a[32] absolute 0x0123;

Variables need to be used somewhere to prevent the compiler from removing them. Also, the compiled code is different if the assignment is done on a separate line vs if it is done inline, which changes the size of functions.

For global variables they may be used in main simply by assigning to them. For arrays it's enough to assign something to the first position. E.g.:

    a = 1;

    a[0] = 1;

Function parameters

I have not been able to place these at absolute addresses

Internal library variables and function parameters

I have not been able to place these at absolute addresses

Functions

These are postfixed with org 0xXXXX:

    void myFunc() org 0x0123 { ... }

You may also put the address after an extern declaration in an h file:

    extern void myFunc() org 0x0123;

Library functions

These may also be positioned, just skip the function body:

    void libraryFunction() org 0x0123;

Collisions

Variable collisions are common, in cases where the compiler has decided that they won't conflict. In those cases, it is not possible to absolute only one of the colliding variables, as the compiler won't place anything else on an address occupied by an absolute'd variable.

That means that you have to set all variables to absolute for that particular address - and if one of them is a function parameter you're out of luck it seems as those cannot be absolutely placed (or at least I don't know how)

Wavemixing and loudness

When designing the continuous wavemixer, I thought a bit about the fact that as you turn the dial, the (perceived) loudness of the output changes. As the number of harmonics in the signal changes, from none with the sine wave, to “all” in the square wave, the output sounds progressively louder even if the signal amplitude is the same.

This is most pronounced when going from sine to saw, but triangle to saw also has a noticeable difference, so I’ve contemplated changing the input mix to compensate for this. As the cross fade is computer controlled, I could also compensate in the source mix vca, which is good since it can be done after the hardware has been made.

When studying “off the shelf” VCO chips with built-in waveshapers, I noticed that the different wave outputs indeed have different amplitudes. I have not been sure if this is just a byproduct of how the waves are generated in hardware, or actually a design feature.

Today I read the data sheet for the AS3394 (a CEM3394 clone) because I was curious about building a simpler synth voice, and noticed that it has a built in waveform mixer/selector. And in the text, it is clearly stated that the waveforms have different amplitudes to keep the loudness the same. Saw is 27% larger than triangle, and square is 27% larger than square. 

Unfortunately, I cannot see the same numbers in the waveform plots on page 4, but it shows that triangle output is 50mV, saw is 45mV and square is 30mV. Now, 27% larger than 30 is 38, and 27% larger than 38 is 48.4, so we are very close to the real value for square, but saw does not make sense. However, the saw output on pin 9 is stated as 45mV as well, so this could just be a copy/paste error. The 27% text is lifted straight from the CEM data sheet which does not have a similar plot so it’s hard to tell if the original text is wrong or if the plot is wrong without measuring. I have bought an AS3394 so maybe I’ll get around to checking it sometime.

CEM3340

Tri: 0-5v

Saw: 0-10v

Square: 0-12v

Meaning square is 20% larger than saw, but saw is 100 larger than tri. Also, they are not centred, meaning they should be centred using a capacitor (or with separate centring circuitry - caps mess with pulses, they won’t be centred around 0. Not uncommon in real designs though, and something that will happen in the filter anyways, one just need to take it into account when mixing several sources to prevent clipping).

SSI2130

All outputs are 0-2.5V, though pulse goes slightly below 0 (-34mV)

For more on the waves, see:

Tri:

https://en.m.wikipedia.org/wiki/Triangle_wave

Saw:

https://en.m.wikipedia.org/wiki/Sawtooth_wave

Square:

wikipedia.orghttps://en.m.wikipedia.org › wikiSquare wave - Wikipedia

XM8 as a vocoder

I have thought about the posibility of using the XM8 as a vocoder for a long time, but had decided to not go ahead with it due to the added complexity.

However, while designing the voice cards I realised that by just adding tiny modifications, I could at least leave the door open to adding a vocoder daughterboard later. Let me explain.

Vocoder architecture

A vocoder has some central components. First of all, it takes two inputs:

 - one (usually a voice) that is analysed for frequency content by dividing the input into frequency bands using bandpass filters. The amplitude of each band is captured using an envelope follower.

- another one (usually an instrument sound rich in harmonics) which is divided into the same frequency bands as the first one, and where the amplitude is controlled by the amplitude of the first input.

The effect is that the second input "mimics" the first, making the instrument "talk".

In addition to the inputs, a noise source is used, and amplitude is sampled (analog sample and hold) at intervals set by a variable clock.

Here is the block schematics of the classic ETI Vocoder DIY kit:

It has three main parts - analysis and synthesis at the top, and sound generation at the bottom. The two oscillators are used in place of the second input.

How to implement this in the XM8

Now, we would need to implement the whole analysis, sample and hold and voiced/unvoiced detection on the daughterboard. The output from the board would be 16 CVs that can control VCAs. 

The second input will be either 

- External audio - if we want to use a different source for our "instrument"

- Output from the low pass filter on voice card 1 - that way we can use everything on the voice card except the state variable filter as a mono synth. 

We would then feed the second input as External input to all voice cards. By sending the input directly to the SVF - this is already part of the architecture - we can use the SVF in place of the second block of band pass filters in the schema above. The cutoff frequency for each filter is fixed and can be calibrated (part of the existing design) digitally. As an added bonus, the cutoff frequency may be moved to change the voice pitch (or even invert or reorder the bands).

There are two additional important things in the ETI vocoder design:

 - the first and last frequency bands are made using low pass and high pass filtering respectively. Fortunately, this is supported by the SVF.

- every second band is phase inverted. This is also supported by our architecture.

Changes needed to the voice cards

- Add a CV input going to the SVF. 

- Add an output from the low pass filter (pre VCA), this will be used on the first voice card to use as the second input.

Changes needed to the main/input board

- Add a switch between external input and voice card 1 LPF output (this is a good idea anyway)

- Add a switch between this input and a third input used for vocoder noise source. This would be controlled by the voiced/unvoiced detector on the vocoder analysis board.

- CV outputs going to the vocoder board to control voice input volume etc.

- Chaining between synths - either we need a separate analysis board on synth two or we need 8 VCA inputs. We need a separate Ext audio out, tapped after ext audio mux, to send voice card 1/noise to second synth.

A four channel mux may be used, if we let the vocoder analysis board control A1 and input noise to input 3 and 4, the mainboard may control A0 to switch between external input and voice card 1 LPF. A1 would then effectively override the two inputs (and should have a pulldown resistor so that it is disabled if no vocoder daughterboard is fitted.

Usage: LPF filter VCA must be turned down on all voices, and Ext in turned up and connected to SVF for all. Voice card 1 may be used as input to the other sources.

As one XM8 probably ends up having only 8 voices, we need to chain two to get a full 16 band vocoder. Here is one way of doing that:

We need to have a single analysis board to be able to detect voiced/unvoiced properly. Bus chaining requires level matching between the synths, so ext bus input should probably have VCAs.

Things to test

I am unsure of the steepness of the bandpass in the ETI vocoder. The SVF has a 12dB bandpass.

Update: According to the Deliyannis bpf docs, one filter has 12dB cutoff, so two must have 24dB. That means that we may have to run the audio through both the LPF and the SVF (as HPF).

Deliyannis band pass filter

While reading about the human voice filter bank in the VP-330 (on the Oakleysound site) i realised that the ETI bandpass filter is called a Deliyannis bandpass filter or resonator, a calculator can be found here: 

https://www.changpuak.ch/electronics/Deliyannis_Bandpass.php

http://earmark.net/gesr/opamp/bpf.htm

Teensy 4.0 bottom pins - finding a suitable header and connector

If I'm to use the Teensy 4.0 as my voice controller MCU, I need to use the 10 additional pins on the back to get to the second SPI.

This means I either have to solder pins to the 10 pads, or use a breakout board with castellated connections like https://forum.pjrc.com/threads/57672-Another-Teensy-4-0-Breakout-Board?highlight=Teensy+4.0+rear+pins

If I am to solder pins, I need to make sure that I can find a matching mating connector. As the SMD pin header is higher, the mating connector needs to be lower. Also, the pins need to be short enough to fit the connector.

I measured the pre-soldered pins on the Teensy, the bottom plastic is 2.54mm high, the pin is 5mm.

Normally, mating connectors for the single rows are 8.5mm high, with some saying that the pins may be 6.6mm long.

I am going to try out the following:

Pins (from Farnell):

Samtec TSM-105-04-L-DV

These have a 0.15" (3.81mm) height before the pins, or 1.27mm more than the ones on the Teensy. The pins are 3.05mm, which is a bit on the short side.

Update: Samtec TSM-105-01-F-DV has a pin height of 5.84 which may be more suitable.

GCT BG050-10A-0-0450-0737-0350-L-D

These have a height of 3.5mm before the pins, but the pins are 4.5mm. That looks very promising. Unfortunately, ordering these in Norway incurs a $13 fee because they are only in stock in the US.

F = 3.5mm, D=4.5mm

Female connectors (from Farnell):

Amphenol 76342-305LF

This is a 7mm high receptacle. combined with the GCT connector it would give a total height of 10.5mm, as opposed to the 11.04mm of the side connectors, leaving a 0.5mm gap. This is probably fine. Combined with the Samtec one the gap is reduced to 0.2mm, but the short pins (3mm) may not be long enough. The max pin length is not stated but from the "normal" connector we can guess around 4.9mm.

AMP 215307-5

Similarly, a 7mm high receptacle. Max pin length is not stated for this one either, but it says that the connection point is 2.2mm into the connector which is a tad too long for the 3mm Samtec pins.

From JLCPCB:

I managed to find a couple of 7mm headers from JLCPCB as well:

Liansheng FH-00097

UPDATE: This is a 20p part and won't fit

part C2829902, though only 8 are in stock right now:

Wcon 2171-210SG0CUNT3

UPDATE: This is a 20p part and won't fit

part C721788 - unfortunately, the mating position is  3.57mm down which again may be too far for the pins.

I will order the Farnell ones shortly to test.

Update:  Results from Farnell

14 pin socket:

Part 1593466 / 2212-14SG-85 

May pull pins 0.8mm out and still have good contact. Tested using pins that protude about 5.66mm and has 2.54mm plastic at the bottom

When pressed together, pins and header measure 10.87mm. Header is 8.42.

10 way SMD

Pins: 3551099 / Samtec TSM-105-01-F-DV (NB: F, not L). Plastic + bent pins measure 3.86mm. The pins measure 5.68mm so the total height is 9.66mm

Header: 1098050 / Amphenol 76342-305LF. Measures 6.97mm. Pins may be pulled out at least 1mm and still have good fit. Height with pins is 10.85mm

Header: 3419216 / AMP 215307-5. Measures 6.96mm. Pins may be pulled out at least 2mm and still have good fit. Height with pins is 10.84mm. Has a very nice, tight fit

Conclusion: The combination of either of the headers with the SMD pins will work, and the height is damn near spot on when used with the 14 pin socket and standard pins!

I still have the GCT BG050-10A-0-0450-0737-0350-L-D on order and will add the results when they get here, but it seems the Samtec ones work nicely.

Update 2:

Pins: 1798977 / GCT BG050-10A-0-0450-0737-0350-L-D. Plastic + bent pins measure 3.65mm. 

Combined with header the total is 10.62. The pins are at least 1mm shorter than the Samtec ones. They still fit quite well even when pulled back 0.2mm

Pins: 3585115 / Samtec TSM-105-04-L-DV. Pins above plastic is 3mm, which is too short to be comfortable. I would not recommend this.

Final conclusion:

The clear winner is the Samtec TSM-105-01-F-DV pins with either of the two headers. Since I've bought enough of the GCT pins already, and they work fairly well, I will go with those. The price is also between half and 1/3 of the Samtec, so if you're in the US they are probably a lot cheaper. Since I had to pay extra they are more or less the same. Had I not bought them I would have gone with the Samtec.

Both SHOULD work with the LCPCB headers too.

UPDATE: Suggested female headers are 20p and wont work. This one may work:

 

JLCPCB C2682198, https://jlcpcb.com/partdetail/2776421-X5521FV_2x05_C70D301000/C2682198