lichtuberstromt Posted December 22, 2019 Report Share Posted December 22, 2019 I've been implementing analog controls in the GOOM distribution for STM32F4, and thought I had conquered all of my issues with AINSER with much help from the forums. Got all my controls on panels now and wired everything up and have a whole new problem. Only one control on the first MUX chip works. I'm only using 3 chips and the other two work perfectly. I am almost positive that I tested the first MUX chip, but perhaps not... It's acting like the MUX isn't getting the ABC bits to advance through each channel, it just stays on the first channel and AINSER assigns that pot's value to all of the pins on that chip. But ABC on MUX 1 are receiving the same pattern as MUX 2 and 3. Tried swapping MUX chips around with no change. Same with ribbon cables. Really seems like it's a hardware issue, but I can't for the life of me find it. I'm out of time for the day, but plan to rebuild it on the breadboard and see if the problem persists. Could this be caused by software? I can't see anywhere in AINSER that would cause this kind of an issue. To be clear, there are 8 knobs (parameters 0-7). Only one knob generates values and it assigns that value to all parameters (0-7). I built my module with a bit of a weird pin mapping, so the working knob is number 6, but this is the one connected to X0 on the MUX. Which really makes it seem like the MUX just isn't advancing. I can change pin mapping and it still only reads that one knob, thought it does change the order in which it assigns pin values (matching the pin mapping). Any thoughts as to where to look for further testing? Thanks! Jeff Quote Link to comment Share on other sites More sharing options...
latigid on Posted December 22, 2019 Report Share Posted December 22, 2019 You mention AINSER, but talk about muxes. Do you mean AINSER64 (even if not all multiplexers are used)? Are you using a self-designed board or something from uCapps? Maybe the scanning isn't working properly? Try http://ucapps.de/mios32/ainser_jitter_mon_v1_002.zip for diagnostics. Quote Link to comment Share on other sites More sharing options...
Antichambre Posted December 22, 2019 Report Share Posted December 22, 2019 (edited) So you've got a custom AINSER64 with 3 MUX only and you use only 3 channels of the ADC. Your issue is very strange. It can't be inhibit pin issue cause inhibit switches off all multiplexed inputs. It can't be the ADC cause you receive something from third channel. ABC lines are the same for all MUX, so there's no short-circuit, cause only one MUX doesn't work. Just in case, is there continuity between all "A" pins, "B" and "C" of the MUXes? But I'm pretty sure you already checked it. It's not a faulty MUX cause you swapped them. Hummm... When you say: 1 hour ago, lichtuberstromt said: To be clear, there are 8 knobs (parameters 0-7). Only one knob generates values and it assigns that value to all parameters (0-7). Does it means the AIN hook is called 8 times when the only working knob is moved? Edited December 22, 2019 by Antichambre Quote Link to comment Share on other sites More sharing options...
lichtuberstromt Posted December 22, 2019 Author Report Share Posted December 22, 2019 Sorry, should have been more clear - this is a self built module based around AINSER64. Just pared it down to 3 muxes and inadvertently did some pin swapping. Antichambre - I agree, this is strange. It feels so much like the ABC lines are not firing, but the are on the same node as the two functioning muxes. You're correct that there is continuity for all A pins, B pins, and C pins. The only thing I can possibly come up with is that this was my first PCB layout and I did a bad job routing these lines. Specifically on the failing MUX, the C line is almost twice as long as A or B. Other MUXes are all similar length lines. Is this enough to cause this issue? Yes, the AIN hook is called 8 times. I have a debug message in the main notifier and it gives me 1 message for each pin all with the same value. I'm as confused as can be. Later tonight I'll try to breadboard just a single mux on the first channel of the ADC. That is the other weird thing I did - I wired my ADC backwards. MIDIBox design calls for channel 7 as Mux 1, 6 as mux 2 etc. I went channel 0 as Mux 1. Had to change some code, but I don't think it should cause this kind of issue. I'll suss it out on the breadboard when I get a chance... Thanks for taking a look at this! Jeff Quote Link to comment Share on other sites More sharing options...
Antichambre Posted December 23, 2019 Report Share Posted December 23, 2019 14 hours ago, lichtuberstromt said: Specifically on the failing MUX, the C line is almost twice as long as A or B. Other MUXes are all similar length lines. Is this enough to cause this issue? No, this is not the issue. Did you try the tutorial 012b? To test your AIN module alone. Best, Bruno Quote Link to comment Share on other sites More sharing options...
Zam Posted December 23, 2019 Report Share Posted December 23, 2019 Hello Did you check the analog side ? I mean the pots to multiplexer path ? If you make the 8 pot wiper like a single bus... Best Zam 1 Quote Link to comment Share on other sites More sharing options...
Antichambre Posted December 23, 2019 Report Share Posted December 23, 2019 12 minutes ago, Zam said: Hello Did you check the analog side ? I mean the pots to multiplexer path ? If you make the 8 pot wiper like a single bus... Best Zam Ahah! Clever! Quote Link to comment Share on other sites More sharing options...
Zam Posted December 23, 2019 Report Share Posted December 23, 2019 Just now, Antichambre said: Ahah! Clever! plz wait until OP say something...can be dumb too Still (no offense) I find pples around so focused on digital and code that they usually miss the first things to check in the chain Best Zam Quote Link to comment Share on other sites More sharing options...
lichtuberstromt Posted December 23, 2019 Author Report Share Posted December 23, 2019 So its not the wiper, but that is indeed a clever possibility! And exactly why I love this forum. You guys always have ideas I'd never think of. Unfortunately, I've got 3 seperate control banks (8 pots each), and they each work fine on the other two MUXes and also exhibit the same weird behavior on the first MUX. Good thinking on the tutorial Antichambre - had forgotten all about the initial AINSER testing I had to do. Ended up just loading the MB128 Controller because it was handy and already has debug messages. Works fine... Each pot has its own pin and its own unique value. Albeit this is all when plugged into J19. My Goom implementation has AINSER running on J8/9 and its associated SPI. Goom uses the onboard DAC of the STM32F4 which uses the same SPI as J19. So I'm thinking the problem must lie in modifications I've made to the AINSER software module... Not sure off the top of my head, what could be causing this rather unique issue, but I'm going to start over again with the original AINSER code and slowly remodify it again. What's strange is that I could swear I had it all working. Then this problem popped up after setting it all aside to work on other projects. Of course that also means there are some major lapses in my memory, so who knows what I did to the code... Again, many thanks for the help - always good to have a few fresh eyes and brains to help regain perspective on this stuff. You all rock! Will report back shortly! Quote Link to comment Share on other sites More sharing options...
lichtuberstromt Posted December 23, 2019 Author Report Share Posted December 23, 2019 Ok, so it turns out to be a rather clever trick that I've pulled on myself (at least I think this is the issue). MIDIO128 works great on SPI 2. But I need SPI 1 for implementation of Goom because of a conflict with the DAC. MIDIO128 exhibits the same problem when using SPI1 and J8/9. To use SPI 1, I was just simply changing line 42 in AINSER.H and all was well. Not exactly, but it avoided the conflict with the DAC at least. This morning I realized that I can improve things a bit by also changing the RC pin assignments a bit. My understanding from the comments in AINSER.H is that SPI 2 can use RC1 or RC2, but J8 can only use RC 1. But if I alter the code for the first AND second module to be assigned to RC2, all of the pots work. Except the one pot that spit out data for all pins, still does so. Closer, but not fixed. Unfortunately, I save tons of space and money by eliminating the CS jumper and hardwiring to RC2. So now its time to see if I can swap the lines in the ribbon cable and make it work on RC1. I'm a little confused as to why or how the CS line is causing this issue, but it seems to be at least related to the code and my "custom" board. I think I've learned to do a little improvising when copying circuits... That CS jumper would be nice to have right about now... Quote Link to comment Share on other sites More sharing options...
lichtuberstromt Posted December 23, 2019 Author Report Share Posted December 23, 2019 Well... Just noticed something interesting. All of my errant data is coming in on the other module. The one I'm not using. Whatever is happening is way over my head, but I think I can just parse it out. With the module set to only use RC1 and the ribbon cable modified to also use RC1, all of the knobs return appropriate values for Module 1. One knob also returns its values for all of the other pins (except for itself) on Module 0. So I can just write my handler to ignore commands from module 0. It's a bit of a kludge, but it works for my purposes. It gets weirder though. The original AINSER64 code addresses the ADC channels in reverse order. u16 pin = muxed ? (mux_pin_map[mux_ctr] + 8*chn) : chn; // the mux/chn -> pin mapping is layout dependent //u16 pin = muxed ? (mux_pin_map[mux_ctr] + 8*(7-chn)) : (7-chn); // the mux/chn -> pin mapping is layout dependend The first line is modified as suggested by Antichambre to work around the fact that I wired it backwards from the original midibox wiring. The commented out line is the original code. Until now, I thought this was a bit of a kludge and fairly odd that MUX 1 was supposed to be wired to Chan 7 of the ADC. I'm assuming the problem I'm having is maybe the reason (or one of the reasons) why its wired as such. If I use the original code, I have no weird issues. The pin numbers are completely wrong, but thats to be expected. So I'm thinking that must be the issue. For now I'll just filter out the data from Module 0. I'll breadboard it with the correct wiring and see how it behaves though. Would eventually like to revise my PCB to have the RC jumper and just make things a little less sloppy. I still trusted the autorouter a bit too much when I made this one... Have since found the joy of manual routing. It's almost soothing... Thanks again for the guidance on all of this. This would be in the pile of sad broken things without this forum. A little nudge in the right direction is beyond valuable! As is paying attention to the original schematic and not "fixing" anything... Woops :) Quote Link to comment Share on other sites More sharing options...
lichtuberstromt Posted December 23, 2019 Author Report Share Posted December 23, 2019 (edited) one more new problem... I have a pin map that works for MUX 2 and 3. Doesn't work for MUX 1. The obvious answer would be that I screwed up the layout, but I keep checking it and everything is fine. And that kind of makes me think of the A B and C lines again. MUX 1 is just really off. Tried swapping chips again with the same results. Rechecked for continuity between A, B, and C lines. Really don't want to breadboard all three MUX chips, but I'm feeling like I may have to. Was so excited to have normal values earlier, that I failed to notice that the pin numbers were wrong. So back to the thinking board for me. Any thoughts as to what could cause one MUX to have a different pin mapping than an another? Wouldn't it have to be either swapped A, B, C lines or some swapped lines between the pots and MUX inputs? I'll recheck between pots and MUX and see if I can find anything out of place. And its consistently wrong on the pin mapping. Has the same issue whether I use the code for the reversed ADC channels or the original code. FWIW, this is at least the fun kind of puzzle that I enjoy. I'm not great at solving them obviously, but I could worse things to be confused by... edit - should add that everything works fine under MIDIO128 on SPI2. Pins are all reading perfectly and actually in the right order. Strange that the simple move to SPI1 seems to throw everything off on MUX 1... Edited December 23, 2019 by lichtuberstromt new information Quote Link to comment Share on other sites More sharing options...
Antichambre Posted December 24, 2019 Report Share Posted December 24, 2019 11 hours ago, lichtuberstromt said: It gets weirder though. The original AINSER64 code addresses the ADC channels in reverse order. u16 pin = muxed ? (mux_pin_map[mux_ctr] + 8*chn) : chn; // the mux/chn -> pin mapping is layout dependent //u16 pin = muxed ? (mux_pin_map[mux_ctr] + 8*(7-chn)) : (7-chn); // the mux/chn -> pin mapping is layout dependend The first line is modified as suggested by Antichambre to work around the fact that I wired it backwards from the original midibox wiring. The commented out line is the original code. Until now, I thought this was a bit of a kludge and fairly odd that MUX 1 was supposed to be wired to Chan 7 of the ADC. I'm assuming the problem I'm having is maybe the reason (or one of the reasons) why its wired as such. If I use the original code, I have no weird issues. The pin numbers are completely wrong, but thats to be expected. I'm surprised cause I did it for the HAARP and use a 4 channel ADC to reduce the cost. But I use it on the regular J19. Channels are reversed like you. I don't use the AINSER64 module and add/rewrite a simplified/dedicated copy in the app folder. I made some changes to reduce the scanning and make it faster. The CS uses only 16 inputs, the 16 others are for a future extension like CV in. And it works for me. s32 ARP_AIN_POT_Handler(void (*_callback)(u32 pot, u32 value)) { // the mux_ctr -> pin mappin is layout dependend const u8 mux_pin_map[8] = {0, 1, 2, 3, 4, 5, 6, 7}; static u8 mux_ctr = 0; // will be incremented on each update to select the next AIN pin static u8 first_scan_done = 0; static u16 link_status_ctr = 0; s32 status = 0; // init SPI port for fast frequency access // we will do this here, so that other handlers (e.g. AOUT) could use SPI in different modes // Maxmimum allowed SCLK is 2 MHz according to datasheet // We select prescaler 64 @120 MHz (-> ca. 500 nS period) status |= MIOS32_SPI_TransferModeInit(ARP_AIN_SPI, MIOS32_SPI_MODE_CLK0_PHASE0, MIOS32_SPI_PRESCALER_64); // determine next MUX selection int next_mux_ctr = (mux_ctr + 1) % 8; // loop over channels int chn; for(chn=0; chn<2; ++chn) { // CS=0 status |= MIOS32_SPI_RC_PinSet(ARP_AIN_SPI, ARP_AIN_SPI_RC_PIN, 0); // retrieve conversion values // shift in start bit + SGL + MSB of channel selection, shift out dummy byte MIOS32_SPI_TransferByte(ARP_AIN_SPI, 0x06 | (chn>>2)); // shift in remaining 2 bits of channel selection, shift out MSBs of conversion value u8 b1 = MIOS32_SPI_TransferByte(ARP_AIN_SPI, chn << 6); // shift in mux_ctr + "Link LED" status to 74HC595, shift out LSBs of conversion value //u8 b2 = MIOS32_SPI_TransferByte(ARP_AIN_SPI, ((chn == (ARP_AIN_NUM_CHANNELS-1) ? next_mux_ctr : mux_ctr) << 5) | link_status); u8 b2 = MIOS32_SPI_TransferByte(ARP_AIN_SPI, (chn == 1 ? next_mux_ctr : mux_ctr) << 5); // CS=1 (the rising edge will update the 74HC595) MIOS32_SPI_RC_PinSet(ARP_AIN_SPI, ARP_AIN_SPI_RC_PIN, 1); // store conversion value if difference to old value is outside the deadband u16 pot = mux_pin_map[mux_ctr] + 8*chn; // the mux/chn -> pin mapping is layout dependend u16 value = (b2 | (b1 << 8)) & 0xfff; previous_arp_ain_pot_values = arp_ain_pot_values[pot]; int diff = value - previous_arp_ain_pot_values; int abs_diff = (diff > 0 ) ? diff : -diff; if( !first_scan_done || abs_diff > ARP_AIN_POT_DEADBAND ) { arp_ain_pot_values[pot] = value; // notify callback function // check pin number as well... just to ensure if( first_scan_done && _callback && pot < 16 ) _callback(pot, value); } } // select MUX input mux_ctr = next_mux_ctr; // one complete scan done? if( next_mux_ctr == 0 ) first_scan_done = 1; return 0; // no error } For your layout: You can change the MUXes mapping here: // the mux_ctr -> pin mappin is layout dependend //const u8 mux_pin_map[8] = {0, 1, 2, 3, 4, 5, 6, 7 }; //const u8 mux_pin_map[8] = {1, 4, 3, 5, 2, 7, 0, 6 }; // reversed pins const u8 mux_pin_map[8] = {6, 3, 4, 2, 5, 0, 7, 1 }; // order of MUX channels You can reduce the channels: for(chn=0; chn<3; ++chn) { u8 b2 = MIOS32_SPI_TransferByte(AINSER_SPI, ((chn == 2 ? next_mux_ctr : mux_ctr) << 5) | link_status); And limits the number of inputs by security: if( first_scan_done && _callback && pin < 24 ) Quote Link to comment Share on other sites More sharing options...
lichtuberstromt Posted December 24, 2019 Author Report Share Posted December 24, 2019 Yeah I think I was confused when I came to that specific conclusion. Using the MIDIO128 as a testing tool, it works fine on J19 with your modified code perfectly. Switching to J8/9 makes MUX 1 act strange and have an incorrect pin order. The other 2 MUXes continue to behave perfectly. Still a lot of random data coming through from the "other" module that doesn't exist, but I'm just parsing that out and it seems to work fine. I'll try reducing the channels and number of inputs. Appreciate seeing your code for HAARP. I think I may do the same and move to a copy in the app folder so I can leave the original AINSER module in its original state. Read through the datasheet for ADC (MPC3208 - I stuck with the 8 channel for unknown reasons) and all I can imagine is that Din is doing something really strange when it tries to read from the first MUX. If I remember right it has the ability to go low and create leading zeros, and maybe its doing it in some kind of mysterious way that leaves me with an unordered (but repeatable) set of pins. Seems like a really far-fetched explanation though. My other thought is that J8 is just running a different clock speed that is making things act strange. Seems equally far fetched though. Do you (or anyone) know of potential conflicts on SPI 1? I've moved SRIO to SPI 0 with no change, and I think there is some overlay from the non-audio DAC, but I'm not using it anywhere. Otherwise I'm not seeing how SPI 1 should be operating so differently from SPI 2. It would make more sense if it just didn't work at all, but changing the pins of just 1 MUX is so odd... Thanks again for all your help! And a happy holiday to all celebrating anything! Or not! Happy day regardless! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.