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

[protofuse]

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...

Edited November 9, 2009 by protofuse

[baptistou]

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]

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]

hello experts,

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

1) 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?

2) 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]

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 :-(

[TK.]

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]

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]

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.

[TK.]

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]

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.

Edited November 8, 2009 by protofuse

[protofuse]

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]

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]

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!

Edited November 8, 2009 by protofuse

[TK.]

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]

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 !!

[TK.]

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]

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 ?!)

[TK.]

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.

[TK.]

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]

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!

Edited November 8, 2009 by protofuse

[TK.]

I don't think that it will compile this way (there is a missing bracket)

Why are you checking for <= 64?

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

And why do you multiply by *8?

There are 16 channels... somehow I'm missing a clear concept.

It makes sense to add a comment what actually the function should do, and what are the constraints.

This would make it easier for others to find out what's wrong in the code.

Or it could even help you to find the error by yourself ;)

Best Regards, Thorsten.

[protofuse]

you're right ... 64 is for the other matrix!

[protofuse]

I don't think that it will compile this way (there is a missing bracket)

Why are you checking for <= 64?

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

And why do you multiply by *8?

There are 16 channels... somehow I'm missing a clear concept.

It makes sense to add a comment what actually the function should do, and what are the constraints.

This would make it easier for others to find out what's wrong in the code.

Or it could even help you to find the error by yourself ;)

Best Regards, Thorsten.

yes, I corrected that...

for the midi note / led mapping, I had to redo little things.

the second test about the matrixIndex gives me a warning:

warning 94: comparison is always true due to limited range of data type

grrr.

explicit cast is required?

[protofuse]

the compilation of this code gives me warning 94: comparison is always true due to limited range of data type for the second if() statement.

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 < 32)	// being sure that we'll write inside bounds

		{

			matrix[matrixIndex] = value;

		}

	}

}

same warning if I cast like that :

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 int matrixIndex = (int) ( noteIndex - 1 - _NOTE_MATRIX_OFFSET + channelIndex );


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

		{

			matrix[matrixIndex] = value;

		}

	}

}

any suggestions?

Edited November 8, 2009 by protofuse

[protofuse]

this code doesn't give me any warning :smile: :

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

// This function is called by MIOS when a complete MIDI event has been received

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

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;

		}

	}

}

Thorsten, the 8* was to manage my leds like that:

- one midi channel per column

- one note pitch per line

- velocity gives the color

but it needs to be improved and finished.

btw, now, I can write at last : EVERYthing works fine here!

and, the most important, I understood why the different things that gave me headache didn't work in the past !!!

thanks to all of you (I already do that on my website )