[solved// multiple core issue] tracking a strange pots bug

protofuse · November 3, 2009, 9:27pm

hello,

only several hard bugs on the protodeck… grrr. bug tracking, at this point, is very annoying but has to be done!

I think I killed a 74HC4051 (analog mux/demux)…

My question isn’t “how to test it?” indeed, replace and try is the right way for that.

the symptom was: freaking flow (not like a jitter, a real random flow, continuous when one pot on the mux/demux was opened etc)

The question is: what could be frequent causes to kill this kind of component in midibox world ??

It would prevent me some headache tracking things that doesn’t matter

I guess short circuit or smtg like that … but is there a frequent cause to that?

all hypothesis about that could be fine…

baptistou · November 5, 2009, 9:30am

Hi,

To be sure that the problem comes from the suspected 74HC4051, you took it off, put a new one and then everything worked, is that right?

For me two things could burn an IC: over voltage or overcurrent. I doubt that you had an overvoltage if you only have +5v running around your board. Over current is what you had then. It could be possible for example if you have the output of the IC put to ground and you put +5V on the input, then you have a high current flowing through the device when the adresses pins connect this input to the output.

Baptistou

protofuse · November 7, 2009, 9:36pm

Hi,

To be sure that the problem comes from the suspected 74HC4051, you took it off, put a new one and then everything worked, is that right?

For me two things could burn an IC: over voltage or overcurrent. I doubt that you had an overvoltage if you only have +5v running around your board. Over current is what you had then. It could be possible for example if you have the output of the IC put to ground and you put +5V on the input, then you have a high current flowing through the device when the adresses pins connect this input to the output.

Baptistou

sorry I didn’t view your answer

it wasn’t that.

still tracking this last hardware bug on the protodeck

protofuse · November 7, 2009, 9:48pm

hello experts,

I’m tracking my 2 last protodeck hardware bugs and I’d need some help.

one pot give me a headache

everything works fine (2cores + 2 dout + 3 ain + 3 din)

I’m turning one pot (THE damned pot) and the other core freezes (some leds switch off, buttons and pots attached to the core frozen don’t respond etc)

this is the ONLY pot that gives me that.

I tested to boot the gear with this pot a little bit open, it boots right ; I turn a bit … wow! 2nd core freezes!

so I guess it isn’t an overcurrent, but a “signal” problem..

any ideas?

the problem of testing pots

independently of the previous described problem (I’m quiet sure about that), 8 pots attached to one SR give me headache too.

one works, the other not etc etc.

I switched ribbon cable from one SR to other, the previous unworking pots works and vice versa.

so, I bet on the SR. I changed it… all the same.

and I had the genius idea to test the pots…

but, how could I test the pots?

I wanted to test continuity between SR and pots but I found a strange thing: my continuity tester beeeeeps* when I test the continuity between all the middle pins on my pots… (those more far don’t give that)

how could I test that?

all ideas would be appreciated

protofuse · November 8, 2009, 8:26am

one big clue about 1)

if I disconnect the midilink between core1 and core2, if I turn this weird* pot, no problem.

so my hypothesis: it is a midi issue between the 2 core … no?

for the 2)

I’m still stuck, and VERY stuck

T.K · November 8, 2009, 10:54am

I think it’s better to measure the voltages instead of continuity with a beeper.

Each pot outputs a value between 0V and 5V at the middle pin.

Check this first. Whenever you turn the pot, the output voltage must change.

Thereafter disconnect J6 of the AIN module from the CORE module, and connect the J6:A/B/C lines directly to 0V or 5V.

There are 8 combinations how these lines can be connected to 0V/5V

Each combination selects another pot (1 of 8), and you can measure the voltage of the selected pot at J5 of the AIN module.

If during measuring it turns out, that a certain combination doesn’t route the pot voltage correctly to J5.Ax, you know that the error (e.g. missing cable) is located between the 4051 multiplexer and the appr. pot

Best Regards, Thorsten.

protofuse · November 8, 2009, 12:41pm

I think it’s better to measure the voltages instead of continuity with a beeper.

