LPC17 MIDI out trouble

Testing/Troubleshooting
1

hi all,

 

this is my first post so first i would like to say hello,

 

and then immediately ask for help :slight_smile:

 

the problem is, MIDI OUT is not working on my CORE_LPC17.

 

i’ve built the CORE_LPC17 module and got USB and MIDI IN working,

i.e. i was able to install the bootloader via USB, and then the MIDIBOX_NG

application. commands in the MIOS Studio terminal work fine.

 

i tested the loopback as described on the MIDI troubleshooting page, and

it works if i take out the LPC17 and short RX and TX via a jumper directly

at the LPC socket (i installed female headers).

so it looks as if there is no problem with the circuitry between the MIDI socket

and the female headers…

 

MIDI in works correctly with the LPC installed, if i send MIDI commands to MIDI IN

i can see them via USB on the terminal in the midi monitor.

 

but MIDI out does not work, there is no data transmitted.

 

i put a LED against the MIDI out socket, and it flickers only briefly directly

after power-up (i think no data is transmitted at that point)

 

if i measure the voltage directly on the TX pin on the LPC board, it seems to

be constantly at 5V…

 

any ideas how i can proceed further?

 

thanks!

 

 

2

Hi,

 

welcome on board! :smile:

 

if i measure the voltage directly on the TX pin on the LPC board, it seems to

be constantly at 5V…

 

This surprises me, because I would expect 3.3V here

Are you sure that it’s 5V? Then it very likely related to an unintended bridge on the board, e.g. caused by a big soldering blob between the Tx track and a 5V track.

 

Best Regards, Thorsten.

3

hi thorsten,

sorry, i measured again more carefully this morning, and counted the pins more carefully.
so, with the USB plugged in i measure 5V on P2.1/RXD1 and 0V on P2.0/TXD1
(also i checked P0.1/RXD3 and P0.0/TXD3 and get also 5V and 0V respectively).
the voltage directly at the MIDI socket is 3.3 V at J12 and J20
(between middle/GND and square via / middle left pin of socket in rear view).
this confuses me a little since according to the schematic i would expect 3.3V on the right side (M+).

these voltages are the same with and without the ICs (IC1,IC2,IC4,IC5, LPC17) or jumpers (apart from J17) in their sockets.
to me the soldering looks clean, all blobs look concave, shiny and covering just the pad …
and i also thoroughly cleaned the board with alcohol
(if it is possible to attach images here i could attach a picture of it?)

do you have further ideas of points where i could measure to find a short if there is one?

thanks,
Gerhard

4

 i measure 5V on P2.1/RXD1 and 0V on P2.0/TXD1

 

RXD = 5V: confirmed

TXD = 0V: very strange, it should be ca. 3.3V when no MIDI data is sent

 

It’s especially strange that you measure 0V at both TXD pins (the same soldering error twice - very unlikely?)

 

(if it is possible to attach images here i could attach a picture of it?)

 

yes, just click on the “My Media” button (right after the smilie)

 

 

do you have further ideas of points where i could measure to find a short if there is one?

 

Could you please check the voltage at the remaining two TX pins?

MIDI OUT3: J5B.A7 (LPC1769 pin P0.2)

MIDI OUT4: J4B.SD (LPC1769 pin P0.11)

 

And: are you sure that the application is running?

E.g. is the query in MIOS Studio working? Does it return “MIDIbox NG V1.xxx”?

 

Best Regards, Thorsten.

5

 

hi thorsten,

 

the voltages i mentioned above were measured without and IC or the LPC inserted.

when i insert everything an run normally, i get 3.3V at all four TX pins - as expected.

 

i am 100% sure the LPC17 runs MIDIBOX_NG correctly, i can communicate via terminal

and also have an LCD attached. when i switch on the MIDI monitor i can see MIDI sent

to MIDI_IN1 via USB on the terminal.

Only MIDI_OUT is not working…

 

for good measure i reflowed now almost all solder points (that were connected to something),

images are attached.

 

thanks!

gerhard

<___base_url___>/gallery/image/2230-2014-01-20-155425/?do=embed

<___base_url___>/gallery/image/2229-2014-01-20-155350/?do=embed

6

Hi Gerhard,

 

how do you test the MIDI OUT, resp. how are you generating the MIDI messages?

By default (if no control element is connected), no data will be sent to the MIDI OUT ports.

 

You could enable message forwarding from USB with following terminal command:

set router 1 USB1 all OUT1 all

