Troubleshooting midiphy SEQ v4+

[otropom]

Thanks for your reply, actually testing the matrix with seq_r (seq_l either) on CC16 (ch1, with the NG loaded) doesnt seems to work, cant figure out if i'm missing something but i will try again this this afternoon. By the way here's another video of the beast booting up, hope it will help find this little problem

 

[latigid on]

Thanks for the report; the matrix scan would be useful, but it does look somehow like the bottom two rows are connected?

If the rest of the SRIO chain is fine probably the issue is with the output side.

I would check the cable for shorts once more. Plug a double-row pinheader in and check continuity for adjacent pins starting in the bottom-left corner 1-2 (bottom right if you view from the pin side) but also the top pin to the next in the series 2-3 etc.

2 4 ...
1 3
notch this side

The rows are on 8-pin header J5 and the corresponding side of the 24-pin header. Check the male pin headers too.

For soldering:

Disconnect the IDC24/16/8 cable and power. Are there shorts on adjacent pins of IC18 on lemec_R? Pins 1,2,17 and 18 would be of interest. 
On IC17, check for shorts on pins 6,7 and 8 especially.
On the JA board, the pinout for the LED matrices has row 1 on pin 5 and row 2 on pin 2 (there's a silkscreen indication for pin 1). Check that there are no shorts there especially.

With _NG and probably best with no .NGC loaded, you can use the MIOS terminal command
 

set dout x 1

where x is the shift register pin and 1 turns it on. Count the number of SRs in the chain *8 to set the pins of IC17 The idea is to see if you can control the 74HC595 pins independently. You can also use this to test the matrix: turn on row one and then the columns in turn with the subsequent 8 SR pins.

Good luck!
Andy

[laual]

Hi all, 

I'm almost done with my build. I've been lucky since I've gone so far without too much problems for my first build ever. Thanks for the video guides which have been more than helpful. 

It seems the only problem I've is with the Oled screens:

Each screen works when plugged individually, I swapped the cables to check that there are no shorts in the cables but when I plug the two screens in the core only the screen 2 works. 

Does anyone have an idea how to troubleshoot this further? 

Thanks for the help and for all the development behind this machine, can't wait to try it out! 

Laurent

[Karg]

Hi,

I had a similar problem with the "non-plus" version of the sequencer. If I recall correctly, the issue was in 3.3V vs 5V.

Check if Jarvis here in the OLED display thread on page 2 describes your issue. If so, the solution was provided a couple of posts below.

 

[laual]

Hi Karg,

I tried switching the voltage toggle to all positions on the STM32F4 but it doesn't resolve the problem. It is on 5v in. Followed the video tutorial to prepare the core. The displays appear to be 3,3v on the Midiphy shop.

How can I proceed further?

Thanks!

[laual]

So, I've tried setting lcd_type to 0x02 in the bootloader but still no luck.

[Hawkeye]

@laual, congrats to your build so far, the displays should be fixable, too! :)

I am sure Andy will chime in later on, but meanwhile, could you check R33A, R33B, R33C and R33D on the wCore?

R33A-C should be all 1k, but R33D must be 560R. Now if you had a 1k in R33D, that might explain what is going on (happened to me, too :)).

J15_S needs to be set at 3.3V.

Many greets!
Peter

 

[laual]

Hi Peter,

Resistance on the core are correct but I appear to be missing "J15_S needs to be set at 3.3V". How do I set this? Do I jumper the middle pin with the 3.3V pin?

Edit:

That was it, I must have missed this step in the build guide. It's working now, I'll make a quick jump between middle pin and 3.3V.

Thanks a lot (also for the video guides)

 

Edited February 25, 2020 by laual

[latigid on]

Hi Laurent,

That's probably it, there is no power supply to the OLEDs in this case and they are likely parasitically powered somehow.

Here you can borrow the jumpers from the v407 board:

https://www.youtube.com/watch?v=QaN26uzUA1A&t=3357s

 

