Page 1 of 1
MOD5270 J2, J1 pinouts - confusion
Posted: Wed Mar 27, 2013 1:12 pm
by sehsamudra
Hi, I refer to a PDF document online "MOD5270 Pinout and Signal Description" which shows each pin on the MOD5270 module with Function, Alt. Function, GPIO Port, Description. What is the latest version of this chart ?
I also refer to the PDF supplied with each NBURN installation on a computer, MOD-DEV-70-SCH-R1p7.pdf which shows the MOD-DEV-70 adapter board pinouts. In that document, J2[5] is shown connected, but in the previous chart above, J2-5 is shown NC, and the names/functions of the pins in both documents do not seem to be all the same.
I'm designing new schematics and would like to know how many pins are available for use in the system, and what are the correct names of the pins ?
Thanks.
Re: MOD5270 J2, J1 pinouts - confusion
Posted: Wed Mar 27, 2013 4:03 pm
by rnixon
The data sheet for any of the modules should take precedence. The mod-dev-70 is used for many different modules and is just an eval board for certain features. So I think you should use the module data sheet as the reference for your new design.
Re: MOD5270 J2, J1 pinouts - confusion
Posted: Wed Mar 27, 2013 8:16 pm
by roland.ames
On MOD5270, J2[5] is not connected. I have a copy of the schematic, MOD5270-SCH-R1p1.pdf, and it is clear that this pin is not connected to anything on the MOD5270.
Re: MOD5270 J2, J1 pinouts - confusion
Posted: Thu Mar 28, 2013 8:34 am
by sehsamudra
may I request a quick list of available pins (unassigned) that one could use for a project, if (a) using MOD5270 in a daughter board for bench testing (b) not using MOD5270, but using just the MCPU carrier board by itself as a core module. I suspect we will have more flexibility using the core module, but which pins are broken out from the CPU on those carrier boards that are best left alone ? Some of those pins may be useful for external interfacing (I2C, IRQ ... ) and not just for GPIO.
This could be useful for other customers as well. ...
Thanks for your tips.
Re: MOD5270 J2, J1 pinouts - confusion
Posted: Thu Mar 28, 2013 9:02 am
by dciliske
Can you try to reexplain that? I'm not sure I understand what you're asking for.
Re: MOD5270 J2, J1 pinouts - confusion
Posted: Thu Mar 28, 2013 9:09 am
by rnixon
Yes, the sentence " not using MOD5270, but using just the MCPU carrier board by itself as a core module" is confusing. How would a carrier board be used as a core module? There is no intelligence on the carrier board.
Re: MOD5270 J2, J1 pinouts - confusion
Posted: Fri Mar 29, 2013 7:53 am
by sehsamudra
I was attempting to say that the core module has all the intelligence and some pins available. Which list is the definitive enumeration of those pins? For example, in the current discussion, the
I'm looking for guidance of ok to use for customer projects - given that the development phase requires the core module to be placed into (say) a Mod-Dev-70. Is looking through the schematic the only way to do this? I'm seeking some unassigned pins that would stay that way from development to field testing.
Thanks!
Re: MOD5270 J2, J1 pinouts - confusion
Posted: Fri Mar 29, 2013 8:40 am
by dciliske
So, when the module datasheet says a pin isn't connected (i.e. pin J2[5]), then it's not connected. It does not connect electrically in any way with anything on the module. If it lists items in multiple columns of Functions, then it can serve as any of those functions, and generally also as a GPIO pin (unless it's GND or VCC). You can use whatever pin you like, just don't try to use the same pin for multiple uses.
Do that answer your question? I'm still not entirely sure what you're asking about.
Re: MOD5270 J2, J1 pinouts - confusion
Posted: Sat Mar 30, 2013 12:42 pm
by sehsamudra
dciliske wrote:So, when the module datasheet says a pin isn't connected (i.e. pin J2[5]), then it's not connected.
[... snip ...]
Do that answer your question? I'm still not entirely sure what you're asking about.
I went back and compared the data sheet of MOD5270B and the schematic of MOD-DEV-70. I have highlighted the pins in the attached PDF that I believe are "unassigned" in yellow, and potentially safe to use in my custom application.
Is my analysis correct? I have split out the pins into odd and even series, just in case someone else out there is laying out a PCB board and would like to wire up the signals to various external components with regard to the left/right sides of the 50-pin connectors. I have presented only the J2_C connector here, and now would like to ask if there is any recommended application note that summarizes the methods for utilizing those "yellow" pins at the beginning of a embedded application, or if the document "MOD5270 GPIO Configuration" is the only guide available.
Also: In the MOD-DEV-70, is J5's IRQ5- a different signal than J2[47]'s IRQ5- function?
I think you see what I was asking: during the development of a circuit, based upon the combination of these two systems, it is not readily apparent that not all of the pins of the MOD5270B are connected/utilized and neither are those of the MOD-DEV-70 module. As the modules themselves may have different revision numbers, any number of board changes might fundamentally affect a hardware development project (and also cause the software application to be rewritten to accomodate different pin assignments) that spans a few months, in which the product(s) are gradually prototyped.
For example, I used SB70LC module initially to get my precision timing circuit running, but now have to change the pin assignments to accommodate the pins that I have at my disposal. I have to also create a quick cheat sheet to accommodate the programming tips mentioned in the appnote for MOD5270 pinio, but I believe it would be useful to have commonality between the two frameworks (if they don't exist already) so we can test small and then test big, and then test with our own stand-alone interface board. The ultimate version of any product is just to use the application code on a stand-alone mainboard with just the CPU and its required peripherals running with a Netburner license, but that is a long way off from me at this point. With such a goal, it would be nice IMHO if we didn't have to keep changing code from one platform to another, or from one revision of the systems to another. Any tips in this regard, please?
Also, it would help in the verification and validation phase of things, if this were to be submitted to any certifying authority, I think.
Regards
//n3rdx @GWU