Each pot outputs a value between 0V and 5V at the middle pin.

Check this first. Whenever you turn the pot, the output voltage must change.

Ok I’ll do it firstly…this afternoon.

Thereafter disconnect J6 of the AIN module from the CORE module, and connect the J6:A/B/C lines directly to 0V or 5V.

There are 8 combinations how these lines can be connected to 0V/5V

Each combination selects another pot (1 of 8), and you can measure the voltage of the selected pot at J5 of the AIN module.

If during measuring it turns out, that a certain combination doesn’t route the pot voltage correctly to J5.Ax, you know that the error (e.g. missing cable) is located between the 4051 multiplexer and the appr. pot

ok I’ll check it in the second time.

but I really think about murdered* pots

thanks a lot Thorsten

I’ll keep this post updated

protofuse · November 8, 2009, 1:29pm

Thorsten, considering your clearly explained test/advices, I guess it is for the bug 2)

Do you have an idea about the bug 1)??

it is very strange.

T.K · November 8, 2009, 1:52pm

issue 1) could happen if your application running on core #1 doesn’t send a complete MIDI event, so that core #2 will freeze until the timeout period has passed.

There are more possible reasons if course (e.g. programming error in application running on core #2), but with the given details it will only end into speculations.

Maybe I could give you more explicit hints by posting your MIDI sending routine used for pot events, and the MIDI receiver routine of core #2

Best Regards, Thorsten.

protofuse · November 8, 2009, 1:59pm

issue 1) could happen if your application running on core #1 doesn’t send a complete MIDI event, so that core #2 will freeze until the timeout period has passed.

There are more possible reasons if course (e.g. programming error in application running on core #2), but with the given details it will only end into speculations.

Maybe I could give you more explicit hints by posting your MIDI sending routine used for pot events, and the MIDI receiver routine of core #2

Best Regards, Thorsten.

ok Thorsten.

I ommited to write something. this didn’t happen before… (before what..?!)

I’m quiet sure my code is safe. but “being sure” isn’t the way to follow when you track a bug !!

the code(s) are here:

http://code.assembla.com/protodeck/subversion/nodes/protodeck/protodeck_CORE_1/main.c

http://code.assembla.com/protodeck/subversion/nodes/protodeck/protodeck_CORE_1/main.h

http://code.assembla.com/protodeck/subversion/nodes/protodeck/protodeck_CORE_2/main.c

http://code.assembla.com/protodeck/subversion/nodes/protodeck/protodeck_CORE_2/main.h

there is only one pot that gives me that, the one sending {0xbA, 0x02} from core1.

this is the core that freezes when data flows from core1 from this freaky pot.

protofuse · November 8, 2009, 2:27pm

issue 2) fixed!

it reminds me that: post on the protodeck’s blog about connector

I checked 999times, not 1000 ! bad boy I am!

pots/AIN connector problem!

issue 1) still in tracking!

lylehaze · November 8, 2009, 2:32pm

there is only one pot that gives me that, the one sending {0xbA, 0x02} from core1.

this is the core that freezes when data flows from core1 from this freaky pot.

OK, it seems T.K. nailed the 0xBA, 0x02 bug..

0xBA = Status Byte, Control Change, Channel 11

0x02 = Breath Controller (Coarse)

0x?? = Data Value for Breath Control..

So, it’s looking for another byte of data there..

I have said it before, that T.K. guy knows his stuff!

Have Fun,

LyleHaze

protofuse · November 8, 2009, 2:59pm

OK, it seems T.K. nailed the 0xBA, 0x02 bug..

0xBA = Status Byte, Control Change, Channel 11

0x02 = Breath Controller (Coarse)

0x?? = Data Value for Breath Control..

So, it’s looking for another byte of data there..

I have said it before, that T.K. guy knows his stuff!

Have Fun,

LyleHaze

hello lylehaze,

thanks for your answer.

considering the pots event map of the core1:

{0xbA, 0x01}, {0xbA, 0x02}, {0xbB, 0x01}, {0xbB, 0x02},

{0xbA, 0x03},	{0xbA, 0x04}, {0xbB, 0x03},	{0xbB, 0x04}

