Subversion Repositories svn.mios

Rev

Rev 338 | Go to most recent revision | Blame | Compare with Previous | Last modification | View Log | RSS feed

HEADER 3 MIDI Interface Troubleshooting

<H1>MIDI Interface Troubleshooting</H1>

<P CLASS=INFO><I>This page has been written for troubleshooting a core module stuffed with a PIC18F452. For old PIC16F projects see <A HREF="howto_debug_midi_pic16f.html">this page</A></I></P>

<P CLASS=INFO>A proper link to your computer is essential for a successful upload of MIOS and MIOS applications, since these programs cannot be uploaded via a PIC programmer, but only via the MIDI interface. Once the bootstrap loader has been burned into the chip, you can put the MBHP_BURNER aside and should focus on getting the MIDI interconnection running.</P>

<P CLASS=INFO><B>NEWS:</B> MIOS Studio simplifies the upload of MIOS code. This guide still references the use of MIDI-Ox, this will be changed in future. Please try MIDI-Ox as well as MIOS Studio.</P>

<P CLASS=DESC>The bootstrap loader sends an upload request after power-on:<BR>
<CENTER><IMG SRC="howtodebug/upload_request.gif" alt="" width=240 height=76></CENTER><BR>
It's some kind of "sign of life" from your PIC. So long as MIOS isn't available, this request will be sent periodically every 2 seconds, otherwise it will only be sent once.</P>

<P CLASS=DESC>If this request message doesn't appear, you should first ensure that the most important parts of your core module are soldered properly:
<UL CLASS=CL>
   <LI><B>TEST PROG1:</B> If you are not sure that the bootstrap loader has been burned successfully, use the verify function of IC-Prog/P18</LI>
   <LI><B>TEST CORE1:</B> ensure that you've stuffed a 10 MHz crystal (parallel cut) to your PIC18F core module</LI>
   <LI><B>TEST CORE2:</B> only relevant for MBHP_CORE_V1 and MBHP_CORE_V2 PCB: are <A HREF="mbhp/mbhp_core_5.jpg">all 5 jumpers</A> connected to the programming port?</LI>
   <LI><B>TEST CORE3:</B> Check it visually for bad solderings or missed junctions</LI>
   <LI><B>TEST CORE4:</B> Check Vdd of the power supply like shown here: <A HREF="howtodebug/mbhp_core_extract_measuring_vdd.gif">mbhp_core_extract_measuring_vdd.gif</A></LI>
   <LI><B>TEST CORE5:</B> Check the ground of the power supply like shown here: <A HREF="howtodebug/mbhp_core_extract_measuring_gnd.gif">mbhp_core_extract_measuring_gnd.gif</A></LI>
   <LI><B>TEST CORE6:</B> Check the polarity of your MIDI plugs: <A HREF="howtodebug/mbhp_core_extract_midi_plugs.gif">mbhp_core_extract_midi_plugs.gif</A></LI>
   <LI><B>TEST CORE7:</B> Check the polarity of the protection diode D1: <A HREF="howtodebug/mbhp_core_extract_d1.gif">mbhp_core_extract_midi_d1.gif</A></LI>
   <LI><B>TEST CORE8:</B> Check the resistor values at the MIDI Out Port: R8 and R7=220 Ohm (resistor code: red-red-brown)</LI>
   <LI><B>TEST CORE9:</B> Just to ensure: this diagram shows a crosslink between the core module and your PC: <A HREF="howtodebug/mbhp_core_midi_crosslink.gif">mbhp_core_midi_crosslink.gif</A></LI>
   <LI><B>TEST CORE10:</B> If you notice a lot of request messages like shown in <A HREF="howtodebug/rxtx_feedback.gif">this snapshot</A>, then there is a short circuit between the Rx and Tx pin of the PIC. Check the tracks which are routed from the MIDI-Link port J11 to the Rx/Tx pins for direct connections (see the <A HREF="mbhp/mbhp_core.gif">layout</A> and <A HREF="mbhp/mbhp_core.pdf">schematic</A>), you could scratch with a screw driver between the tracks to ensure that they are not connected together.</LI>
   <LI><B>TEST CORE11:</B> The code upload can also fail if no, or a too small bypass cap is connected to the power rails of the PIC. A possible effect is, that for example "F0 F0 F0 F0 7E F0 00 01" will be sent by the PIC instead of the proper SysEx string "F0 00 00 7E 40 ... F7". Another effect could be, that something is received by your MIDI interface, but not displayed by the MIDI monitor because of the invalid MIDI event structure. This all can happen even when the IO and Software loopback test which is discussed below is passing,<BR>
