Unable to upload anything !!

Testing/Troubleshooting
1

Hello everybody !! Let’s get direct : I’m planning on burn it all and go buy a real, good-working MIDI controller.

No, just kidding, love DIY too to give up that silly way… But I knew I had to be stuck one day, this day has come.

Already tried many times to search for someone having my problem … Please don’t hesitate to indicate me any post I could possibly have missed …

Here’s the plot : my first attempt was a total failure. I purchased a virgin 18f452, then asked a friend of mine possessing a PIC burner to burn the bootloader on it. Back home, I happily saw the sysex messages every two seconds, then tried to upload MIOS, then … things began to get messy. First, it failed, so, passing out all the good advices TK and others patiently gave to noobs like me, I tried whatsoever, like unticking or ticking every options that could possibly be, I didn’t know at all what I was doing but did it anyway, until that - I don’t really know how - MIOS seemingly came on the PIC, since from that moment, I only had the (good) sysex string on startup. I must mention, it was absolutely not obvious that I had to care on my PIC id number, which was curiously 70 and not the 00 expected (already saw it in a post, and confirm it should be put in FAQ - anyways it solved this guy’s problem, not mine :frowning: ) .

Well, after that, totally unable to upload any hex file.

I first thought I had my PIC f**** up because of my newbie’s eagerness, plus, I found bizarre that its ID was 70. And I made many random manips, such as wildly (and dumbly) unplugging the pic, and so on in that kind of ABSOLUTELY MUSTN’T-DO stuffs… Thought I really killed him. I so decided to calm down and patiently wait for another pic from smash TV, with already bootloader and mios on it, in order not to have to burn it by myself and just to be sure that things had this time been well done.

Now, I received this piece of wonder, then re-checked for the millionth time my core breadboard (which had been meanwhile covered by dust), basic hardware tests passed OK again, brand new pic stuffed in and …

