The PIC-IoT WG development board (part number EV75S43A) is a Microchip-designed evaluation platform that integrates a 16-bit PIC24 microcontroller, an ATWINC1510 Wi-Fi module, and an ATECC608 secure element to provide out-of-the-box, cryptographically secure cloud connectivity for IoT prototypes. In a real installation, this board changes the deployment workflow by replacing a multi-chip BOM and manual certificate injection with a single pre-provisioned module, cutting secure cloud provisioning time from days to minutes. Makers and engineers commonly confuse this board with generic ESP32 development kits or the similar PIC-IoT WA variant; unlike the ESP32, which typically handles TLS in software and stores private keys in readable flash, the WG board uses a dedicated silicon root-of-trust, and unlike the WA (Amazon AWS) variant, the WG is pre-configured for Google Cloud IoT Core and Azure.
Silicon Architecture and Component Specifications
To understand why this board exists, you have to look past the main processor. The EV75S43A is not just a microcontroller breakout; it is a tightly coupled secure telemetry node. The physical layout deliberately places the RF-sensitive WINC1510 module away from the digital switching noise of the PIC24 MCU, while the ATECC608A cryptographic co-processor and MCP9808 temperature sensor sit on a dedicated I2C bus to minimize trace length and capacitance.
When designing a custom carrier board or debugging the evaluation kit, you must treat these as three distinct power and communication domains. The Wi-Fi module uses SPI, while the security and sensor elements use I2C. Below is the exact silicon breakdown you will find on the board.
| Component | Part Number | Primary Function | Key Specification | Typical Active Current |
|---|---|---|---|---|
| Host MCU | PIC24FJ128GA406 | Application logic, sensor polling, MQTT payload formatting | 16-bit, 32 MHz, 128KB Flash, 8KB RAM | ~12 mA @ 32 MHz |
| Wi-Fi Network Controller | ATWINC1510 | 802.11 b/g/n connectivity, TCP/IP stack offload, TLS termination | 2.4 GHz, SPI interface, integrated PA/LNA | ~140 mA (TX), ~65 mA (RX) |
| Secure Element | ATECC608A | Hardware root-of-trust, private key storage, ECDSA signature generation | I2C interface (Addr: 0x60), 16 key slots, EEPROM | ~5 mA (during crypto op) |
| Temperature Sensor | MCP9808 | Ambient environmental telemetry for cold-chain or HVAC monitoring | I2C interface (Addr: 0x18), ±0.25°C accuracy | ~200 µA (active), ~0.5 µA (shutdown) |
The Math: Hardware Crypto vs. Software Emulation
Why include a dedicated ATECC608A crypto chip when the PIC24 has some hardware acceleration and the WINC1510 supports TLS natively? The answer lies in key storage security and execution efficiency. If you use a standard ESP32, your private TLS key is stored in the SPI flash memory. If an attacker gains physical access to the device, they can dump the flash and extract the key, allowing them to spoof your device on the cloud network. The ATECC608A generates the private key internally and never allows it to be read out. The host MCU only sends a hash to the chip, and the chip returns the signature.
Let us look at a worked numeric example to see how this affects power budgets in battery-operated telemetry nodes. When establishing a secure MQTT connection, the device must perform an ECDSA (Elliptic Curve Digital Signature Algorithm) sign operation to prove its identity to the cloud broker.
- Software Implementation: If the PIC24FJ (running at 32 MHz) attempted this via a software crypto library like MicroECC, the math-heavy elliptic curve operations would take approximately 1,800 ms of continuous CPU execution.
- Hardware Implementation: The ATECC608A has dedicated silicon for this exact math. It generates the ECDSA signature in roughly 115 ms.
By offloading to the ATECC608A, the MCU saves 1,685 ms of active execution time per handshake. At an average active MCU current of 15 mA, this saves roughly 25.2 µAh of battery capacity per connection event. If your sensor node wakes up to transmit every 15 minutes (96 times a day), that single hardware optimization saves 2.4 mAh per day, or nearly 1 Ah over a year. In a low-power IoT deployment running on a 2000 mAh 18650 cell, this math is the difference between a 1-year and a 2-year battery life.
Where You Meet This In Practice
You will typically encounter the PIC-IoT WG architecture in commercial environments where device spoofing could cause physical damage, financial loss, or regulatory violations. Common deployments include:
- Cold-Chain Pharmaceutical Monitoring: Tracking vaccine temperatures in transit. If a competitor or negligent driver could spoof the telemetry data to hide a temperature excursion, the payload is worthless. The ATECC608A ensures the cloud knows the data came from the specific, calibrated sensor on the truck.
- Smart Grid Metering: Utility companies use hardware-rooted identities to prevent malicious actors from injecting false load-balancing data into the grid management system.
- Industrial Motor Telemetry: Vibration and thermal sensors on high-value CNC machines or pumps, where a spoofed 'all-clear' signal could result in catastrophic bearing failure.
The most frequent hardware issue engineers face when moving from the EV75S43A evaluation board to a custom PCB is Wi-Fi module brownout. The ATWINC1510 can draw peak transient currents up to 350 mA during RF transmission bursts. If your custom carrier board relies on a standard USB port (limited to 500 mA total) or a weak linear regulator without adequate local decoupling, the voltage rail will dip below the WINC1510's 3.0V minimum operating threshold. The module will reset mid-transmission, dropping the TLS session and forcing a full, power-hungry re-authentication. Always place a 100µF low-ESR tantalum capacitor and a 100nF MLCC within 5mm of the WINC1510 VCC pins.
Provisioning and Debugging the Secure Element
The true power of the PIC-IoT WG development board is its support for Just-In-Time Registration (JITR) or Zero-Touch Provisioning. When the board boots and connects to Wi-Fi, it presents a device certificate signed by Microchip's manufacturing CA. The cloud provider (e.g., AWS IoT Core or Google Cloud) recognizes the Microchip CA, verifies the signature via the ATECC608A, and automatically registers the device in your IoT registry without you ever manually typing a serial number or uploading a PEM file.
When debugging the board via the MPLAB X serial console (typically at 115200 baud via the onboard UART-to-USB bridge), you should watch for the following sequence to verify the secure element is functioning:
- ATECC608A Initialization: Look for the I2C wake-up sequence. The chip requires a specific low-level pulse on the SDA line to wake from sleep mode before the first I2C transaction. If your logic analyzer shows NACKs on address 0x60, your I2C bus is missing the wake condition.
- WINC1510 Firmware Check: The board will print the Wi-Fi firmware version (e.g., 19.7.6). If you are connecting to modern cloud brokers that enforce TLS 1.2 with strict cipher suites, ensure your WINC1510 firmware is updated via the Microchip firmware upgrade tool. Older firmware versions will fail the TLS handshake silently, resulting in a socket timeout error rather than a clear cryptographic rejection.
- MQTT Publish Verification: Once connected, the board publishes a JSON payload to a shadow topic. Verify that the payload includes the 'secure' boolean flag set to true, confirming the TLS handshake completed using the hardware-backed private key rather than a software fallback.
Ultimately, the PIC-IoT WG is not just a learning tool; it is a reference design for how modern, secure IoT nodes must be architected. By separating the application logic, the RF transmission, and the cryptographic root-of-trust into three specialized silicon domains, it provides a blueprint for building telemetry systems that survive both physical tampering and network-level spoofing.