Then play some keys on the virtual keyboard of MIOS Studio -> MIDI OUT1 should output MIDI note messages.

 

Best Regards, Thorsten.

7

Hi Thorsten,

 

I’m a little confused now that you say by default no data are sent to MIDI OUT?

It was my understanding that it should be possible by default to communicate with the CORE_LPC17

via the MIDI ports only, and use USB only for power? it is written everywhere in the instructions

that MIDI can be used to upload MIOS32 etc… so i thought for this data have to go through MIDI IN and OUT

by default already when the bootloader runs?

 

I did your routing suggestion and indeed a few occassional bytes are being sent to MIDI OUT now, so a little bit

of progress :slight_smile:

but the data are not the notes sent from the virtual midi keyboard, only very few bytes arrive, mostly FF and FC,

not complete and correct MIDI messages.

 

i see two possibilities now, either it looks like the path to the MIDI port might be buggy but then it is strange why

the loopback test (shorting RX and TX) worked just fine.

 

second, the LPC does not send MIDI OUT messages correctly (due to hardware issue on the LPC board,

or due to a MIOS software issue that has for some reason not been seen yet…)

can i somehow read the MIDI messages directly at the TX pins?

 

thanks,

gerhard

8

Hi Gerhard,

 

the reason why I came to the idea that you are testing the MIDI OUT wrongly was simply because you haven’t described how exactly you are testing the MIDI OUT port.

It was the only conclusion at my side.

Especially since you wrote “but MIDI out does not work, there is no data transmitted.”

 

I’m pretty sure that this is not related to a software issue, maybe only due to a configuration problem (like if you would assume, that USB transfers would be forwarded to a MIDI port w/o special app configuration)

 

 