I receive the correct sysex string in both midiox and miosstudio (with this time ID 00). And I actually have the same problem than before : trying to upload a basic test application (compiled with sdcc under code::blocks - a simple code that is supposed to send midi cc#1 at channel one only when I turn the pot on PIN1), the upload request is received as expected, but then miosstudio tries to upload the first block and … nothing more happens till I stop the process (yet I gave him a chance, waiting for an afternoon or so ^^).

Looks like that :

The reboot request will lead to an error acknowledge, please ignore!

Waiting for upload request…

Received Upload Request

Sending block #1 00000000-000000FF

I don’t think it’s useful, but I join both my codefiles and hex (made for a pic18f452 - character lcd displaytech 162c, 16x2 - no AIN module, pots directly connected on analogue input pins of the pic - DOUT and DIN both with 3 SR, but left apart for the test app). Anyways, it doesn’t work with any other hex file.

As I mentioned, I received the sysex string : F0 00 00 7E 40 00 01 F7 on startup. Though, The loopback test of gm5 doesn’t work (although I checked with an oscillo at school : data are transmitted from the pc, as a led placed between gm5:out pins indicates, and when I applied a square wave on GM5:in, I received a lot of midi events, which seems to prove that my g35 is actually working - so why the loopback test doesn’t work ?) - I tried “lowering the Low Level Output Buffer size (normaly set to 2048) and increasing the output delay” in midiox. Successless.

Datas are actually transmitted by the pic, as the test out1 and the gm5 led both indicate, and moreover I do receive the correct sysex string at startup.

Just to be sure, before test PC1 I just selected for both send and receive, the gm5 midi port 1 ; after, I selected all the five ports, it didn’t work anyway.

So, let’s go again for all that troubleshooting stuff …

Test prog 1 : errrr … I hope I can trust smashTV ?

Test core 1 : quartz 10.000 AEC08H, rechecked the datasheet, actually a parallel cut.

Test core 2 : not for me (I’m using V3).

Test core 3 : working on a breadboard, with all connections checked by multimeters.

Test core 4 and 5 : everything OK, ca. 0V on ground and 5.11V on Vdd.

Test core 6 and 7 : polarities already checked a million time.

Test core 9 : …

Test core 10 and core 11 : anyways I receive the good sysex string !!!

Test out 1 : led flickers, so does gm5 led on startup.

Test out 2 : my midi out grounds are not connected (only a shielding if I well understood ?)

Test PC 1 : first chose “MIDI USB port 1” on both input and output. Then tried with the five at the same time. Am I wrong here ?

Test PC 2 : receive nothing (but as I mentioned, my GM5 seemingly works in both directions).

Test in 1 : 220 ohms, red-red-brown, even checked with multimeter.

Test in 2 : checked for the million-and-first time.

Test in 3 : the led is lit but doesn’t flicker while sending sysex (although the gm5 led does). This tends to confirm the idea I had that my core’s opto doesn’t work. Well, let’s go forth …

Test in 4 : the led is still lit when connected at either pin 6 or 8 from the opto…

Test in 5 : Ok, led flickers.

Test in 6 (opto’s standalone) : aaaaaaaaand … uuuuuh ? it WORKS ? led is on when j13:m- is free, off when grounded … grrrr … so if the opto is fine, why does my led not flicker when connected on Rx and sending sysex???

Test in 7 : all my hopes rely on it. I beg you please, please don’t work …

Blaaaah seems to work, I have 5.11 V (the normal voltage output of my 7805 circuitry) when switch cable open, and ca. 45 mV when closed.

Test inout : gm5 led flickers, but nothing received. Tried all the possible configurations of the polarity, doesn’t work as well.

Test SW1 : unable to upload hex code again …

Test SW2 : this one I didn’t burn by myself. Again, I blindly rely on smashTV bootloader’s burning abilities.

Summing it up : there’s two main issues

  • I don’t seem to have any MIDI signal relayed by my core’s opto, and yet it seems OK (anyways I’ll buy a new one and see)

  • I’ve seen from my eyes (greatly helped by an oscillo and a wave generator) that my gm5 works in both directions, though I don’t receive anything when I loop it back and send him a sysex dump (and yet, its led flickers). Besides, I do receive a sysex on startup, so I don’t understand why the loopback tests don’t work. I use simple wires (about 20 cm long, pair-twisted) to connect to GM5, and have the MIDI out grounds from both core and gm5 opened. Could the issue come from it ?

Oh, and something I forgot : I made my first attempts with the gameport, since I have no MIDI plugs on my computer. I thought the upload problem could also come from here, that’s why I got on building a GM5. You know the following.

Thank you for having read this hard piece of bla bla.

[minimal.zip](< base_url >/applications/core/interface/file/attachment.php?id=5286)

[minimal.zip](< base_url >/applications/core/interface/file/attachment.php?id=6339)

2

Hi dubstructor,

Sorry to hear this is giving you problems!

Test prog 1 : errrr … I hope I can trust smashTV ?

You can…I am quite procedural about a lot of things, especially handling/writing the PICs.

I actually saw yours give the correct upload request via MIDI and display the “ready.” message on an LCD with my own eyes.  Simply put no PIC chip ever meets the cut shipping tube without firing it up on a modified Core I have here to be sure it gives the correct behavior.

My guess (considering the failed loopback test) is there is an interface or driver issue, something that won’t pass a simple loopback just won’t be able to do a sysex upload.

Back to the kit mill!

Best regards

SmashTV

3

I found bizarre that its ID was 70

Some PIC programmers don’t erase the ID field correctly. A workaround is explained at the MIDI Troubleshooting Page (requires to use the PIC programmer)

The reboot request will lead to an error acknowledge, please ignore!

Waiting for upload request…

Received Upload Request

Sending block #1 00000000-000000FF

Something is wrong with your toolchain setup, because a MIOS application should start at 0x3000 (at 0x0000 the bootloader is located). But don’t worry, there is a overwrite protection for the bootloader. It’s still there and you haven’t destroyed it (I’m writing this before you are assuming that the PIC has to be reprogrammed - this won’t help in your case)

I’ve seen from my eyes (greatly helped by an oscillo and a wave generator) that my gm5 works in both directions, though I don’t receive anything when I loop it back and send him a sysex dump (and yet, its led flickers).

For further analysis it would be interesting if the loopback works for other MIDI events.

E.g., you could send a MIDI Note event with the virtual keyboard of MIDI-Ox and check if it is received back.

Best Regards, Thorsten.

4

Is your external wirings is correct, too ?

http://www.tec.sci.fi/tecref/midiport.gif

5

Hy smash, hi TK, hi janis, good to feel your support …

You can…I am quite procedural about a lot of things, especially handling/writing the PICs.

I actually saw yours give the correct upload request via MIDI and display the “ready.” message on an LCD with my own eyes.  Simply put no PIC chip ever meets the cut shipping tube without firing it up on a modified Core I have here to be sure it gives the correct behavior.

Of course I trust ya :wink: Your PIC undoubtedly works. BTW I’ve not thanked you. So thanks ! Love the stickers ))

Anyways I made the tests prog1 to out2 just to follow the procedure, but since I receive the sysex string I don’t think it was necessary… It gives me to think (maybe wrongly ?) that the board is fine (at least the PSU and the circuitry that leads Tx signal to MIDI OUT), and the GM5 : MIDI IN to USB OUT too. And BTW my former one was not so dead after all :frowning: But let’s forget that

My guess (considering the failed loopback test) is there is an interface or driver issue, something that won’t pass a simple loopback just won’t be able to do a sysex upload.

Back to the kit mill!

Well, I have no grief against that, but …

For further analysis it would be interesting if the loopback works for other MIDI events.

E.g., you could send a MIDI Note event with the virtual keyboard of MIDI-Ox and check if it is received back.

OK, I already tried that : I have the MIDI NOTE ON and NOTE OFF messages in the output monitor on key hitting, but nothing in the input monitor ! It’s even the first thing I did, before trying sysexes … And yet …

With the oscillo, I saw a few bits incoming for both note on and note off events (unfortunately I lost the paper where I wrote down the datas I received, and have no further access to this material-but I remember it seemed totally OK).