I'm on holiday and the internet is too slow for me to find the tutorial step where the jumpers are inserted, but yes, you must connect the middle pin of J15_S to the 3v3 side.

Hope that solves it!

Best,
Andy

[slo]

My V4+ is almost built but  I have 1 small problem. The mighty beat LED colors are inverted, green on the beat, red on the measure. Checked the RJ9 resistors, they are all ok, looked in config, I have no idea why this is happening. Help!

[latigid on]

You could swap the resistors around or simply the pins in the HWCFG:

#           SR  Pin ##default
LED_BEAT    M5B  0
LED_MEASURE M5B  1

#           SR  Pin ##swapped
LED_BEAT    M5B  1
LED_MEASURE M5B  0

 

There is also a setting in the options menu to invert the LED colours (MENU>UTILITY>OPT.; maybe this has an effect somehow?:

OPTIONS page: new option "Swap LED colours" (relevant for Wilba and midiphy Frontpanels)

 

[slo]

Fixed, by swapping the values in the HWCFG. Now to button up and take some pics.

Thanks Andy.

[mcmurray]

Edit: got it working by re-soldering IC1, got the idea from this post: 

Hi guys, finally it's my turn to ask questions in this topic. My build is very close, I can feel it!

I'm currently testing my LEMEC boards. Happy to report that nearly everything works apart from the 3rd encoder on the LEMEC-R. Turning it gives nothing in the debug window, however pushing the button works.

I've tried the other encoder board, but the problem remains. Have checked soldering in that area, as well as checked for shorts. Any ideas on what I could try next? Is there a schematic available?

Edited April 4, 2020 by mcmurray

[latigid on]

Trying the other encoder board means you swapped the other SEQ-plate onto le mec _R? Then the issue is probably on le mec_R.

The encoder pins for ENSW3 are connected to pins 6 and 7 of J1 for both PCBs of the stack. Pin 1 is identified with a square solder pad (on the left when viewed from the top, so right-to-left if you're looking at the bottom of le mec).

IC1 is the 165 shift register reading this encoder. You should measure continuity to pins 3 and 4 from the encoder pins. If not, check the soldering on the headers and that the interconnections are sound (were longer male pinheaders used?).

You can also carefully short pins 3 and 4 to 0V (ground) and see if DIN events are registered. Use "set debug on".

Here's a composite of what I wrote above:

 

 

Edited April 4, 2020 by latigid on

[mcmurray]

Thanks for that reply latagid, managed to sort that issue out :)

Here's where I am now.

All testing throughout the build process was successful, further problems arose once installing the modules in the case. When I load seq_l now, I get the result in the picture above.

Debug mode does not register any inputs. I wonder if I've shorted something, will continue troubleshooting (starting with removing modules from the case and re-testing per the build video) and post back here.

I noticed the ribbon cable connections are different in the RH case compared to the testing which was done in the build video. Does the seq_l program need to be changed to accommodate this so that testing may be conducted in this configuration?

Edited April 6, 2020 by mcmurray

[mcmurray]

Some progress - I found seq_r and now fluxtest works again.

With debug mode on the led pushbuttons are not lighting up, and the LED matrix is not changing with CC16. Will continue troubleshooting and report back.

Edited April 6, 2020 by mcmurray

[latigid on]

A few steps forward... :)

The seq_r (or _l) file must be loaded to trigger LED events with the pushbuttons. Check that MIOS Studio is sending events on Ch. 1 for the JA matrix.

Check that there is sufficient clearance between the board stack and isolate the J8/9x pin headers if needed. 

[mcmurray]

When the boards are configured as left handed, seq_l works perfectly, including fluxtest, CC16 and pushbuttons/LEDs. Have not tested the OLEDs in this config, I will however.

When the boards are configured as right handed, with seq_r loaded only the pushbuttons/LEDs on the JA board work. LEMEC pushbuttons do not trigger the LEDs, and produce random lighting of the keys. CC16 doesn't have an affect on the LED matrix. With OLEDs connected they are blank.

