Need a hand

[sebotron]

Hi guys, sorry I've been a little sidetracked by non-pedal work.

I'm grasping at straws here but is your clock speed on the FXCore set to the same value as in the code?

Phil.

The PLL Range pins on the fxc are both pulled up so the fxc should be running at 48KHz with the proper clock speeds and the codec's default setting is set for MCLK @ 256fs for 8KHz to 48KHz, which is the case so I didn't touch the bits. Same with the audio interface format, default is i2s stereo. Again, same with slot length, default is 32-bit and the fxc datasheet mentions using the entire 32-bit

I suggest posting a short failing program that should work so we can see if there is something in the code.

All the default examples from the website result in horrible static.

This works fine:

Code: Select all

; gain
cpy_cs    r0, in0
cpy_cs    r1, pot0_smth
multrr    r0, r1
sls       acc32, 4
adds      r0, acc32
cpy_sc    out0, r0 

cpy_cs    r0, in1
cpy_cs    r1, pot0_smth
multrr    r0, r1
sls       acc32, 4
adds      r0, acc32
cpy_sc    out1, r0 

I'm just getting started with the assembly tbh, I figured I'd get the hardware down before diving into the software. All I can say for now is that copying any of the default programs and flashing to the fxc from the CLI asm results in a crazy amount of noise - except for the Function generator which seems to be working fine.

For what it's worth, here are my Diptrace files: https://drive.google.com/drive/folders/ ... sp=sharing

Not an EE so I'm very open to criticism and advice.

On a somewhat unrelated note: the fxc is running warm, not hot, but def warm. I haven't noticed this on the dev board but maybe I just didn't pay attention. Is this to be expected?

[Frank]

flashing to the fxc from the CLI asm results in a crazy amount of noise - except for the Function generator which seems to be working fine.

Interesting, what is the CLI version/platform? What is the command line you are running? Are you using the ICP or jumpering from the dev board to your board?

Have you looked at the lst file to see if it shows any errors in assembly?

Also need to consider what the chip is running internally that is different in function generator. Hmmmm, function generator is the only one that does not use an input it only writes to the output. I would look at the CODEC to FXCore lines and make sure there is nothing strange there. Your pass works but maybe something odd somewhere on the board..

Try the phase shifter, it only uses mreg and creg like function generator, no delay memory.

For what it's worth, here are my Diptrace files: https://drive.google.com/drive/folders/ ... sp=sharing

Unfortunately they seem to be V4 and we have V3 in house, can you export to V3? If not then please print to PDF files.

On a somewhat unrelated note: the fxc is running warm, not hot, but def warm. I haven't noticed this on the dev board but maybe I just didn't pay attention. Is this to be expected?

I would check the pin out, it sounds like you are pulling extra current for some reason.

[sebotron]

Interesting, what is the CLI version/platform? What is the command line you are running? Are you using the ICP or jumpering from the dev board to your board?

Latest CLI from the website running on Windows 10. Actually I was still using the GUI as of yesterday and saw that it was no longer supported so I suspected it might've been the issue. I downloaded the latest CLI but I have the same result.