With the wave generator, I sent to gm5 a square wave oscillating between 0 and 5V, making its frequency vary, so that I generated alea pseudo MIDI codes, and I actually saw a lot of random events in midiox input monitor, varying accordingly with my frequency variations. So I can’t understand WHY the loopback test fails (and I already tried every possible combination of polarity, though I brought very particular care when plugging it for the first time, re-checking the gm5 PCB in accordance with my core).

I must precise, I demanded for help soldering the gm5 smd chip to a technician from my school, who did it with monsters I can never afford, like a huge soldering oven and a binocular… He even checked it after with very accurate testers and everything was fine. Soldering the other parts of the gm5 was mine, but I also checked it OK… One of the life’s great mysteries I guess.

Something is wrong with your toolchain setup, because a MIOS application should start at 0x3000 (at 0x0000 the bootloader is located). But don’t worry, there is a overwrite protection for the bootloader. It’s still there and you haven’t destroyed it (I’m writing this before you are assuming that the PIC has to be reprogrammed - this won’t help in your case)

My bad … I didn’t notice the difference so I made a copy-paste of the message I had when trying to upload the app of troubleshooting : TEST SW 1 (though, it’s not a MIOS-level hex, so … it should start at 0x3000 ?)

Actually, when trying to upload the hex I joined, the message was :

The reboot request will lead to an error acknowledge, please ignore!
Waiting for upload request...
Received Upload Request
Sending block #1 00003000-000030FF

And then nothing…

/*So I guess my toolchain is OK ? (BTW I’m also stucked from the software side because I spent two weeks writing my own custom app which finally worked on ACsim, but I can’t compile it under the release target, seemingly due to some pointer’s issue … But that’s another problem I’ll post in the appropriate section when my MIDI stuff agrees to work).-*/

AAAAAAARGH !!! Wouldn’t it have been wrong, it would maybe have been the key … I’ve never been so disappointed by things working well … I’m deeply sorry for the mistake …  But thank you for learning me one more thing (these days I learn a bunch everyday, my head will soon be in a memory overflow). Funny you write me “before you’re assuming that the PIC has to be reprogrammed”, because before receiving smash’s PIC, and after my “PIC burner friend” went away, I built a PIC burner working with P18 which, because of my computer’s lousy ports, didn’t even pass the compatibility test (neither did none of my roommates’ computers. No laptop though.)

Oh, makes me think … You should maybe advise readers to make P18 compatibility tests, for example the very desperate one with the 100 ohm resistor between those two pins of the parallelport - with of course special care not to swap pins . (why not translate them ? I can make it if you want, hoping my understanding of german is still correct enough - and my english is not too bad …). But anyway it was fun, and now I owe two 74HC14 I can build analogue sound circuits with… (like a theremin - to be followed …)

Is your external wirings is correct, too ?

http://www.tec.sci.fi/tecref/midiport.gif

As I said, there’s only two twisted-pair wires between core and gm5, which are both no more than 20cm long, so I didn’t shield them with ground. The rest is the USB cable’s business… which knows it has to do his job well, or else it knows what will happen >) . And yes, I just checked it one million-and-second time, it’s all OK. But thanks

So what I think to do know, is to try with another 6n138, though it passed the standalone tests OK - or maybe to test the one on the GM5 ? but I would emphasize the fact that I take for sure it works in both directions, only not in loopback configuration - . Or, firstly, to do one thing I know I should have done, re-plugging my LCD … What I’d surely have done if not so buzzy . But, I’m not sure at all that the LCD works, because with my former PIC, I managed to have my second line full of blocks, but never “Ready” or “Hello” or whatever I tried to make it say with MIOSstudio, and curiously the backlight had worked for a few hours before slowly fading to dark and desperatly staying that way - with the blocks always here, though (checked the BC338 OK).

Writing all that I’m thinking to something : could it be my computer’s responsibility again ? I mean, I was not at home when trying all those tests with oscillo and so on… So, not using my computer… But right now I’m on mine and using ploytec’s driver, and anyway I DO RECEIVE THE CORRECT SYSEX ON STARTUP. And the gm5 obviously receive - and transmits - MIDI data since its proper led flickers on keyboard events and so does the one I put on gm5 MIDI OUT . So I assume that making the same tests at home it would lead to the same results.

6

Hello,

Sorry for your difficult day. I will offer a few things to try, but I am not as smart as the others that helped you already, so if I say “A” and they say “B”, you can bet on “B” for sure. :wink:

Sometimes a different approach might help, so here goes..

As best I can tell from your mad ranting, you have been able to see MIDI from MidiBox to GM5, but not much from GM5 to MIDIBox. Good news, you’re halfway there. (I’m trying to be positive!)

