VOXL J13 B2B Clarifications

Thomas MacNamara

Hi, I have a few questions regarding some of the pins on the B2B connector.

Pins 2, 4 and 6 are listed as VDCIN_5V_CONN, does that mean we could use these pins to power the VOXL
Are pins 12 and 14 the minus and plus signals respectively for the USB2 port
We would like to be able to break out some of the GPIO is there any of the listed ports that would be better to use then others?
Are the UART and i2C ports in the VOXL ecosystem? The documentation tends not to mention j13.

I realize questions 3 and 4 are very realated to https://forum.modalai.com/topic/635/voxl-b2b-port-connections-questions?_=1644888153272 but I thought I would clarify how we would be using them if that made any difference. They would be only for VERY simple things like communicating with arduino like devices or reading pots.

There seems to be more detailed documentation for the Snapdragon Flight here:
https://developer.qualcomm.com/qfile/33889/snapdragonflight_b2b_user_guide_v2_feb2017.pdf

But I don't want to design a whole PCB on an assumption that the implementations are the same.

Background: We are designing an all in one power-over-ethernet, usb to ethernet and voltage regulator daughterboard in order to keep the footprint of the VOXL small when running of a passive POE connection. (underwater means that the less cables the better and completely rules out running off the wireless)

Thanks and sorry once again for asking weird questions for our weird usecase

Vinny

Hi Thomas,
Great "weird" questions (they are not weird and we love your use case BTW ) and thanks for asking them here on the forum. I'm glad you referenced that other post since I'll refer to some of those constraints here, so you can see from both SW and HW some of the limitations.

In order:

We have those pins designed more for power-tap-off, such as when installing our Modem or Microhard designs. It is technically a near-direct-connect to the power module input connector J1, but due to common mode filters we have on the prime input, this source is not ideal for powering the Voxl due to ground return path design, current handling capacity, and it is not tested and validated with our ecosystem as such. We do use it on occasion for test modes, but that is all we suggest limiting it to. You can short out the power module this way too, so be warned .
I'm not aware of the power capabilities of all POE applications. I would not trust you can deliver 30W burst for power-on in-rush that our power module over J1 provides.
Yes, this is the second USB port on the Applications Processor, and those are indeed -/+ as you say. This is the data path to Modems and Microhard radios. If you notice our diagrams https://docs.modalai.com/microhard-add-on-datasheet/#block-diagram, we use that as the USB to ETH with NDIS for the Microhard radio. FYI, this port is HOST mode only, not OTG, so pin 8 should be ignored/Do Not Connect.
Yes, depending on what you want to do. You have four scenarios to pay attention to:
3a) We certainly would prefer you avoid the following at all costs:

GPIO_70 (some deep software that even we cannot override blocks access)
GPIO_114, GPIO_104, GPIO_103, GPIO_102, GPIO_101, GPIO_57 (these are core config signals, as per that old 2017 Snapdragon Flight doc (which I authored BTW ) and can brick your system if not dealt with properly)
GPIO_4, GPIO_5 (debug UART disabled by default, so not sure if the GPIOs are also blocked)
3b) We know these are usable, but you may need to override some of the ModalAI SW which uses these for our Modems and Microhard designs (refer to that same block diagram above to see some of them):
GPIO_106, GPIO_107, GPIO_108, GPIO_72, GPIO_71
3c) These "should" be free. What I mean is that we do not use them, but we also do not know if they will work they way you need them to, so be sure you provide backup options. There may be some more of those "GPIO_70" issues lurking so use some series resistor options to change them if needed:
GPIO_92, GPIO_94, GPIO_95, GPIO_96, GPIO_64, GPIO_127, and GPIO_126
3d) These are BLSPs, related to your question #4, that when not configured for an alternate mode, should be free for GPIOs.
GPIO_61, GPIO_60, GPIO_59, GPIO_58, GPIO_7, and GPIO_6
3e) Another option, something we do too to avoid GPIO system image blockages, is if there is a known I2C port not used on one of the side Voxl connectors (J7, J11, or J10), consider using an I2C to GPIO expander. We know those I2C ports work great.

We need to update our docs with some of these constraints, so I'll be sure to work on that.

Yeah, that is the other thread, where we "intended" to use those as BLSP11 and BLSP8 UART/I2C expansion and some GPIOs during early design phases, but the system image as noted in that posting never enabled them, and I do not think it's an easy change. We've had customers ask, but it's not technically a HW limitation as the other thread states, but more of a system image (which is deep SW we do not modify anymore) limitation. When you see features in our diagrams using those ports, we are really not. It's just added hardware stuff we have/had and recently started DNI'ing those parts impacted, such as the INA231 and A71CH on the Microhard diagram.... those are not actually installed.

My old Snapdragon Flight document you found on the developer forum at Qualcomm regarding J3 has a lot of similarities to Voxl J13 due to the fact we originally designed them to be compatible. However, Voxl has some key differences in pin numbers and port usage, but the prime PWR/GND/USB and core control signals do match up with the system functions which allowed us to use the same testing and debug hardware across both platforms. However, just please go by our docs as they are relevant to Voxl. The QCDF doc has no consideration for Voxl.

If you want to further our support by having us review your plug-in board schematic design, we'd be happy to make sure you got it right. Follow-up with us. We have many customers we've signed NDAs with for this purpose. Just use the other contact process on our website https://www.modalai.com/pages/contact-us so we can get you directed to the right person to initiate that, and I'd be the one ultimately reviewing it and providing feedback.

Thanks!
Vinny

Thomas MacNamara

Hi Vinny,

Thank you for such a detailed set of answers!

In response to your points:

We will just make a super short connector between the daughterboard and J1. I did like the elegance of a single board that snapped on and did everything we wanted but this really won't add much to the footprint. We are running 12v passive power over ethernet so we will make sure that per the docs there is a nice supply of 5v 6a for the j1 port.
Yep just making sure, this will be shunted strait into a usb-to-ethernet setup (based on the rtl8153-cg chip), depending on how annoying the GPIO stuff might be we did think about simply putting a tiny powered usb hub onto the daughterboard and breaking out a usb connection in order to do those tasks (a little more effort to implement but more flexibility)
Ooof that is a bit of a minefield isn't it? The BLSPs do look to be the best choice if we go with the GPIO idea.
In light of this it might not be that bad an idea to go with the USB microhub idea, that way it would not be hard to implement another discreet microcontroller to deal with any realtime/gpio tasks and simply package that up into a nice neat message to pass upstream.

We will do a bit of planning and let you know where we got to.

Regards,
Thomas