If this happens, check that the 2200 uF cap (C5 of the core module) is soldered properly. If you are unsure about the state of the cap, since you've re-used it from an old device, try another one.<BR>
If you are using the optimized PSU for MIDIbox SID, bypass the outer pins of the (not mounted) 7805, so that C5 has contact with the +5V/Ground rails (see also <A HREF="mbhp/mbhp_4xsid_c64_psu_optimized.pdf">mbhp_4xsid_c64_psu_optimized.pdf</A>)!</LI>
   <LI><B>TEST OUT1:</B> Connect a LED to your MIDI Out port and check if it flickers: <A HREF="howtodebug/mbhp_core_extract_out_led.gif">mbhp_core_extract_out_led.gif</A></LI>
   <LI><B>TEST OUT2:</B> Somebody noticed in the forum, that the MIDI Out of his core module didn't work because of an "incompatibility issue" with the bench supply he used and the switching PSU of his PC. The solution was to disconnect the middle pin of J12 (ground line of MIDI Out port)</LI>
</UL>


<P>This should help to locate the problem on the core module site.</P>

<P CLASS=INFO>At the PC site:<BR>
<UL CLASS=CL>
   <LI><B>TEST PC1:</B> check the MIDI-Ox configuration - <A HREF="mios/bootstrap_sysex0.gif">have you select the correct ports?</A></LI>
   <LI><B>TEST PC2:</B> ensure that the MIDI interface of your computer is working: loopback the MIDI Out of your PC to the MIDI In of your PC and send any SysEx dump by using the "Send/Receive SysEx" function of MIDI-Ox. The number of sent bytes must match with the number of received bytes. If it doesn't match, search for a new driver for your MIDI interface/sound card. If not available, you can possibly fix this problem by lowering the Low Level Output Buffer size (normaly set to 2048) and by increasing the output delay (normaly set to 0 ms) in the <A HREF="mios/bootstrap_sysex1.gif">MIDI-Ox SysEx configuration menu</A></LI>
</UL>

<P CLASS=INFO>I assume that you do see the upload request string now. Try to upload MIOS, the core should reply with an acknowledge message after every uploaded block like shown here:<BR>
<CENTER><IMG SRC="howtodebug/upload_acknowledge.gif" alt="" width=243 height=175></CENTER><BR>
<B>Note:</B> the checksums will differ depending on the program.</P>

<P CLASS=INFO>If nothing happens, your MIDI-In is possibly not working:<BR>
<UL CLASS=CL>
   <LI><B>TEST IN1:</B> Check the resistor values at the MIDI In Port: R11=220 Ohm (resistor code: red-red-brown), R6=1.2kOhm (brown-red-red), R5=5.6kOhm (Green-Blue-Red).</LI>
   <LI><B>TEST IN2:</B> Check the polarity of your MIDI plugs again: <A HREF="howtodebug/mbhp_core_extract_midi_plugs.gif">mbhp_core_extract_midi_plugs.gif</A> - maybe the two pins of the MIDI In port are swapped?</LI>
   <LI><B>TEST IN3:</B> solder two cables to the bottom side of the core module like shown in <A HREF="mbhp/mbhp_core_midiin_debug.gif">mbhp_core_midiin_debug.gif</A>. The LED should lit (take the polarity of the LED into account, the short leg is the cathode and has to be connected via a resistor to Vss). So long as single MIDI events are received, you won't notice a difference, but with a continuous SysEx stream the LED should begin to flicker.<BR>