I’m going to start with the loopback problem, 'cause if you haven’t got control of your MIDI interface, you’re not going very far. You say that you can see pulses with your scope, but it’s not working. Maybe I can help with this observation: A scope looks at voltage, but MIDI works with current. If that doesn’t ring a bell, I’ll try it another way: Your scope is referenced to ground, but the input optocoupler is referenced to the other MIDI conductor, usually a resistor to +5 volts, I think. If the “other side” of that circuit isn’t there, it will act just like what you are describing. All voltage and no current will bust your chops every time. (I can almost hear the forehead slap and the low groan)

I have one other suggestion, but it’s a guess, I could be completely wrong..

Wire your MIDI Jacks completely and use real MIDI cables in between them. Don’t cut corners with a bit of wire hacked between where the MIDI jacks are supposed to connect.

There is no problem making your own MIDI cables, but make them right, and make good,clean soldered connections. Don’t go cheap on how things are connected, that’s just asking for extra headaches. If you have a cable that works “most of the time”, either fix it or destroy it. Flaky cables are just not worth it.

I hope this helps, good luck.

LyleHaze

One other thing.. You might want to start by uploading a file for a completed project, such as “midimon” or something, before trying out something you put together yourself.. Just to reduce the number of possible sources of trouble.

7

Hi lylehaze

Hello,

Sorry for your difficult day. I will offer a few things to try, but I am not as smart as the others that helped you already, so if I say “A” and they say “B”, you can bet on “B” for sure. :wink:

Hey… After having read from you on PSUs I’m not sure I will discard your advices so fast … Anyways I bet they would say A, too.

As best I can tell from your mad ranting, you have been able to see MIDI from MidiBox to GM5, but not much from GM5 to MIDIBox. Good news, you’re halfway there. (I’m trying to be positive!)

Zeno’s paradox… ;d

Seems like I’ll never reach my goal because I always got a half of the remaining way to run… But you’re right every half forth is good to take.

I’m going to start with the loopback problem, 'cause if you haven’t got control of your MIDI interface, you’re not going very far. You say that you can see pulses with your scope, but it’s not working. Maybe I can help with this observation: A scope looks at voltage, but MIDI works with current. If that doesn’t ring a bell, I’ll try it another way: Your scope is referenced to ground, but the input optocoupler is referenced to the other MIDI conductor, usually a resistor to +5 volts, I think. If the “other side” of that circuit isn’t there, it will act just like what you are describing. All voltage and no current will bust your chops every time. (I can almost hear the forehead slap and the low groan)

Outch my forehead… Careful, if I slap it too hard my poor head will burst. But, yeah, didn’t realize that current stuff at all.

A led plugged in series with a resistor between the outings of my pseudo-midi connections flickers on keyboard hitting though … But, in this case, maybe it is the resistor that creates the current ? So, maybe the issue finally comes from the opto ? Although it passed the standalone tests OK, I point out the fact that the test in 3 :

Rx pin - led|>|- 220 - gnd

leads to the led lighting but not flickering on receiving events.

So, what ? Can I directly go buy another 6n138 or can my gm5 in some manner produce a voltage but zero current signal, or (put whatever you want in here) ? If so, is there a workaround on the gm5 itself ? (hope not on the chip because I will absolutely not be able to modify it and I think it really has been made with all material you can ever dream about to solder SMD, and moreover not by me but by an old electronics guru I can trust as well as smashTV). And… what do you mean “the “other side” of the circuit” ? Because the PIC seems OK and my board as well …

For your suggestion on MIDI cables, OK, it’s worth trying but I’ll have to purchase two extra MIDI sockets (I have only two and two cables that I’m not using now). Do you think it still could be the “guilty part” even if :

  • I do receive my sysex at startup (core midi out - gm5 midi in OK (?) )

  • I do see the led flicker when shortening core midi in +/- (gm5 midi out - core midi in OK (?) )

Do you guys all think I should remove the gm5 opto from its socket to test it, too ? (I’m always very reluctant on doing that because always fear damaging with my big fingers)

And, finally, the reason why I woke up this night : I’m too dumb. Another forehead slap. Actually, when I did those tests on GM5, I don’t know why, but I think I didn’t try the loopback configuration, because it was satisfying enough to see both incoming and transmitted signals. But I just thought - and got out of bed - those two things don’t mean that either GM5 or computer can handle both directions AT THE SAME TIME.

Or maybe I’m saying nonsense, maybe MIDI is made of such a way that messages going in opposite directions are never sent at the same time … or USB … dunno, just trying to understand.

So … up to now I thought there were no problem from this side, but now I’m not so sure of it. Maybe the driver (though, I’m using ploytec’s, how can this be possible ?) Or my hardware USB config ? Is there a workaround, a mysterious option in my motherboard’s BIOS I should switch ON/OFF like I already had to a thousand times ?

I’m using a 4-ports USB cards plugged on PCI #3 slot, which has always been working fine with my other USB devices until now, my motherboard is an ASUS P4P800-X stuffed with a Celeron 2.60GHz (X86 type, family 15 model 2, brown eyes, curly-haired) .

What makes me think of it, is that, since I began this adventure, I never succeeded in communicating with my computer without any problems. Firstly, I connected my core to gameport (which was actually recognized as a MIDI device), and … same problem.