Ok, next experiment (unfortunately again you haven’t described *all* details, e.g. which MIDI interface you are using to test the OUT port, therefore I hope that following test won’t confuse you again - just trust my guidance… :wink:

What happens if you loopback MIDI OUT1 to MIDI IN1, and configure the MIDI router the following way:

set router 1 USB1 ALL OUT1 ALL
set router 2 IN1 ALL USB1 ALL

I expect, that every MIDI note that you are sending with the virtual keyboard will now be sent back by the core due to the MIDI loopback.

Accordingly, the MIDI IN Monitor of MIOS Studio should show the same events like the MIDI OUT monitor.

 

Best Regards, Thorsten.

9

hi thorsten,

Ok, i will do this routing test a bit later, but i can immediately explain my setup to you in more detail,

sorry for assuming this was unambiguous, you are of course right it is not …

I have a laptop (Apple MBPr with Mavericks) with a USB cable in one USB port going to the USB port in the CORE_LPC17,
and a USB-MIDI cable (Roland UM-1) in the other USB port going to the CORE_LPC17 MIDI_IN1 and MIDI_OUT1 sockets.

all ports (MIOS32, and UM-ONE, respectively) are correctly recognized by MIOS studio and other MIDI monitor applications

running on the computer.

when i set the in/out ports in MIOS Studio to “MIOS32” (the MIDI port assigned to the USB cable),
the LPC17 is correctly recognized and communication is possible.

when i send MIDI data from another virutal keyboard to the UM-ONE, i can see it in the LPC17 terminal on IN1.

when i set the in/out ports in MIOS Studio to “UM-ONE” (the MIDI ports assigned to the Roland UM-1 interface) no communication is possible anymore.

this is how i conclude only the MIDI OUT is not working.

 
for the previous (hardware) loopback test i removed the CORE_LPC17 and shorted the pins in the empty female headers.

this worked.

 

i’ll write again once i did your suggested routing loopback test.

 

thanks,

Gerhard

10

Hi Thorsten,

 

Further test results:

 

  • Your proposed loopback test works (routing USB1 –> OUT1 –> cable –> IN1 –> USB1) : more progress :slight_smile:

 

  • I also tried to just route USB1 –> OUT1 (leaving IN1–>USB1 open) with the same loopback cable to IN1

  and can see the events come back via IN1 in the midimon in the terminal

 

  • These tests I repeated with permuting the cables between IN1/2, OUT1/2 and got the expected results in each case

 

–> the LPC17 seems to be able to talk to itself just fine

 

  • I repeated the “jumper” loopback test (taking out the LPC17 and shorting Rx/Tx  on both with two different MIDI interfaces
      (the Roland cable and a no-name cable), it also works flawlessly 

 

–> the Mac seems to be able to talk to itself just fine, and going through the octocouplers etc also seems to work

 

now, what does not work is any test that sends MIDI data via IN1/2,OUT1/2 between the Mac and the LPC17.

some data do get transmitted, but they are wrong and incomplete, bytes get lost. i see that in the MIOS midi monitor

and on third-party midi monitors.

 

from these tests i conclude there might be a problem in synchronizing the

communication between the Mac and the LPC17,

perhaps the MIDI baud rate is not set correctly, or something like that… ?

 

thanks,

 

Gerhard 

11

perhaps the MIDI baud rate is not set correctly, or something like that… ?

 

It can’t be changed by the user without recompiling the application, therefore very unlikely.

And LPC17 wouldn’t be able to receive MIDI messages from your Roland UM1 if the baudrate would be wrong.

 

 

from these tests i conclude there might be a problem in synchronizing the

communication between the Mac and the LPC17,

 

I think that it it’s neither a synchronization, nor any other software issue.

 

It seems, that your Roland UM1 interface can’t handle MIDI signals at 3.3V level correctly.

There is a small number of MIDI devices where this is the case, they are designed for 5V signals, but LPC1769 (like many other modern microcontrollers) can only supply 3.3V.

 

Therefore the next test: try another MIDI device.

If it works, then we can start to think about workarounds for your Roland UM1 (e.g. usage of a level shifter).

 

Best Regards, Thorsten.

12

Hi Thorsten,

 

I tried with another MIDI Interface (Prodipe 1in/1out) which exhibits the same problematic behaviour.

Also, I tested MIDI loopback with another device (Mutable Instruments MIDIpal) which also

includes a MIDI monitor and MIDI thru feature and it works just fine with both interfaces, the Roland

and the Prodipe.

(Not sure if the MIDIpal uses a 5V signal on the output though…)

 

Another thing i googled is that apparently many MIDI interfaces still have problems with MacOSX Mavericks

since it is quite new.

however, since i tried with two different MIDI interfaces, and I have no problems with the MIDIpal (or any

of my other synthesizer I connected previously) I doubt it is a driver issue.

 

I am therefore ready to try your level shifting idea :slight_smile:

 

Thanks,

Gerhard

13

Hi! 

I was having the exact trouble Gerhard describes. 

USB is/was working perfectly. But when powered from a wall-wart with a MIO iConnect the MIOS Application is not recognized, MIDI In works fine, but MIDI Out does not work at all.

When I switched interfaces to my Scarlett 2i4 everything works perfectly.

 

The thing that threw me off track is that the MIO iConnect plays perfectly with my sammichFM (among others), so I didn’t stop to consider that the interface was the issue- I assumed my soldering skills were at fault. Apparently it is one of these interfaces that does not recognize 3.3v, only 5v that TK describes.   

 

I’ll update the white and blacklist with my findings. 

Best of luck Gerhard!!

 

-dugan

14

Before trying to level shift the Tx signal (which involves some soldering work and an additional IC, such as a 74HCT541), following experiments would be interesting.

 

  1. connect your MIDI synthesizer to MIDI OUT1 - are you able to play notes?

 

  1. connect your MIDI Pal between MIDI IN1 and OUT1 - does it show the outgoing MIDI data, and is MIDI loopback working?

 

  1. and now the trick: bridge R21 (a 220 ohm resistor) with a small cable so that it doesn’t limit the current draw anymore.

Together with R22 (the second 220 ohm resistor which shouldn’t be bridged (!) to prevent a short circuit between ground and 3.3V while plugging in the cable), this should result into a current draw of ca. 7.5 mA, which is still close to the MIDI spec, but might help in your case.

 

Background: actually the MIDI spec says, that the current loop requires about 5 mA. Assumed that the MIDI Out has two 220 Ohm resistors in serial, and the MIDI IN of the target device has a single 220 Ohm resistor as well, this results into exactly 3.3V / 3*220 Ohm = 5 mA

However, some interfaces might have a poorly designed MIDI IN circuit, so that this is not enough to drive the optocoupler.

 

@Dugan: could you please also check if 3) solves the issue at your side?

 

If this solves the issue, I will document the workaround at the MBHP_CORE_LPC17 page.

Fortunately with the STM32F4 core it will be possible to use the Tx pin in Open Drain mode again, so that MIDI OUT can be supplied at 5V and therefore no adaption issues can be expected (due to a hardware imperfection in the LPC1769 chip this isn’t possible).

 

Best Regards, Thorsten.

15

I was just about to suggest this to.  Running the Midi OUT with only 3.3v you would suspect that these 220 ohm resistors would need to be changed. I’ve questioned this for a year or more but nobody was reporting any issues. 

 

Edit: TK - on your calculations you forgot to subtract the forward voltage of the receiving diode which is 1.7v max at only 1.6ma.  So the voltage is really 1.6 volts, not 3.3v.

16

TK (and Gerhard!),

 

I removed R21 and installed a bridge and the MIO interface now communicates with MIOS Studio exactly as it should.

Thanks!

1 Like
17

Hi Thorsten,

 

First i would like to report that also for me the LPC17 communicates normally if i bridge R21 :slight_smile:

 

Thanks for all the help!

 

I guess I have to also bridge R26 to get OUT2 working?

 

Second, i did the tests you requested (before bridgeing):

 

  1. Connecting a synthesizer (Korg EM-1, not really a synth but a fairly standard toy…) works,

    in both directions

 

  1. loopback through MIDIpal works even with R1 in - looking at the MIDIpal PCB it has written 3.3V all over it,

    so i’m guessing its also 3.3V. i can see two 220 Ohm resistors close to the 6N138. not sure about the acutal

    schematics because Olivier has taken them down i think, but probably MIDIpal is prepared for 3.3V operation

    so that could explain the success.

 

so, it looks as if only the connection between the Roland and Prodipe USB-MIDI interfaces did not work.

last test i did before soldering in the bridges is to test the Roland in “iPad mode” (a small switch on the cable) …

i thought this maybe switches the device to lower currents/voltage, but it didn’t work

 

Thanks again, I’m happy to finally have learned more about MIDI :slight_smile:

 

Gerhard

 

 

18

I’m glad you got yours working, too Gerhard!

It’s a testament to TK’s incredible knowledge that he solved this issue with conjecture alone. 

 

You and I should update the wiki’s blacklist and/or whitelist with our interfaces so the next cats who come upon this are less blind than we were. -I think TK is going to update the LPC17 page to indicate that some USB/Midi interfaces will behave better with the workaround he provided. 

 

Just to confirm against better minds than my own: Removing the 220 Ohm resistor only adds ca. 2.5mA to the Midi Out signal path and should not be deleterious to most/any equipment connected to it, correct?

 

Thanks!!

dugan

 

EDIT: Gerhard- The kludge is only so that your Midi/PC interface works with your PC & MIOS Studio… You only need to bridge R26 if (for some weird reason) your Midi Out isn’t working with your other Midi hardware… in my case Midi Out always worked with my midi hardware, just not with MIOS Studio. …If it is confirmed (by folks smarterer than me) that there is nothing deleterious about removing R26 (&r21) you can if you like, but I see no reason to do so if it’s communicating with the equipment that you want it to. You already have MidiOut 1 & USB to talk to MIOS Studio, there’s no reason to have 3 ways of getting Midi Out messages to MIOS Studio… I think…

 

TK (or another genius): The R21 / R26 resistors are only there to rectify the signal to ~5mA if the initial voltage was 5v, right? 

Cheers! 

19

Hi Dugan,

 

good point. it’s true that all devices i tested with the second port worked apart from the PC so i’ll leave R26 in for now.

perhaps a flexible solution would be to include a jumper on future revisions of the CORE_LPC17 board

in order to short R21/R26 if neccessary for the particular users setup.

 

Cheers,

Gerhard

20

My guess what TK proposed is not going to be the final fix. It was just to see if it solved the problem.

 

The three 220 ohm resistors in the transmit and receive sides are put in circuit so that plugging the wrong equipment into any of the Midi ports wouldn’t destroy equipment at either end.

 

The Midi spec indicates a 5ma current loop. This current is achieved by the 3-220 ohm resistors in the loop and the +5v supply voltage with an assumed voltage drop of 1.7v across the receiving opto-isolator. With a 5 volt source you get 5v-1.7v/3-220 ohms = 5ma. With only a 3.3v source from the LPC unit, this current is reduced to 3.3v-1.7v/3-220 ohms = 2.42ma which is less than half that it should work with.

 

I believe that the 2 resistors on the Midi Out port should not be bypassed, but changed to a value of 47 ohms. This would give 3.3-1.7/(47+47+220) = 5.09ma. My opinion is that these 47 ohm resistors are a little lower than what I would want for protection but they still provide some protection and still gives enough current to meet the spec. We will wait and see what TK’s final approach will be.

 

Pete