seq v2.4 - led chaos

[haesslich]

Hi everybody.

Finished yesterday our Seq-Prototyp. Works realy gread and it makes realy fun!  ;D There is still one mistake left. The 16 step LEDs seems to be "mad". They do not flash as they should.

When I build the CLock-Box some time ago, there was a kind of the same mistake. But I can't remember what was the solution. May there be something wrong with the DOUT, cause I tested the Seq sequencing Reason and everything works great. Maybe there is a kind of data-transmission problem. Maybe wireing mistake?

If anybody got an idea, please tell me

Thanks braintu

[stryd_one]

The 16 step LEDs seems to be "mad". They do not flash as they should.

What do they do? Are there any other things that are not quite right? No matter how small or insignificant they seem, they might give us a hint...

When I build the CLock-Box some time ago, there was a kind of the same mistake. But I can't remember what was the solution.

Now you know another reason why it's a nice idea to document problems and solutions here or on the wiki.. Sometimes you might be documenting them for yourself ;)

[haesslich]

Hi.

no everything else is allright. If I push for example Step 1, I can see the "C-3" goes on in the LCD. The steps are even given out correctly to MIDI, as I said, tested it with Laptop and Reason.

OK - I try to make some usefull tests to describe the LED behaviour. Then i will leave a massage in about 2h.

thx

[haesslich]

so i checked every important connection, and changed the ics on the dout. the only thing that changed is the, lets say error-behavior. the led behavior is realy to complex to discribe it, just an example:

after swiching on the seq stepLEDs 1,5,9,13 are high, 12 and 16 jitter.

same with the previous ics: 1,4,8,16 are on, if you hit a step button the LED from the step befor goes high, just the led! - in the lcd everything is correct.

I hope somebody understands what i mean.

i have no idea what could be wrong

[TK.]

Could it be, that one of the (unusued) DOUT pins has a short? Would it be easy for you to disconnect all other LED connections?

Best Regards, Thorsten.

[stryd_one]

Sorry haesslich! I thought I had replied to this but I must have closed the window or something... Anyway I just wanted to say I didn't mean to disappear on you there :)

[haesslich]

okay i checked with the srio interconnection test, everything seems to be okay.

next i had a look for shorts on the dout module, found some, soldered properly (this time without short circuits ;) ) again but this did not solve every problem. here is one fantastic example of the chaos :)

i set to 48 bpm so that i can see more clearly what's appening. i set no step, and no led lights up. well as long as i don't change into the menu: in the bpm menu LED 4 blinks. back in the main page it stops blinking. i really do not have any idea what this is supposed to be :)

is there a possibilitiy, that the short circuits destroyed the shift registers?

[TK.]

In v2.4 it's normaly that one of the LEDs blinks in the BPM menu. So far I remember this was to display the divider for the external clock (there was no place on the 2x16 LCD frame to do this...)

There are some more menus where you will notice those blinking LEDs, e.g. pattern selection.

In MBSEQ V3 you will see this in every menu, because they are used to indicate the selected menu item.

Best Regards, Thorsten.

[haesslich]

Hi.

I ve done a lot of measureings. Now Im very shure that the problem is somewhere in the bus system.

I checked the bus at every buspin from the ics and found out something strange. on some pins its a low level. bits are sent with a high level. on other pins this turns around. teh bus state is high and bits are sent with a zero. so tk or someone els whats the normal state?

and if i push button like step9, pla or braek the state on the ics switch. anybody an idea???

please help!!

[TK.]

I'm a little bit confused now.

From your last description everything seemed fine, just only a LED was blinking. I described, under which circumstances this can happen.

Now you are writing that you continued with debugging. So, what is the current state? What did I miss?