Secondly, thinking I had my first PIC scr***d up and waiting for smash’s, I tried to build a parallelport programmer, without any success (P18 started up, but never recognized my programmer, though I could switch LEDs ON/OFF with the Vdd/Vss… ON/OFF buttons, but with DATA IN never reacting, always stuck to 1). I tried every configuration for the parallelport from the BIOS (adress, (bi)directionnal …), tried to (de)activate the interrupt requests and so on … never worked.

Thirdly, this.

Nevertheless all my periphs work fine, I guess that if my motherboard was responsible for all that mess, I would already have encountered issues with them.

So, let’s sum it up :

  • could it be the core opto even if it passed the standalone test ?

  • should I check the gm5 opto, or could I have made any mistake on my gm5 pcb leading to voltage but zero current ?

  • (anyway I will try it but) could it really come from that I’m not using true MIDI cables ?

  • is it possible that my computer is the worst crap ever and definitely prevents me from having midi fun although I use enhanced drivers ?

  • one more thing I forgot : since it seems that I can both send and receive datas, but not the two at the same time, what will happen if I “don’t use feedback from core” ?? After all, my MIDIbox will only be aimed at sending datas. But this time I won’t try things I don’t understand.

Thanks a lot for all your suggestions ! Tomorrow I’ll go trying it on friends’ computers, before maybe shopping two MIDI sockets and a dozen optos. And try to make it shorter next time (hope your eyes don’t cry too much when reading me). Good night guys.

8

Gosh I made a silly answer …

I’m going to start with the loopback problem, 'cause if you haven’t got control of your MIDI interface, you’re not going very far. You say that you can see pulses with your scope, but it’s not working. Maybe I can help with this observation: A scope looks at voltage, but MIDI works with current. If that doesn’t ring a bell, I’ll try it another way: Your scope is referenced to ground, but the input optocoupler is referenced to the other MIDI conductor, usually a resistor to +5 volts, I think. If the “other side” of that circuit isn’t there, it will act just like what you are describing. All voltage and no current will bust your chops every time. (I can almost hear the forehead slap and the low groan)

Ok forget what I wrote … I just ensured that all my pull-up/down resistors are stuffed, and that the opto is fed (like I did already many times), everything is OK. So why don’t I have any current signal at Rx ?

9

OK, I can answer a few questions, but as always, I could be wrong.

On the bright side, if I AM wrong, there will be someone here to correct me in short order.

I’ll try to be more detailed than I need to be, since it makes everything clearer, and because others may be reading this too.

The difference between voltage and current: the Output from the PIC switches between +5 volts and zero volts. It is capable of sourcing (5 volts) or sinking (zero volts) about 25 ma per pin. In the case of the MIDI output, the signal goes through a 220 ohm resistor, then directly to the MIDI OUT jack. The return comes off the MIDI OUT jack, through another 220 ohm resistor, and then to +5 volts…

OK, I have drawn a simple .bmp to help me explain, but I can’t figure how to upload it here..

Here’s the current path for a MIDI communication. We start with +5 volts from the sending (MIDI OUT) port, through a 220 ohm resistor, and off to the MIDI OUT jack. The MIDI cable carries this to the MIDI IN jack, where we go through another 220 ohm resistor,then through the LED inside the optocoupler. The current path then goes back to the MIDI IN Jack, through the MIDI cable, back to the MIDI OUT Jack of the sender, through one more 220 ohm resistor, and to the PIC (or GM5 chip) that’s sending the data.

                                MIDI OUT                MIDI CABLE              MIDI IN            opto

                    +5Volts—/////-----<<------------------------->>-----/////----|>|-----\

                                                                                                                                  |

PIC OUT-----------------/////-----<<------------------------->>-------------------------/

The point I was trying to make.. you can use a scope to see lots of activity at the PIC output, or anywhere along the bottom wire, but unless the complete circuit, including the +5 pullup on the “other side” of the MIDI OUT jack is in place, the opto will not pass the current needed to light it up. Another point, if the wires are swapped, the LED in the opto will never “light up”, so it won’t work.

And this leads well into my other point.. You have what appears to be a working GM5. So IF it has normal DIN sockets for in and out, you can make a couple MIDI cables and test each one by just plugging IN to OUT. To answer your question: yes, midi can go full speed in both directions at once.

After doing a loopback test on each of your MIDI cables, you can be SURE that:

The GM5 is working, The GM5 drivers are working, the MIDI cables are tested OK, your MIDI OX and/or MIOS Studio are correct, and all your shit is good.

Once you have that, you are MUCH closer to figuring out how your MIDIBox is really doing.

Anything less than that, and you’re just making your troubleshooting more difficult than it needs to be.

Hope it helps.

If I got anything wrong, have me kicked and banned. :wink:

LyleHaze

10
  1. Simple, helpful midi signal tester :

http://www.epanorama.net/circuits/miditest.html

  1. One of my midi cables I made from old PC keyboard cable with original DIN plug on one end.
11

Right back …

