Development and production programmers for AES-MS-MT3620-M-G-2-TR

Hi Paul,

Sorry I did not see this question earlier.  The most direct path to developing a product that will leverage the Avnet Azure Sphere Module is to use the Avnet Azure Sphere Starter Kit.  The Starter Kit uses the same Azure Sphere Module, and code developed on the Starter Kit can run on the final production unit (assuming you use the same hardware interfaces) with zero changes.  Additionally, the Starter Kit has flexible expansion slots that make connecting external sensors and other hardware easy to accomplish.

Check out our Blog with all the Avnet Azure Sphere content here on E14:  Avnet Azure Sphere Resources | element14 | Azure Sphere

Let me know if I can help in any way,

Brian

Thanks Brian!  That helps and is appreciated!

Can you elaborate more on a suggested solution for a production programmer?  Our customer is looking to do about 25K/year of these in production.

Thanks again!

Paul

When you're planning your Azure Sphere production work flow you need to plan for manufacturing tasks/tests that require accessing the Azure Sphere device from a Windows10 PC.  The Azure Sphere PC software tools require the use of a USB-to-UART interface chip that exposes these interfaces to a PC in a way that allows the tools to recognize and interact with the Azure Sphere device.  Additionally, these tools require that the interface be implemented with the FTDI T4232HQ UART-to-USB interface chip. Microsoft has some documentation on this interface here.

There are two approaches to consider . . .

Approach #1: Include the FTDI device on your final product

With this approach the FTDI interface is included on the final production unit.  The connector could be external to the unit or hidden inside the unit.

Pros:

• Provides the interface for production activities
• Provides the interface for field technicians if needed

Cons:

• Adds BOM cost for all units
• Exposes the interface for non-authorized technicians
  • Note unless the user had access to the devices Azure Sphere Tenant, there not much they could do with the unit other than wipe it clean or manage wifi networks.

Approach #2: Provide connectivity (connector/socket) on the product for an external FTDI programming board

Pros:

• Reduces BOM cost for all units
• Does not expose the interface for non-authorized technicians, of course clever engineers will always find a way!

Cons:

• Requires additional board design with FTDI device and some type of interface cable or socket to connect to production units

Alternative approach

I guess you could also develop a test fixture that you could drop one of the Avnet Azure Sphere modules into that connects to the correct pins to connect a FTDI device on the test fixture.  I don't see this as a preferred option because you'll want to run functional tests on your final production units so you would likely still need to implement one of the first two approaches.