why it doesn’t for 0xbB, 0x02 ? oh, wait.. I may not explain enough my stuff… parts of code involved are:

const unsigned char pot_event_map[32][2] = {

		//-------- AIN 11

		// SR1 = instrument control 1 for channels 1-8

		{0xb0, 0x03}, {0xb1, 0x03}, {0xb2, 0x03}, {0xb3, 0x03},

		{0xb4, 0x03}, {0xb5, 0x03}, {0xb6, 0x03}, {0xb7, 0x03},

		// SR2 = send B rate for channels 1-8

		{0xb0, 0x02}, {0xb1, 0x02}, {0xb2, 0x02}, {0xb3, 0x02},

		{0xb4, 0x02}, {0xb5, 0x02}, {0xb6, 0x02}, {0xb7, 0x02},

		// SR3 = send A rate for channels 1-8

		{0xb0, 0x01}, {0xb1, 0x01}, {0xb2, 0x01}, {0xb3, 0x01},

		{0xb4, 0x01}, {0xb5, 0x01}, {0xb6, 0x01}, {0xb7, 0x01},

		// SR4 = send A controls + send B controls

		{0xbA, 0x01}, {0xbA, 0x02}, {0xbB, 0x01}, {0xbB, 0x02},

		{0xbA, 0x03},	{0xbA, 0x04}, {0xbB, 0x03},	{0xbB, 0x04}

};

/////////////////////////////////////////////////////////////////////////////

// This function is called by MIOS when a pot has been moved

/////////////////////////////////////////////////////////////////////////////

void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) __wparam

{

	// send mapped CC value

	MIOS_MIDI_BeginStream(); // midilink encapsulation header

	MIOS_MIDI_TxBufferPut((unsigned char)pot_event_map[pin][0]); // first value from table

	MIOS_MIDI_TxBufferPut((unsigned char)pot_event_map[pin][1]); // second value from table

	MIOS_MIDI_TxBufferPut(MIOS_AIN_Pin7bitGet(pin)); // 7bit pot value

	MIOS_MIDI_EndStream();	// midilink encapsulation tail

}

so the 3rd value is always sent… I GUESS!

could it be an overcurrent issue ?

I write again a very strange thing: it happens when I turn a bit the pot.

not when the value is high at the beginning:

I start the midibox with this pot at 0. it boots correctly, everything works fine. I turn a bit …issue!
I start the midibox with this pot at N>0. it boots correctly, everything works fine. I turn a bit …issue!

T.K · November 8, 2009, 4:22pm

Er… what are you doing in MPROC_NotifyReceivedEvnt() of the second core?

void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam
{
int channelIndex = evnt0-0x90;
int noteIndex = evnt1;
unsigned char value = evnt2;
matrix[8*(noteIndex - 1 + _NOTE_MATRIX_OFFSET)+channelIndex] = value; //-1 cause note begin at 1 and row at 0
}
[/code]









this function will write into a RAM location depending on the received event.



There is no if() branch which filters the expected events, accordingly any received event will write something into the matrix[] array.







Let's assume 0xba 0x02 is received:



channelIndex = 0xba-0x90 = 0x2a (instead of 0xa --- hint: it's better to write "unsigned char channelIndex = evnt0 & 0xf")



noteIndex = 0x2







-\> matrix[8\*(0x2a-1+\_NOTE\_MATRIX\_OFFSET)+0x2a] = value







Thats somewhere outside the array range.. Something random will happen (\*) after this write operation. The effect will change whenever you add new/remove old code.











So, I strongly recomment you to check for the received event -\> if( (evnt0 & 0xf0) == 0x90 )



and to add some additional checks to ensure that matrix[] is never written outside the declared range.







It's also better to use "unsigned char" (8 bit values) instead of "int" (16 bit values) for faster code execution.







The same programming error exists in MPROC\_NotifyReceivedEvnt() of the first core.







Best Regards, Thorsten.







(\*) this could also explain similar "strange effects" that you noticed in the past.

protofuse · November 8, 2009, 4:31pm

Er… what are you doing in MPROC_NotifyReceivedEvnt() of the second core?

void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam

{

int channelIndex = evnt0-0x90;

int noteIndex = evnt1;

unsigned char value = evnt2;

matrix[8*(noteIndex - 1 + _NOTE_MATRIX_OFFSET)+channelIndex] = value; //-1 cause note begin at 1 and row at 0

}

this function will write into a RAM location depending on the received event.

There is no if() branch which filters the expected events, accordingly any received event will write something into the matrix array.

Let’s assume 0xba 0x02 is received:

channelIndex = 0xba-0x90 = 0x2a (instead of 0xa — hint: it’s better to write “unsigned char channelIndex = evnt0 & 0xf”)

noteIndex = 0x2

-> matrix[8*(0x2a-1+_NOTE_MATRIX_OFFSET)+0x2a] = value

Thats somewhere outside the array range.. Something random will happen (*) after this write operation. The effect will change whenever you add new/remove old code.

So, I strongly recomment you to check for the received event -> if( (evnt0 & 0xf0) == 0x90 )

and to add some additional checks to ensure that matrix is never written outside the declared range.

It’s also better to use “unsigned char” (8 bit values) instead of “int” (16 bit values) for faster code execution.

The same programming error exists in MPROC_NotifyReceivedEvnt() of the first core.

Best Regards, Thorsten.

(*) this could also explain similar “strange effects” that you noticed in the past.

Thorsten, I’ll correct it right now and test it … just “after right now”

it is strange that only 1 pot does that…

thanks a lot ! I keep you informed !!

T.K · November 8, 2009, 4:41pm

Thorsten, I’ll correct it right now and test it … just “after right now”

it is strange that only 1 pot does that…

no, this isn’t strange.

Because “random effect” means that something could happen that you won’t notice immediately, or that you will never notice…

In this particular case (when 0xb2 is received) the programming error caused an effect that you noticed immediately: the application crashed, probably because a frequently used runtime variable has been overwritten.

Best Regards, Thorsten.

protofuse · November 8, 2009, 4:45pm

void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam

{

	if( (evnt0 & 0xf0) == 0x90)

	{

	unsigned char channelIndex = evnt0-0x90;

	unsigned char noteIndex = evnt1;

	unsigned char value = evnt2;


		if( (noteIndex - 1 - _NOTE_MATRIX_OFFSET)+channelIndex <= 64)

		{

			matrix[8*(noteIndex - 1 - _NOTE_MATRIX_OFFSET)+channelIndex] = value;

		}

	}

}

the first if is ok, the second one could be improved I guess (bitwise operator ?!)

T.K · November 8, 2009, 4:48pm

It’s better to calculate “8*(noteIndex - 1 - _NOTE_MATRIX_OFFSET)+channelIndex” only a single time, and to put the result into a temporary variable.

Btw.: you forgot the 8* multiplication inside if()

Best Regards, Thorsten.

T.K · November 8, 2009, 4:52pm

Btw.: matrix is declared as:

static unsigned char matrix[32] ;
[/code]









Why are you checking for \<= 64?



I would expect a check for \< 32, since matrix[] is in the range 0..31







Best Regards, Thorsten.

protofuse · November 8, 2009, 4:55pm

It’s better to calculate “8*(noteIndex - 1 - _NOTE_MATRIX_OFFSET)+channelIndex” only a single time, and to put the result into a temporary variable.

Btw.: you forgot the 8* multiplication inside if()

Best Regards, Thorsten.

indeed, ok!

void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam

{

	if( (evnt0 & 0xf0) == 0x90) // being sure that this is a note message

	{

	unsigned char channelIndex = evnt0-0x90;

	unsigned char noteIndex = evnt1;

	unsigned char value = evnt2;

	unsigned char matrixIndex = noteIndex - 1 - _NOTE_MATRIX_OFFSET + channelIndex;


		if (matrixIndex >= 0 & matrixIndex <= 64)// being sure that we'll write inside bounds

		{

			matrix[matrixIndex] = value;

		}

	}

}

I’ll fire it in the gear!