OK I went buying my midi sockets, soldered them on gm5, plugged one cable between them and …

Still nothing. I can’t f***ing get my output messages to the input.

I had a polarized 1uF cap on C3 that I thought it could be the issue. I replaced it with a non-polarized, it didn’t change anything. I still see my gm5 led flicker when hitting a key or releasing it but nothing in the input. So… gm5 issue ? Driver issue ? Cable issue (I tested both of them) ? PC issue ?

On the other hand, I still have no current variation on the pic side of core opto, though everything is well stuffed after one more drastic check. Unfortunately they didn’t have any 6n138 so I’ll have to reorder some from the internet.

One more ‘strange’ thing : on startup I receive the sysex on both input and output monitors, is it normal ?

Heeeeeeeeeeeeeeeeeeeeeeeeeeeelp !!!

EDIT : I don’t exactly know how it happened, but hot-unplugging my gm5 and somehow randomly handling it, I finally had alot of midi events on both input and output of midiox  !!! Grande première !!! But … it leads to midiox crashdown.

12

You have a scope, so you can see things that most people can’t. Let’s use it.

The crappy graphics I drew before are back.. This time with “follow the bouncing trace”

diagnostics.

Test conditions:

GM5 interface is connected to PC, with software ready to dump sysex on request.

PC software is set to display incoming SysEx if it ever gets here.

MIDI cable under test is connected from GM5 MIDI OUT to GM5 MIDI IN.

Scope is powered up, grounded to GM5 ground, and set to see 5VDC trace.

                                MIDI OUT                MIDI CABLE              MIDI IN            opto

                    +5Volts—/////-----<<------------------------->>-----/////----|>|-----\

                                                                                                                                  |

PIC OUT-----------------/////-----<<------------------------->>-------------------------/

Now figure this, the 5 volts will be divided across three resistors and an LED inside the opto, so IF the current loop is complete, we’ll see about 1.5 volts drop across each of those four devices. Since the loop starts at +5 volts, we’ll see that only when the PIC output is LOW, completing the current loop.

So without getting into the GM5 traces, let’s see what we can scope off the backs of the MIDI jacks..

While at “rest” (not sending), BOTH of the MIDI OUT leads will probably read near 5 volts. Now look at each one while MIDI is sending.

Good readings, showing a complete current loop:

The one closest to the (PIC,GM5,Buffer) Out should be showing a square wave from +5 volts to about +1.5 volts. The other MIDI OUT pin should be a square wave between +5 volts and about +3.5 volts.

Bad Readings, showing an “open loop”:

One pin will be square wave from +5 volts to near 0 volts, the other could be anything, probably always +5 volts

The difference between those two is whether the loop is complete, so current can flow when the PIC output is LOW.

Notice the MIDI cable is “straight through”, so looking at the 2 pins on the back of the MIDI IN jack should give the same results as above.

Because MIDI is a “current loop”, ANY break in that loop will stop it from working.

If you are testing a MIDI connection between two different devices, the scope should be connected to the ground of the MIDI OUT device, since it drives the link. That’s why the MIDI IN circuit needs an optocoupler.

One other detail: The MIDIBox, and a lot of other MIDI IN circuits have a “back diode” across the optocoupler LED, that allows current to flow backwards if needed. (not shown in my cheap graphics, see the core schematics) If everything I described checks OK, but it still doesn’t work, you may be have the wires crossed in your MIDI cable or any of the MIDI jacks.  If the previous tests check OK, move the scope ground to the MIDI IN device, and look at the Output of the optocoupler(6n138 Pin 6). Always High is the “at rest” state, it should pull low pulses as MIDI messages come in.

I hope this all made sense. The “current loop” will divide the voltage as it passes through each resistive component of the circuit, but only if current is flowing. If there is an “open” in the circuit, you get +5 or 0 volts and no current through the optocoupler. I said the drop per resistor would be about 1.5 volts. That’s a rough guess, so if you want more accurate estimates, subtract the forward voltage of the opto LED from VCC, and divide the rest by three.

_IF_ you can “float”(separate) the ground on either your scope or your MIDI gear,

(DON’T do this if you don’t know exactly what that means)

you can connect the ground lead of your scope to the 6n138 pin 3, and the scope probe to the 6n138 pin 2. You should see a positive square wave of about 1.3 to 1.7 volts when MIDI is coming in. If this is correct, you have tested everything you can right up to a working LED inside the opto of the MIDI IN circuit.

Maybe it makes better sense now, maybe I’ve just confused everyone.

If I get feedback that I’ve flown too wild, I’ll gladly delete this post.

Good Luck,

LyleHaze

13

OK now I use MIDI cables and I finally have a loopback.

Here’s the configuration :

MIDIox -> GM5 OUT <----------> CORE IN -> OPTO (pic not stuffed) -> CORE OUT <----------> GM5 IN -> MIDIox.