<B>Note:</B>so long as the LED is connected directly to the Rx pin, the PIC will *not* receive the MIDI data due to the power consumption of the LED. This method is only usefull to test if the MIDI signal is available at the Rx pin.</LI>
   <LI><B>TEST IN4:</B> if the LED doesn't lit, connect the anode to the optocoupler (Pin IC2:6). If it still doesn't lit, connect the anode with the +5V rail of the optocoupler (Pin IC2:8)</LI>
   <LI><B>TEST IN5:</B> If this doesn't help you to detect the error, continue with the next step - see <A HREF="mbhp/mbhp_core_midiin_debug2.gif">mbhp_core_midiin_debug2.gif</A> -  in this configuration the LED should only lit when MIDI data is received. Than more MIDI events are received a time, than brigther the LED. If the LED doesn't lit, check the polarity of the protection diode D1 before the optocoupler (again...). Also check the polarity of the MIDI cable (again...).</LI>
   <LI><B>TEST IN6:</B> Standalone test for the optocoupler: <A HREF="howtodebug/mbhp_core_extract_opto_test.gif">mbhp_core_extract_opto_test.gif</A></LI>
   <LI><B>TEST IN7:</B> A second standalone test for the optocoupler, this time the optocoupler isn't plugged in the core module: <A HREF="howtodebug/mbhp_core_opto_test.gif">mbhp_core_opto_test.gif</A></LI>
   <LI><B>TEST INOUT1:</B> final check to ensure that all 4 MIDI ports are working: put the PIC out of the socket and loopback the MIDI IO ports at the Rx/Tx pins like demonstrated in <A HREF="howtodebug/mbhp_core_extract_io_loopback.gif">mbhp_core_extract_io_loopback.gif</A>. Send any SysEx dump by using the "Send/Receive SysEx" function of MIDI-Ox. The number of sent bytes must match with the number of received bytes.</A></LI>
</UL>

<B>Disconnect the LED after the tests, otherwise the PIC won't receive MIDI data!</B>.</P>

<P CLASS=INFO>Additional software checks:<BR>
<UL CLASS=CL>
   <LI><B>TEST SW1:</B> The bootstrap loader is normaly sufficient for MIDI In and Out Port checks, but under special circumstances an alternative firmware makes sense to get a better understanding about the root cause for a non-working code upload.<BR>
The <A HREF="mios/sw_loopback_test.zip">software implemented loopback test</A> is a .hex file can be programmed directly into the PIC.<BR>
Connect the MIDI OUT of your MIDIbox with the MIDI IN of your computer and the MIDI IN of your MIDIbox with the MIDI OUT of your computer. Turn on your MIDIbox. Activate the virtual MIDI Keyboard in MIDI-OX. Press some keys (Q-W-E-R-T-Y...) and check the messages in the MIDI-OX window. If you only see the KEYBOARD events, the RxTx firmware doesn't forward the incoming MIDI bytes to the MIDI out. If you see a lot of messages after typing once the keyboard, you possibly have a MIDI feedback loop (check the MIDI Port menu). If you see the messages like on <A HREF="howtodebug/midibox_debug_rxtx.gif">this picture</A> (every event twice), the MIDI In- and Out port is working.<BR><B>Note:</B> newer MIDI-Ox releases provide a seperate input and output window.<BR><B>Note2:</B> the RD4 pin (CORE::J14) toggles on each incoming MIDI byte, this is a nice additional debugging help.</LI>
   <LI><B>TEST SW2:</B> (only relevant if you've programmed the bootloader with your own PIC programmer): some PIC programmers are not able to modify the ID field, which specifies the MIOS device ID, the LCD type and especially the to-COM option (alternative baudrate). This wouldn't be a problem so long the ID is completely zero (common case), but unfortunately the ID field is FFFFFFFFFFFFFFFF by default. <A HREF="mios/mios_bootstrap_picstart_workaround_v1.zip">This program</A> fixes the ID field, details are described in the main.asm header</LI>
</UL>

<P CLASS=INFO><B>Sidenote:</B> if you own a <A HREF="mbhp_ltc.html">MBHP_LTC</A> module, debugging with a LED will be easier since the LEDs are buffered and therefore don't have to be disconnected when communicating with another MIDI device.</P>

<P CLASS=INFO>If these tips don't help, it cannot be excluded that the MIDI interface of your PC doesn't work. Especially gameports are sometimes not reliable - mostly because of a driver issue or wrong BIOS settings (IRQ enabled?). Some soundcards are shipped with a buggy driver, which has to be updated (e.g. Soundblaster Audigy, SEK'D Prodif, ...). Cheap MIDI adapters without optocoupler mostly don't work, in this case it's better to make a 1:1 connection via the MIDIbox Link port of your core module like shown in <A HREF="mbhp/mbhp_midi_gameport.gif">mbhp_midi_gameport.gif</A>.</P>

<P CLASS=INFO><B>Good Luck!</B></P>

FOOTER