(I'm asking to get a feeling, which additional information could help you)

Measuring the LED matrix: you have to take into account, that the "busses" are time-multiplexed. The update frequency is 1 mS, it's hard to measure this correctly with a multimeter.

If all LEDs are off in the column, you should measure a constant 0. With all LEDs on, you should measure a constant 5V. In all other cases you will measure something between 0V and 5V

A very easy way to debug the matrix is just to disable LED matrix mode in the firmware, and to connect the row which should be measured to ground (all others open). This would also allow you to measure the LED outputs unmultiplexed.

But just to highlight again: I'm not sure, if you are hunting for an imaginary problem, which is easy explainable if you would know, how the LEDs are driven in the different menu pages.

Btw.: did you upgrade to MBSEQ V3 in the meantime?

Best Regards, Thorsten.

[haesslich]

edit: english version:

i'll explain from the beginning, i hope to reduce confusing ;)

we (haesslich&braintu) built the seq. v2.4 because we only had one of the "old" pics.

some leds startet blinking wildly when certain combinations of buttons were activated. example:

after starting the seq. the steps 1, 5, 9, 13 were lit up (just like they have to be) but LED 8 was blinking wildly. after pressing another button ~ 4-6 other LEDs started blinking wildly.

when playing, the "cursor" did not invert these LEDs but just lighted them constantly up. (the steps thet were set regularly were inverted when the "cursor" went through the pattern - just like they should be.).

today we used the oscilloscope to measure the bus. at first everything seemed to be okay (bus signal = low as long as no step set; bits set the bus signal high), but then we found out that step-button 9 kind of inverted the bus signal. in this case the bus was constantly high and by setting any step, the corresponding bits pull the bus signal to low. and exactly then our special friends among the leds started going wild ;-)

next i started measuring the bus signal on all ics. at the pin where one ic gives the bus signal to the next one in a row. i found out, that some chips hat the right signal levels (bus = low, bits = high), and some had wrong levels (bus = high, bits = low). but: interesting that the wrong signal levels were changed to right signal levels on some chips.

[this is the point where i got confused ;-) ]

for example i measured this:

ic_1 -> right levels

ic_2 -> right levels

ic_3 -> wrong levels

ic_4 -> right levels

then i looked again on the bus at the dout module (on the oscilloscope screen). and i recognized: indeed here i could see a wildly blinking bit synchronized to a wildly blinking led. therefore i think that the main module sends out these commands, right?

but now i don't have any idea what to do next. i guess that some connections (maybe at the buttons?) have switched ground and signal. but on the other hand: i connected the ground in star-shape. (i did not use the ground on the din and dout for the buttons and leds but connected all led and button grounds to one line which i connected directly to the ground of the voltage regulator on the core module). if buttons in this case would have switched connections, the ground would be pulled to 5V.

both of us checked the dout and din modules for shorts, optical and with multimeter.

