Troubleshooting midiphy SEQ v4+

[latigid on]

Check the green diode functions by using a multimeter in diode mode (black probe to CC pin) directly on the LED legs.

Some of the soldering doesn't look like proper joints were made, so make sure to reflow the pins. It would be odd, but maybe on RJ3 and RJ7?

The description of the error points more to an issue with IC4 pin 2, R14 (resistor legs too long?), but from your picture these look okay. It might also be T14 on the front side of the board. This part of the schematic is on page 2.

 

[TheMentat]

OK... after drowning my misery in beer last night, I had a go at fixing the problem...

- confirmed LED function with a multimeter

- swapped IC2 and IC4

- reflowed a number of solder joints

- reflowed RJ2 and RJ6 (which, as I type this, I am realizing should have been RJ3 & RJ7)

when that didn't work, I pulled the switches (which actually went a lot smoother than expected with hot air) and swapped T15 & T16.  None of this worked.  Aside from reflowing RJ3 & RJ7, do you have any other ideas?

[latigid on]

Check T14 and R14!

Do you measure any voltage out of pin 2/R14? Follow that down to T14. When you read the T14 label right way up, you should have continuity to R14 on the top-right pin, +5V on the top left pin. The bottom pin is the source current for your green LEDs on columns 3/7.

[TheMentat]

looks like T14 had a bad leg, and will need replacement.

 

In the meantime, it seems like I've developed a couple of other issues:

- superflux 4,8,12 & 16 , and have a very slight red glow to them (like a short somewhere), and 20 & 24 also glow dimly...