But … it loops back so well that I fall in an infinite loop everytime I send something, until I unplug any midi pin ! The good thing is that I have exactly the same messages on both input and output, and at the same times. One more bothering thing is that when I unplug a midi pin to break the loop while sending sysex, or when I exit midiox … My PC reboots. So … driver issue ? I firstly thought the issue was due to that core and gm5 are commonly grounded, so I removed the ground pin of my core midi out, but it didn’t fix the problem.

One troubling fact I have to point out is that on pic’s startup, as I already said, I receive the sysex on BOTH INPUT AND OUTPUT, that I don’t take for normal.

Lylehaze, I’ll do the tests you recommand as soon as I have a correct loopback, because if I understand well, they’re aimed at seeing if every part at the pic side of opto is in place and/or works well . Unfortunately I actually have no scope, used that at school but can’t anymore now that I’m in holiday ! but I guess if I send either a continuous FFFFF… (high midi state) or 00000… (low midi state) sysex,  I will be able to use a multimeter instead and see if the voltages across the midi path are those you nicely computed for me, right ? So please don’t remove your post !!

OK fellows, now I try on either another PC or with another driver, though I’m afraid if ploytec’s doesn’t work, none of them can something for me …

EDIT : when I unplug the ground on core out, I receive, on key hitting, a 256 bytes random sysex that also appears in output monitor, and this time without infinite loopback. Just to be sure : I haven’t cut opened any jumpers on gm5, so the five ports appear in my devices list. Am I right to chose the first for both input and output ? Anyways, if I check the schematics (again), it’s the only one I’m actually using. And, obviously, if I chose for example the second port for input, I have no loopback. So … should I cut the jumpers ?

EDIT 2 : no, forget that ground stuff, it’s all random. I just re-made it and had exactly the same infinite loopback than described.

14

Check the MIDI port routing in MIDI-Ox, it seems that you’ve configured a loopback there which can cause such random effects.

Also the “internal MIDI routing” in MIOS Studio can be easily messed up - have you ever changed it? (it can be displayed with Options->Show Internal Routing, and restored with Options->Restore Default Internal Routing)

Best Regards, Thorsten.

15

TK is right, it sounds like you have a software “MIDI-THRU” that’s screwing with you.

Also, to clarify: The “loopback” test that I described does NOT include the MIDIBox,

just a cable going from GM5 MIDI OUT to GM5 MIDI IN, I figure we get all that sorted before we put the MIDIBox into the picture.

First, check MIDI-OX and remove the link from IN to OUT in software.

Test by sending with NOTHING CONNECTED. what you send out should NOT come back.

Then add a MIDI cable from GM5 Out to GM5 IN, send again, what you send out should COME RIGHT BACK, but on;y when the cable is connected.

Repeat for each cable as a cable test.

No doubt, you’re making progress!

Good Luck,

LyleHaze

16

In MIDIox I have done nothing more than selecting my device - the one I named “noah’s ting” - on both midi input and output, and in MIOSstudio I’ve never changed anything in the internal routing, excepted linking my device in left panel to MIOS studio in port and MIOS studio out port in left panel to my device.

I join the screenshots.

EDIT : ok lylehaze I’m trying it, but this was the first thing I did and I did have this infinite loop, so I thought I misunderstood and that’s why thereafter I cabled the whole loop including core’s opto.

By “removing the link”, I assume you mean unticking the lil’ box at the bottom of the routing window ?

Thanks again for your help.

mios routing.JPG
mios routing.JPG1134×448 68.2 KB

midiox routing.JPG
midiox routing.JPG478×387 30.7 KB

mios routing.JPG
mios routing.JPG1134×448 68.2 KB

midiox routing.JPG
midiox routing.JPG478×387 30.7 KB

17

MIDI-Ox: uncheck the “Automatically attach Inputs to Outputs during selection” Option. It causes a SW loopback.

Thereafter, deselect the MIDI Ports, select them again - this will activate the IOs without creating the loopback.

Could it be, that you are running MIDI-Ox and MIOS Studio in parallel? THis would explain, why MIOS Studio behaves so strange as well.

Best Regards, Thorsten.

18

OK forget my last post, just crossed posts ^^

Errrrr … no I’m not using those on parallel, anyways on my PC midiox won’t open ports that miosstudio uses …

19

YAAAAAAY GREAAAAAAAAAAAAT !!! I finally managed to have a correct loopback in miosstudio !!!

But curiously not in midiox, even with the “attach input to output” unticked, and devices closed then re-opened, I still have this infinite loopback.

Anyways I just made a great step forth !!! Thanks fellows :wink: Et vive mios studio !!!

Now I’m getting out for a little while, I need fresh air. I will go on in my midistuff debugging later and give you the freshest news. I feel this is all close … Already get my champagne ready …

20

OK enough of fresh air, back to the wicked foggy atmosphere of my room.

Now guess what ? I’ve uploaded my first app !!! Should be bouncing everywhere … but … nothing more happens. The upload seems to work well, I’ve verified the ID numbers, I have the checksums, no problem (yeepee ! After all that’s what I’ve been sweating for) .