my last idea is to desolder all connections and solder again with heat shrink tube. before i do this i just wanted to check here again. sorry for the confusion; i think we discovered a real problem in our seq. (this time not interpreting some menu-feature as a bug or hunting ghosts or anything; i wish i could make a short video of the blinking leds. it's lighting up very short and not really bright, but very fast and quite randomly.)

i hope i could explain more clearly now,

have a nice weekend!

brain

and in german:

Hi thorsten

ich schreibe mal in deutsch - hoffe das ist ok - kann ja nachher die ergebnisse nochmal auf englisch posten.

Ich fange nochmal ganz von vorne an. Wir (häßlich und braintu) haben den seq aufgebaut. da wir noch den "alten" pic haben ists nur möglich die version 2.4 aufzuspielen.

die leds haben bei bestimmten tasten angefangen zu blinken. wenn der seq gestartet hat leuchten step 1,5,9,13 - wie es sein soll. zb led 8 flackert aber. hat man jetzt noch eine weitere taste gedrückt - haben noch ca 4-6 weitere leds geblinkt bzw leuchteten einfach auf. wenn der step an den stellen war, wo fälschlicherweise leds leuchten wurden diese aber nicht invertiert!

heute haben wir dann das oszilloskop an den bus gehalten. zuerst schien alles ok (die busleitung war low und bits wurden als high gesendet), aber dann ist uns aufgefallen, dass beim drücken von steptaste 9 sich die pegel gedreht haben. der bus war jetzt auf high und die bits wurden als low gesendet - jetzt begannen auch die leds (verstänlicherweise) auszuflippen.

dann habe ich den bus an allen ics gemessen. also immer dort wo der eine ic die daten an den nächsten weiter gibt. hier ist aufgefallen, dass manche ics den richigen pegel hatten (low = bus, high = bit wird gesendet) und andere den falschen pegel hatten (bus = high, daten senden = low). es war aber so dass nicht, sobald ein ic den pegel gedreht (also "falscher pegel") hat der nächste zwangsweise diesen übernommen hat, sonder es kam auch vor dass ein ic diesen wieder richtig gedreht hat.

so sah zb eine messung so aus:

IC_1 -> richtiger pegel

IC_2 -> richtiger pegel

IC_3 -> falscher pegel

IC_3 -> richtiger pegel

dann habe ich mir ein bit einer flackernden led am bus (auf dem oszilloskopbild) rausgesucht. und hier wurden tatsächlich die befehle vom pic aus an das dout modul gesendet. dh man sah synchron zur led auf dem oszilloskop ein bit "blinken".

also schließe ich daraus, dass der fehler an den eingängen liegt da der pic ja tatsächlich aus irgendeinem grund meint er müsste etwas an die douts senden.

Ich habe aber keine ahnung wie ich weiter vorgehn soll. meine vermutung ist, dass manche taster enen schluß gegen plus anstatt gegen masse legen. dies kann aber eigenlich nicht sein, da ich die masse als sternmasse verkabel habe, soll heißen ich habe nicht die massen an den douts und dins benutzt sondern alle massen der taster und leds in reihe verbunden und diese auf die masse des 5-Volt outs auf dem core modul gelegt. würden taster einen schluß gegen plus bilden so müsste nicht mehr gehen, da die masse dann auf 5V läge.

Ich habe echt keine Idee was ich noch machen kann. Die dout und din Module habe ich mehrfach auf kurzschlüsse optisch und auch mit dem multimeter getestet. meine letzte idee ist jetzt noch alle taster abzulöten und neu zu verkabeln. bevor ich diesen aufwand jedoch betreibe wollte ich nochmal hören, ob du eine idee hast was ich noch tun könnte um diesen fehler zu lokalisieren.

Ich hoffe ich habe mich verständlich ausgedrückt.

schönes wochenende noch

brain

 

[doc]

Hi haesslich,

... what a ugly name ...

I just continue writing in english, so that all others can follow ...

I sometimes also had those Led wireness. I moticed three reasons of them:

1). Once I've forgotten some bridges on the DOUTx board .... But you've checked this, I think

2). A short somewhere between Si Sc RC SC

3). Not enough power for the core (mostly: The regulator goes in protection because of high temperature -- heatsink?? or the psu is too small). There are various symptoms if the PIC runs in under-voltage...

Did you measure the current after the regulator and please also measure the voltage for the PIC. Do you have a heatsink on the regulator?

What psu are you using?

greets

Doc

[haesslich]

hi doc!

i don't think that the voltage is the problem in our case, because the voltage regulator does not even get significant hot. (without any heatsink).

for testing the seq. i lately used a small lab-voltage supply. i don't believe that this is too small. (should be at least 1A, i can check on that).

but i did not check the current after the regulator...

[TK.]

Thanks for the additional informations! I'm still thinking about what could cause such a behaviour...

Are you using 74HC595s or 74HCT595s?

It would also be interesting, if the problem is caused by a static or dynamic effect.

This can be easily tested with the debug function of MIOS Studio.

IMPORTANT: you have to upload a "dummy application" which doesn't frequently modify the DOUT registers - just use the skeleton

Thereafter open the debug window of MIOS Studio and enter following functions:

With the first two MIOS_DOUT_SRSet functions the pattern of the 16 LEDs can be controlled (0xff means: all LEDs on - try also a running one: 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80, and checkerboard: 0x55, 0xaa)

With the third MIOS_DOUT_SRSet function the LED line will be selected. The selected line should get a 0, the others a one. Since I'm not sure if the cathode lines are connected to the upper or lower nibble, just duplicate the number.

Valid values for single line selection are: 0xee, 0xdd, 0xbb, 0x77

Best Regards, Thorsten.

[haesslich]

Hi tk

thanks for these informations. we will test it on the next debugging session. I did the whole sunday tests on the seq. So i'll write down my results - perhaps somebody can find out a pattern.