Is there anything else you can think of which would cause LH configuration to work, but RH to not work?

I will check everything you mentioned. Thank you.

[latigid on]

I faintly remember an issue like this where the Core OLED power jumper was not installed, also check OLED cabling and R33D.

This one:

 

Edited April 6, 2020 by latigid on

[mcmurray]

Jumper is set to 3.3V and R33D is 560R (561 written on the SMD resistor).

I've just changed configuration to LH, run seq_l and nothing is showing on the OLEDs. Next I will check the OLED cabling, will report back!

[mcmurray]

Can the full SEQ program run with just the JA or the LEMEC-L board connected?

I'd like to narrow down the fault by testing JA first if possible. I want to know that the core is operating as expected then I'll connect remaining boards to see where the problem lies.

Edited April 6, 2020 by mcmurray

[latigid on]

Should work, just remember to use the correct SEQ HWCFG file. Like the .NGC, the left/right suffix refers to the position of the JA board. You can also add boards one by one for the _NG testing, good idea.

It would even be possible to make a custom .NGC based on the  _R file and adjust the shift register addressing to test lemec _R first in the chain. You need to adjust the positions of the shift registers because there are three extra ones (that go off to the JA matrix) before the "main" BLM and encoder scanning ones.

Maybe some cables are twisted? They should run in a nice chain, correct? Do all of the IDC shrouded header notches have the correct orientation?

You might consider reformatting the SD card or reflashing the app. 

[lp1977]

12 hours ago, mcmurray said:

Is there anything else you can think of which would cause LH configuration to work, but RH to not work?

@mcmurray, Not sure about the OLED issue, but in regards to the LH/RH behavior, when I built my right handed v4+ I also had seq_l.ngc working properly with the boards plugged in in left hand configuration, with seq_r.ngc behaving strangely when plugged in in right handed configuration. I saw an earlier post by @sis.tm that helped me jump that hurdle where he mentioned:

On 3/29/2019 at 4:48 AM, sis.tm said:

- I would suggest when you are at the part of building everything in the case use the final firmware with hw file for testing. I first used the Seq_r file but had some strange things. When i used the final firmware i didn't see this occur.

 

So, based on that, I then tried the final firmware (at the time. 0.95?) with the HWCFG right hand MBSEQ_HW.V4 with everything plugged in in right hand configuration and everything worked fine.  I just chalked it up to the seq_r.ngc file that I had and moved forward.

 

Once it was running the seq_v4 application, another thing that threw me off a little was my TPD behavior not matching what I had seen in videos and pictures.  By changing the setting of the TPD on the Midibox itself by pressing Utility -> options -> opt26 -> "Green LED: POS   Red LED: Track", this gave me the TPD behavior I was seeing in the various videos and pictures. 

 

Not trying to derail any troubleshooting you guys have going on here in this thread, but maybe try loading the seq_v4 firmware and use the right hand MBSEQ_HW.V4 config file with it all plugged in in right hand configuration and see what you get. 

Just my observations.

Here's the post I referenced earlier:

 

Edited April 6, 2020 by lp1977

[mcmurray]

6 hours ago, lp1977 said:

@mcmurray,

Not trying to derail any troubleshooting you guys have going on here in this thread, but maybe try loading the seq_v4 firmware and use the right hand MBSEQ_HW.V4 config file with it all plugged in in right hand configuration and see what you get. 

 

Thanks! Was thinking about trying this also, it did cross my mind that maybe seq_r was buggy. Will report back.

[mcmurray]

Partial success! Apart from the OLEDs, the sequencer appears to be working in both LH and RH mode. I did what lp1977 suggested and ignored seq_r testing, and loaded the full program and the hwcfg. I get the "DEFAULT" scroll accross the matrix on startup, and the transport buttons appear to work.

Now all I need to do is troubleshoot the OLEDs. I built the cables exactly as shown on the video but both displays are blank. Is it possible to get a list of OLED pins and the voltages which should be on them so I can do some further testing?