I uploaded a simple test application, supposed to send a CC 1 on channel 1 with the last pot value on any pot tweaking (using 8 unmuxed pots) :

main.c

#include "main.h"

#ifndef _DEBUG_C
	#include "cmios.h"
	#include "pic18f452.h"
#endif

void Init(void) __wparam
{
    MIOS_SRIO_UpdateFrqSet(1); // ms
    MIOS_SRIO_NumberSet(NUMBER_OF_SRIO);
    MIOS_SRIO_DebounceSet(DIN_DEBOUNCE_VALUE); // gestion de l'anti-rebonds pour les DIN
    MIOS_SRIO_TS_SensitivitySet(DIN_TS_SENSITIVITY);
    MIOS_AIN_NumberSet(AIN_NUMBER_INPUTS);
    MIOS_AIN_UnMuxed();
    MIOS_AIN_DeadbandSet(AIN_DEADBAND); // définit la variation minimale à laquelle soient sensibles les AIN.
}

void Tick(void) __wparam {}
void Timer(void) __wparam {}

void DISPLAY_Init(void) __wparam
{
  MIOS_LCD_Clear();

  // print static messages
  MIOS_LCD_CursorSet(0x00); // first line
  MIOS_LCD_PrintCString("HELLO");
  MIOS_LCD_CursorSet(0x40); // second line
  MIOS_LCD_PrintCString("WORLD !!");
}

void DISPLAY_Tick(void) __wparam
{}

void DIN_NotifyToggle(unsigned char pin, unsigned char pin_value) __wparam
{

}

void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) __wparam
{
    MIOS_MIDI_BeginStream();
    MIOS_MIDI_TxBufferPut(0xb0);
    MIOS_MIDI_TxBufferPut(1);
    MIOS_MIDI_TxBufferPut(pin_value);
    MIOS_MIDI_EndStream();
}


#ifdef _DEBUG_C
extern void DISPLAY_Init(void);
#endif

main.h :

// $Id: main.h 234 2008-03-28 23:10:41Z tk $

#ifndef _MAIN_H
#define _MAIN_H

/////////////////////////////////////////////////////////////////////////////
// Global definitions
/////////////////////////////////////////////////////////////////////////////

#define AIN_NUMBER_INPUTS      8    // number of used analog inputs (0..64)
#define AIN_MUXED_MODE         0    // set this to 1 if AIN modules are used
#define AIN_DEADBAND           7    // plus petite variation de valeur à laquelle les AIN soient sensibles.
                                    // Les grandes valeurs réduisent la résolution, mais aussi l'hypersensibilité aux petits mouvements.
                                    // 7 is ideal for value range 0..127 (CC events)

#define NUMBER_OF_SRIO        2   // max(nombre de 74hc595, 74hc165)

#define DIN_DEBOUNCE_VALUE    10    // anti-rebond 
#define DIN_TS_SENSITIVITY     0    // sensibilité du touch-sensor (j14; pin 27=RD4 du PIC). 0 si inutilisé.

/////////////////////////////////////////////////////////////////////////////
// Global Types
/////////////////////////////////////////////////////////////////////////////


typedef union {
  struct {
    unsigned ALL:8; //vecteur de flags sur un octet
  };
  struct {
    unsigned DISPLAY_UPDATE_REQ:1; //réaffichage de page
};
} app_flags_t;

//prototypes MIOS

void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam {}
void MPROC_NotifyFoundEvent(unsigned entry, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam {}
void MPROC_NotifyTimeout(void) __wparam {}
void MPROC_NotifyReceivedByte(unsigned char byte) __wparam {}
void SR_Service_Prepare(void) __wparam {}
void SR_Service_Finish(void) __wparam {}
void ENC_NotifyChange(unsigned char encoder, char incrementer) __wparam {}

#endif /*_MAIN_H*/

I attach the hex I obtain, but I don’t think this is the problem - anyways it’s the same with other sample apps.

I’ve re-plugged my LCD in order to see if I could write to it with miosstudio and … I always got my row full of unexpressive blocks. Its datasheet mentions an initialization sequence, but I guess this is done by the PIC on startup ? Anyways, I ain’t got no input MIDI messages on pot turning.

I assume that since I receive checksums while uploading, and anyways using feedback from core, the datas I send actually reach Rx. Just to be sure, I led-tested it like in troubleshooting test in 3, and sent a sysex with midiox : tadaaaaaa ! it flickers ! (great progress again, because up to now it did hopelessly not).

So, the upload seems to be successful, but the PIC then doesn’t behave like it should. Weird. Does the sysex on startup always prove for sure that the PIC is OK ?

(Now that I solved my upload problem maybe I should move or rename this topic ?? Besides,

[glow=red,2,300]NOTE TO THE READER : THE MAIN LESSON HERE IS ALWAYS USE MIDI CABLES.[/glow]

Maybe not the only thing I had to fix, but the greatest help I think .)

[project.hex](< base_url >/applications/core/interface/file/attachment.php?id=5298)

[project.hex](< base_url >/applications/core/interface/file/attachment.php?id=6351)