Now i'm more sure than before that the mistake is on the DIN modules: If i disconnect the third Din module, everything (the leds) works fine. Don't say therefore the mistake must be on the third DIN module. I checked it with three! different din modules, even if there is no 74HC165 in the socket, the leds go mad. There were no changes on the measurements on the bussystem if i connect or disconnect the the DIN#3, the bus signals seem wrong to me everytime. only changes in the behaviour of the LEDs, when i connect or disconnect din#3. Then i thought the mistake must be in the second modul - but i didnt find anythig.

So i did a grand measuring:

I checked every in and out of the bus at the ics (Pin9, Pin10)

I found two different oscilloscop pictures. The first which i will call "OK" in the following looks like this:

____  ______________  ______________  __________

      |_|                    |_|                    |_|

the second one witch i will call "wrong" in the following looks like this:

      __                      __                      __

____|  |_____________|  |_____________|  |_________

DIN#1:

IC_1    Pin_9  OK

          Pin_10 OK

IC_2    Pin_9  OK

          Pin_10 OK

IC_3    Pin_9  OK

          Pin_10 OK

IC_4    Pin_9  OK

          Pin_10 wrong

DIN#2 

IC_1    Pin_9  wrong

          Pin_10 wrong

IC_2    Pin_9  wrong

          Pin_10 OK

IC_3    Pin_9  OK

          Pin_10 OK

IC_4    Pin_9  OK

          Pin_10 NO SIGNAL!

In some case IC4 of DIN#1 inverts the bus to wrong and IC2 of DIN#2 inverts the bus to OK back

DIN#3 -> not connected

LEDs are ok, even the bus looks strange for me

DIN#3 connected -> LEDs go mad

ANYBODY an idea??

i'll check with the mios debug interface next time, when i have energy and motivation for a debug session and will post the results here afterwards ;)

Greets brain

[TK.]

Pin 9/10 is the serial bus - the "idle" level is either 0 or 1, depending on the output value of the next shift register in the chain. The input level at the end (you noticed "no signal") is the last input in the chain, it should always be 1, because of the pull-up termination.

Since MIOS doesn't scan the shift registers permanently, but only each mS, I would say that this behaviour is normal

More interesting are the RC/SC signals from the core to all 74HC165/74HC595. Have a look for the quality of the SC (shift clock) line when the third DINX4 module is connected (it should look digital-like, with sharp edges). Check it especially at the 74HC595 which are going mad - you should still see a proper clock

Best Regards, Thorsten.

[haesslich]

Hi Thorsten.

I checked the edges some days ago. They dont look like digital - they have a enormous transient process, about 2V and they need some time to come to level.

I do not think that the dout has any problems, because as i sad, they act like they should. If there were some leds flashing (which should not flash) i could see flashing bits on the oscilloscop. so the pic sent these messages!

So one point is clear the transient process is not correct - but how to handle this problem??

Daniel

[TK.]

If the clock is not distributed properly, further analysis on other signal lines doesn't really make sense - the ICs won't behave deterministic anymore.

Here a snapshot of the SC (shift clock) of my MBSEQ, where much more shift registers are connected (due to the Duo-LED/button matrix)

At the top the 500 uS/div view, at the bottom the zoomed 1 uS/div view

The matrix is connected via a 50 cm ribbon cable to the DIN/DOUT modules, but even this length doesn't hurt

So, it seems that the clock is loaded by something which should not be there, like a short on any module or a damaged ribbon cable?

Best Regards, Thorsten.

[haesslich]

Hello!

OK i checked the sc signal. While the transient process the sc signal goes shortly down to -2,5V!!! (1µs/div)

So I disconnected  the sc wire of the DIN and DOUT and changed the measuring point to the pic - but still the same. The ribbon cables I changed some days ago.

There was another strange thing: as I told, if I disconnect the last DIN everything works fine on the user side, but nothing changes on the bus!? I found out that I only have to disconnect the SC-wire from the third DIN and everything works (on the user side - nothing changes aon the bus)

So I think we set some limits to the problem but for me this seems to be mystery  ;D

by the way: we use HC ICs

mysterious Daniel

[TK.]

How does it change when you remove the 4 bridges to the CLK pins of the 74HC165s? And when you connect them again step by step?

Maybe this helps to narrow down the problem

Best Regards, Thorsten.