MOD54415 GPIO as inputs

[jediengineer]

Hi all,

I'm a bit confused about using the GPIO as inputs. I'm trying to use J1[9] as an input in my design, but am not having luck. I've set the pin as an input as such:

Code: Select all

J1[9].function(0);

// GPIO

and even tried it as a tristate using

Code: Select all

J1[9].hiz();

I have nothing connected to the pin, and when I read it using an if() statement, it always comes up as high (

Code: Select all

if(J1[9]){}

. I've confirmed it with a multimeter as well. I'm not sure if there's anything I'm missing or not but can someone shed some light on this?

I also noticed in the pinconstants.h that there are 2 modes to this pin, but there were no comments in the code to explain it. Any ideas?

[rlupish]

Try
if (J1[9].read()) { }

Worked for me

[jediengineer]

Tried that too. Same result. I have a mux that switches through 32 inputs, and in between, pin J1[9] is supposed to be reading that mux input. I'm getting the switching, and seeing the inputs change, but for some reason pin J1[9] seems to be stuck high. I'm going over everything I can now to make sure I'm not doing something dumb with this, but so far, its straight forward....

[jediengineer]

In the last 10 minutes, this is what I've done to investigate the problem:

I've disconnected the only connection to J1[9] - it is now floating. I've soldered a wire to the output of my MUX, and connected it to a DMM. In my code, I inserted a 2 second delay inbetween mux channel switching commands. When the unit runs, it now selects the MUX channel, holds it for 2 seconds, then switches again, holds, etc. According to my DMM, and Logic analyzer, the mux is switching correctly, and outputs are swinging as they should. J1[9] is holding constant at 3.3V as far as my scope and logic probe can tell. What would cause that to happen? Is this just an incorrect setup? Again, my setup is this:

Code: Select all

J1[9].function(0);
J1[9].hiz();   // tried once or twice, didn't make a difference like I thought it would 

and this is what I'm doing to check the input:

Code: Select all

		// poll all mux positions
		for (BYTE i = 0; i < 32; i ++)
		{
			J2[33] = 0;															// enable IO
			MUX_Tx[2] = i;                                             			// writes the incremented position to OLAT of the 8b breakout
			J1[5] = 0;															// MUX CS line drop
			J1[6] = 0;															// MUX WR line drop
			J1[7] = 1;															// MUX EN line high
			DSPIStart(1, MUX_Tx, MUX_Rx, 3, NULL, true);						// Data to GPIO breakout to switch mux
			while(!DSPIdone(1));												// release when done
			OSTimeDly(TICKS_PER_SECOND*2);										// delay for port testing
			if (J1[9].read()) MUX_OUT[i] = MYSYS_FAULT_FOUND;					// loads a "pin on" value (chosen so as not to be 1 or 0)
			else MUX_OUT[i] = MYSYS_NO_FAULT;									// loads a "pin off" value (chosen so as not to be a 1 or 0)
			J1[6] = 1;															// MUX WR line high
			J1[5] = 1;															// MUX CS line high
			J1[7] = 0;															// MUX EN line drop
		}

[rhopf1]

Try this before using the pin:
J1[9].function(PIN_GPIO);

[roland.ames]

check which rev of the MOD54415 you have, as J1[9] and J1[10] were changed from 1.8 onwards


see http://www.netburner.com/support/docume ... ignals-fix
specifically the byte write steering signals.

in c:\nburn\MOD5441X\include\pinconstant.h

Code: Select all

#ifndef MOD54415_PIN_CONSTANT
#define MOD54415_PIN_CONSTANT

//#define ENABLE_BE2_BE3      ( 1 )   // Uncomment only for MOD54415 H/W Revision 1.7 and earlier

[pbreed]

This is most likely a revision issue between the code and the PCB.
J1[9] and J1[10] got changed and I'm pretty sure that the code did not.

Sumbit a ticket with the hardware and software revision and we will get this fixed.

[jediengineer]

Thanks Paul and Roland. I do know there were some revisions. I'm using the version 1.6 board at the moment, I uncommented line 35 of pinconstant.h and rebuilt the library already and that didn't do the trick, but I am working with someone through a ticket at the moment. I did have luck using it as an output though so I may just switch my hardware around for the time being. I'll update you later today. Just a side note, I did a little surgery on my prototype board. I cut all traces to J1[9] and connected my MUX output to J2[32]. I changed the pin number in my code and it works perfectly. Going back to J1[9] caused the same issue on 2 version 1.6 boards. Like I said, I'll update you later today, possibly monday if I don't get to it today and let you know if it has been solved. Thanks again for all the help!