I use -p 0 myprogram.fxc command to compile and then flash onto the chip but I also get the same behavior when flashing to ram (I don't remember the exact command as I'm not on my laptop rn but I know I'm using the right one as defined in -h)

And I am using the ICP.

Have you looked at the lst file to see if it shows any errors in assembly?

No assembly error in the lst files with both the little gain program I posted or any of the default examples.

Also need to consider what the chip is running internally that is different in function generator. Hmmmm, function generator is the only one that does not use an input it only writes to the output. I would look at the CODEC to FXCore lines and make sure there is nothing strange there. Your pass works but maybe something odd somewhere on the board..

Try the phase shifter, it only uses mreg and creg like function generator, no delay memory.

Which one would the phase shifter be? Anyhow, I tried all of them including the double shifter and the phaser (which I think might be the one you meant?) and I get the same result.

Like you, I suspect something funny on the input but AFAIK everything is coming in just fine from the codec, otherwise I don't think even a simple gain program would work?

Unfortunately they seem to be V4 and we have V3 in house, can you export to V3? If not then please print to PDF files.
I would check the pin out, it sounds like you are pulling extra current for some reason.

Here's the schematics in PDF: https://drive.google.com/file/d/13QinKE ... sp=sharing

The whole thing is split into two PCBs, one for power and analog signal path and then one for the digital stuff that gets fed 9VDC and has its own 1A LDO.

The switching is a little bit weird: I use a 4 channel CMOS-switch for both analog channels. Both channels are either routed to the codec or to the output so that when the effect is "bypassed", the codec input gets cut (trying for trails here). On the analog path sheet of the schematics you can see that the FXC output goes to a mixing pot along with the dry signal to a summing amp along with the bypassed input that would be floating when the fxc is on (but the line is pulled to gnd as to not leave it actually floating and for biasing). Sorry if this part is a little bit confusing. Will bring any clarification if needed.

So, pinouts are okay AFAIK and I doubt it's a soldering issue because I've been having the same warming up for the last few prototypes I built so I suspect I messed something up on the schematics so I would absolutely love if you had a look. Will provide PDF PCB layouts if needed.

All I can think of is that I might've something wrong in my schematics causing the pulling of extra current and I wouldn't be surprised that it would be also what's causing the white noise issue. I'll probably facepalm very hard when I see it.

Thank you for your time!

[stanleyfx]

Hi, A shot in the dark but one thing I see on your PCB is that you have your input and output jacks placed on one side of the PCB but directly opposite on the other side of the PCB and in line with the jacks you have the FX Core pots placed. I'm not sure this is a great idea as the digital control pot signals are right over the sensitive audio signals and may have crosstalk between digital and audio.

It might not be a problem as you mentioned the straight thrugh program is not affected.

[Frank]

1. Make pin numbers visible on the symbols, you have no idea how often people accidentally reverse digits like 32 and 23.

2. Add SDA/SCL resistors. While the note is correct on the PDF they should be on the board so the lines are not floating when the ICP is disconnected. The idea of the jumpers on the ICP is for people that make a main board with the resistors but also sell an add on board that connects to the main boards I2C. The add on would not have the resistors so you need them on the ICP but the main board would so you need to disable them on ICP. So put resistors on your board and remove on ICP unless it is an add on that will connect to a main board with them already.

3. Yes phaser is phase shifter.

4. Try rotary reverb. It is mono in/stereo out so trying to isolate input channels and see if an issue.

5. Is it always noise on both channels or is it ever one output is good and noise on the other?

Added note after original post:
The audio switching might be an issue, have you check that the SW_FX_BTP_A and SW_FX_ON_A are really the inverse of each other at all times? If they are ever both high then all switches are open and you have a number of floating signals.

[sebotron]

Hi, A shot in the dark but one thing I see on your PCB is that you have your input and output jacks placed on one side of the PCB but directly opposite on the other side of the PCB and in line with the jacks you have the FX Core pots placed. I'm not sure this is a great idea as the digital control pot signals are right over the sensitive audio signals and may have crosstalk between digital and audio.

It might not be a problem as you mentioned the straight thrugh program is not affected.

Hey man! I mean.. maybe? I was careful of using a separate LDO on the analog board as to avoid any noise coming from the digital PCB and I watched tons of Rick Hartley videos before diving in haha

But like you said, if that was the issue I feel like the crosstalk would always be present even when doing a simple passthru/gain effect indeed, which isn't the case.

1. Make pin numbers visible on the symbols, you have no idea how often people accidentally reverse digits like 32 and 23.

The component was imported from Eagle and somehow the pad numbers from the components are the same as the pin names but whatever I triple-checked and renamed the pads without saving my component. The PDF has been updated.

2. Add SDA/SCL resistors. While the note is correct on the PDF they should be on the board so the lines are not floating when the ICP is disconnected. The idea of the jumpers on the ICP is for people that make a main board with the resistors but also sell an add on board that connects to the main boards I2C. The add on would not have the resistors so you need them on the ICP but the main board would so you need to disable them on ICP. So put resistors on your board and remove on ICP unless it is an add on that will connect to a main board with them already.

Gotcha. I've updated my schematics.

3. Yes phaser is phase shifter.

Right.

4. Try rotary reverb. It is mono in/stereo out so trying to isolate input channels and see if an issue.

Same, noise regardless. However - I can def hear the effect applied to the static and when I turn some knobs so it's almost definitely something with the inputs - but how the hell would a passthrough or simple gain program work just fine?

5. Is it always noise on both channels or is it ever one output is good and noise on the other?

Always both.

Added note after original post:
The audio switching might be an issue, have you check that the SW_FX_BTP_A and SW_FX_ON_A are really the inverse of each other at all times? If they are ever both high then all switches are open and you have a number of floating signals.

I hear ya, but ya they're swapped from the MCU code and rn I've even disabled the bypass switch and just pull up SW_FX_ON_A ( "_A" suffix is for analog board btw, "_D" is for digital ofc) and SW_FX_BYP_A is pulled down.

You guys seeing anything that might be responsible for pulling current? I left for a few hours this afternoon and let the whole thing running, still warm but not more warm so it's not runaway or anything. Very weird.

EDIT: Something else I just noticed. I connected the FXC Codec Reset pin to the MCU so that I can catch when it pulls down and then reset the codec myself which I figured was the best way to do it but I haven't done anything in my MCU code yet. Also I noticed that this pin is pulled down through a 10k resistor on the dev board while on mine, it's pulled up through a 10k resistor and then connected to an mcu gpio pin. How and when would the FXC want to reset the codec? I haven't found anything in the datasheet.

Again, thank you. Really appreciate the help.

[Frank]

Same, noise regardless. However - I can def hear the effect applied to the static and when I turn some knobs so it's almost definitely something with the inputs - but how the hell would a passthrough or simple gain program work just fine?

Interesting.

EDIT: Something else I just noticed. I connected the FXC Codec Reset pin to the MCU so that I can catch when it pulls down and then reset the codec myself which I figured was the best way to do it but I haven't done anything in my MCU code yet. Also I noticed that this pin is pulled down through a 10k resistor on the dev board while on mine, it's pulled up through a 10k resistor and then connected to an mcu gpio pin. How and when would the FXC want to reset the codec? I haven't found anything in the datasheet.

Basically the CODEC reset is active from power on until the PLL stabilizes so stable clocks are going to the CODEC when released. We used a pull down so the line would be low as soon as power was applied to try to avoid any CODEC pop. Using a pull up is probably fine.

Nothing jumps out at me as to why it is running a little hot, could be nothing.

Do you have a logic analyzer? I would capture the I2S lines and examine the data as well as trace the analog signal to see if there is a short. When you did the small tests for pass through did you apply the same signal to left and right? If so try different signals on them.

[PhilHaw]

We did consider using the MCU to control the Codec reset pin but in the end we just connected it to the FXCore pin 48 nCODECRST and it works fine that way.

Phil.

[sebotron]

Hi guys, sorry for the delay - got distracted by other stuff.

Ok so, I think I fixed my input issue for the most part. I had two things very wrong that you couldn't have been able to tell from the schematics.

First one is this: https://i2.paste.pics/48d86571eb9869edf ... 5bff50.png - one supply filter cap and one codec analog input cap connected to each other's pads so my bad *facepalm*.

The other thing was that my input jack 1 wasn't grounded, at all. I'm still getting used to Diptrace, used Eagle for years, and apparently my ground net wasn't connected to the pin and it wasn't very obvious.

I fixed both, the noise is gone, fxcore and ldo are still warm-ish.

Now, my issue is I have no output from the DAC when routed from SDI0 (default setting on codec) but I do when I route it to SDO0 (input loopback, essentially) so I'm not sure what's up because I do have data coming in from the fxcore.

Had a gig last night and still feeling it this morning so I'm taking it easy to day but will report back very soon

[PhilHaw]

Glad you've made some progress. I see what you did with those caps - easy mistake to make!

Regarding the ground net error, that's strange because the DipTrace 'Check Net Connectivity...' check doesn't pick it up - I tried it with your pcb layout file.

I then ran the ERC Check on your schematic and, amongst several other errors, it shows "Wire superimposing (no connection): GND_D. This is because the wire is superimposed on the other connections but not actually connected to them. This explains why the PCB connectivity check didn't spot this: as far as it's concerned, the PCB connections are correct per the schematic.

https://app.box.com/s/rxi4p9j9tft7deui18rx67epxsb17pfh