- SW10 no longer illuminates the corresponding superflux (in fact, it slightly green illuminates the superflux on #2 above it)

Edited September 8, 2019 by TheMentat

[latigid on]

9 hours ago, TheMentat said:

- superflux 4,8,12 & 16 , and have a very slight red glow to them (like a short somewhere), and 20 & 24 also glow dimly...

I would suspect IC4 pin 1, R15, T15, RJ7, perhaps also IC4 pin 15, R16, T16, RJ8.

Also check the transistors on the rear of the board and their associated Schottky diodes.

 

9 hours ago, TheMentat said:

- SW10 no longer illuminates the corresponding superflux (in fact, it slightly green illuminates the superflux on #2 above it)

Do you still get a DIN event in MIOS Studio?

Is the switch soldered in properly? The associated diode? If the other switches in the column work, then the matrix is okay and the issue might be with the LED itself or the switch of course.

[TheMentat]

I've resolved the SW10 issue... bad solder joint on the super flux CC after I pulled the switch.

While waiting for the new transistors, I swapped T15 and T16.  Doing so switched the affected superfluxes to green (instead of red).  This suggests a bad transistor which will also have to be replaced.  I suspect I messed up some of these by eagerly trimming the RJ resistor legs.  

 

Moving along, I've started mocking up the final assembly.  For some reason, plugging in the displays will not allow the SEQ to boot (the green LED on the SDcard module does not light).  This only occurs when I jumper J15_S.  I suspect a short somewhere on the power rail for the displays... sound right?

[latigid on]

7 minutes ago, TheMentat said:

I've resolved the SW10 issue... bad solder joint on the super flux CC after I pulled the switch.

Good!

 

7 minutes ago, TheMentat said:

While waiting for the new transistors, I swapped T15 and T16.  Doing so switched the affected superfluxes to green (instead of red).  This suggests a bad transistor which will also have to be replaced.  I suspect I messed up some of these by eagerly trimming the RJ resistor legs.  

Good to know. Depending on the reflow temperature, the component might also be damaged that way.

 

7 minutes ago, TheMentat said:

Moving along, I've started mocking up the final assembly.  For some reason, plugging in the displays will not allow the SEQ to boot (the green LED on the SDcard module does not light).  This only occurs when I jumper J15_S.  I suspect a short somewhere on the power rail for the displays... sound right?

Always check for shorts! On experience this is typically caused by a bad cable or excess copper on the connector end shorting on the OLED PCB. Depending on when your parcel arrived Peter might have put a piece of kapton tape on the OLED. You can try with a piece of paper or tape.

Also check R33D on the Core is 560R.

[TheMentat]

Hey!  replaced the transistors, and sorted out the display power issues.  Moved on to upload the software as per the video, and ran into my next problem.  The file seemed to upload fine, but the device got hung displaying "BOOTLOADER MODE" or something for quite some time.  

 

With nothing left to do I unplugged it.  When re-plugging the USB, the MIDIbox only seems to blink the green LED a few times.  The red LED on the STMDiscovery also glows red.  I get nothing else, and MIOS Studio does not detect the device.

Any ideas?  Do I need to re-flash the boot loader?    What's the best way to do that?

 

Here are the logs:
 

Quote

 

[105084.804] [FILE] Uploading /MBSEQ_HW.V4 with 20385 bytes
[105085.201] [FILE] Upload of 20385 bytes in progress (50%)
[105085.468] [FILE] Upload of 20385 bytes finished.

 

Reading project.hex
Trying to contact the core...
project.hex contains 407732 bytes (1593 blocks).
Range 0x08000000-0x08003fff (16384 bytes) - BL excluded
Range 0x08004000-0x080638ff (391424 bytes) - STM32 Flash
Upload of 391424 bytes completed after 7.06s (54.13 kb/s)
1 ignorable errors during upload solved (no issue!)

 

 

 

[latigid on]

Did you restart MIOS Studio after updating? You say Discovery, but are you using one of those or a Waveshare 407v board? If it's the latter, what are the settings on the switches? What jumpers are present?

You can stuff the JPA0 jumper on the wCore board if you need to reflash from bootloader hold mode.

[latigid on]

And how was the display issue resolved btw?

[TheMentat]

1 hour ago, latigid on said:

And how was the display issue resolved btw?

Bad cable connector...or more accurately, bad connnector installation!

 

Edited September 11, 2019 by TheMentat

[TheMentat]

2 hours ago, latigid on said:

Did you restart MIOS Studio after updating? You say Discovery, but are you using one of those or a Waveshare 407v board? If it's the latter, what are the settings on the switches? What jumpers are present?

You can stuff the JPA0 jumper on the wCore board if you need to reflash from bootloader hold mode.

Thanks for the quick reply. BTW...

My bad,,, it is a waveshare.  I didn’t restart MIOS studio, but did rescan for devices.  It was working completely until I replaced the NG firmware  with the SEQ.

 

 

If I have to re-flash... do I follow the instructions for the stm32f4 on the ucapps website?

http://www.ucapps.de/index.html?page=midibox_seq.html

 

What is refflashing from boot loader hold mode?

 

Edited September 11, 2019 by TheMentat

[latigid on]

Try the boot config on flash. Also rescan devices in MIOS Studio normally doesn't work. At least for me I have to restart each time the MIDI device changes i.e. after each firmware update and reset.

Consider the following troubleshooting earlier in the thread:

 

Good luck!

[knochenfabrik]

@latigid on@Hawkeye Thanks for the input. My current situation is:

DOUT: Had the whole module working fine - suddenly from nowhere the 2nd LED began to blink randomly so i reflowed the whole PCB and now everything looks good and working as intended.

AOUT: After your first feedback I reflowed all the components you mentioned (IC4, 8RX, etc.) and to my surprise got channel 7 and 8 of the AOUT-module working fine. The other channels though didnt work as intended anymore and on J3 i measured pefect 5V on Pin 7,8. On the other pins i measure voltages from 3.6 (e.g. Pin 6)  to 5.7 (e.g. Pin 1) and most channels of the DOUT didntt work as intended when using to control a VCO. So I thought to myself lets reflow all the other ICs and important Rs and Cs aswell. The result is that channel 7 and 8 (which I havent even touched this time) dont work anymore but channel 1-7works fine now.

I still owe you a better picture with voltage information - but now that everything is twisted again I have to measure again and create a new picture :D

Edited September 11, 2019 by knochenfabrik

[TheMentat]

stuffing JPA0 worked... reloaded the software, and it boots normally now.  thanks for that!

Everything seems to be working now except for the LED matrix.  I suspect some bad cabling.  the "DEFAULT" marquee has a few glitchy rows, and the standard display screen is blank.  Stay tuned...

[TheMentat]

aaaaand it's done.

Big thanks to @latigid on for all of the troubleshooting help, and to all those that had a part in putting the package together!  Looking forward to diving in.

Cheers!  

 

[latigid on]

Woohoo!

If you wish you can post a picture in the main thread and claim your serial number :)

http://midibox.org/forums/topic/20885-midiphy-seq-v4/

 

[latigid on]

Hello, I can't offer much help because I can't quite understand the things I've highlighted in bold. If you can clarify those points I'll do my best.

17 hours ago, knochenfabrik said:

@latigid on@Hawkeye Thanks for the input. My current situation is:

DOUT: Had the whole module working fine - suddenly from nowhere the 2nd LED began to blink randomly so i reflowed the whole PCB and now everything looks good and working as intended.

Great!

 

17 hours ago, knochenfabrik said:

AOUT: After your first feedback I reflowed all the components you mentioned (IC4, 8RX, etc.) and to my surprise got channel 7 and 8 of the AOUT-module working fine. The other channels though didnt work as intended anymore and on J3 [on transmute8?] i measured pefect 5V on Pin 7,8.[with or without a working superDAC PCB connected? +5V or -5V?] On the other pins i measure voltages from 3.6 (e.g. Pin 6)  to 5.7 (e.g. Pin 1) and most channels of the DOUT didntt work as intended when using to control a VCO. So I thought to myself lets reflow all the other ICs and important Rs and Cs aswell. The result is that channel 7 and 8 (which I havent even touched this time) dont work anymore but channel 1-7works fine now.

I still owe you a better picture with voltage information - but now that everything is twisted again I have to measure again and create a new picture :D

At a guess, the problem might lie with IC4 as it processes channels 7+8.

[puristin]

Hi all,

I have been troubleshooting my build now for a while without any result, so it is time to ask some help.

I have verified that the Core is working. I believe that my JA board is also working; all buttons give an event, all leds are working and encoder gives MBNG_DIN_NotifyToggle events (rotation and push).

When connecting Core -> JA -> LEMEC-LH -> LEMEC-RH, and testing LEMEC boards with seq_l script, I only get ENC events from encoders. None of the push buttons (encoder push function, Matias, or MECs) work on the LEMEC boards (LH or RH).

So far I have verified that ICs and transistors are correct type, checked orientation of all diodes and ICs, reflowed all IC legs, and inspected visually possible shorts between IC legs, and made sure PLATE board is not touching LE-MEC board. I have also tested my cables. All of this without any luck.

Any ideas, where to look next?

[latigid on]

Photos of the rear of the PCBs would be good. Did you measure any input with set debug on? 

Try connecting only JA and test with seq_l. Try connecting only lemec_l and test with seq_r. 

[puristin]

2 hours ago, latigid on said:

Photos of the rear of the PCBs would be good. Did you measure any input with set debug on?

Try connecting only JA and test with seq_l. Try connecting only lemec_l and test with seq_r. 

When debug is set on, I do not get anything on MIOS terminal from LEMECs other than encoder rotation events.

When connecting only JA: all buttons work, encoder gives events from rotation and clicking.

When connecting LEMEC_LH and loading seq_r, no other events than encoder rotation are shown in the MIOS terminal.

Here are photos of LEMEC PCBs, hopefully they are clear enough.

[latigid on]

How are your 10-pin resistor networks oriented? The 74HC165 inputs of IC3 should be at about +5V

You haven't soldered the switches in, so are you confident that you are properly closing the switch pads? Maybe try to bridge them with metal tweezers or similar. Make sure set debug on is active.

You should be able to control the 74HC595 pins (or resistors R1-8 from the MIOS terminal with set dout x 0|1. Each 595 has 8 outputs so IC2 is 24-31 for _R and 0-7 for _L. During normal running of the (correct) .NGC you should measure some voltage on the pins of IC2, which controls the sink driver transistors.

 

[puristin]

10-pin resistor networks are oriented so that the dot marked on the part is on filled square on the PCB. This should be correct orientation.

IC3 (74HC165) input pins are +4.75v.

I retested Matias switch pads with metallic tweezers (I was using previously short wire). This time also there was no events on terminal for LEMEC_LH, however, for LEMEC_RH I got a few random burst of button events which I could not reproduce from the same switch (eg. one burst of hw_ids 81,91,92,105,109,120).

IC2 (74HC595) outputs on LEMEC_LH and LEMEC_RH are 0v even after trying to set the high with set dout command (command ran after seq_l has been loaded). VCC of IC2 pin is getting +4.75v.

Edited September 15, 2019 by puristin

[latigid on]

That's the correct orientation for RNs.

I think the set dout command should still work after an .NGC is loaded. If you can't set the DOUT pins, then the sink side (cathodes) of your matrix don't work. As the behaviour is common to both boards, my guess is that there is an issue on the Core or one of the connecting cables.

Check IC1B pins 4/5/6 (4=0V, 5=buffer output, 6=buffer input for SO) and back to PB15 on the MCU. It could be a soldering issue with the J8/9 header, the IC or that the header pins don't make sufficient contact to the female connector or similar.

Check IC1B, pins 11/12/13 (RC1) and back to PB12 on the MCU, though the shift in should still occur on the RC2 pulse, which from your working encoders suggests that part of the SRIO chain is functional.

 

[puristin]

I finally managed to get all switches working. Great thanks for all the guidance during the bug hunt, it is highly appreciated!

I was reflowing all the connectors in SRIO chain, and checking all connections with a multimeter. While doing that, I noticed that J89 on LEMEC_LH board had a short between bottom-right pin and third pin from top on right column. There is a narrow trace going between that third pin to plated through hole under J89. For some reason, a bit of coating was missing near that plated hole, and minimal contact was made to the corner pin. I had before visually inspected the area and checked for shorts only between adjacenting pins without reading actual traces in the PCB :/