Jump to content

More AINSER Problems


lichtuberstromt
 Share

Recommended Posts

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

Link to comment
Share on other sites

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 by Antichambre
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

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 by lichtuberstromt
new information
Link to comment
Share on other sites

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 )

 

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...