AXON ICM-GE

How Does the AXON ICM-GE Use the WIZnet W5500 for Industrial Ethernet Access Control?

AXON Access | W5500 | STM32 | Industrial IoT | Ethernet | Access Control

1. Summary

The AXON ICM-GE is an industrial access-control master developed by AXON Access in Kosovo. Its published hardware specification identifies the WIZnet W5500 as the SPI-connected Ethernet controller for an STM32H743VIT6-based system. The W5500 provides the TCP/IP transport used for MQTT over TLS communication with the central management server, supporting credential database synchronization, access-event reporting, and firmware updates. Access decisions are performed locally using an onboard database, allowing authorized access control to continue during internet outages.

2. What the Project Does

Industrial access control without continuous cloud dependency

The AXON ICM-GE is designed to manage access points outside elevator cabins, including building entrances, internal doors, floor landings, parking gates, and garage entrances.

In a conventional cloud-dependent architecture, validating credentials may require communication with a remote server. A network outage can therefore interrupt the authorization process.

The ICM-GE addresses this problem by maintaining its credential database locally and separating access-control decisions from cloud communication.

When a user presents an access card, a reader sends the credential information to an AXON Node. The node forwards the request to the master controller, which checks the stored credential, access permissions, and validity period.

The master then returns a grant or deny decision. The management server handles database updates, event collection, and remote management rather than participating in every access decision.

Hardware architecture

The June 2026 hardware specification identifies the following components and capabilities.

The published system specification also identifies:

These values come from the manufacturer's June 2026 system specification. The access-decision target is not presented as a benchmark measurement.

System data flow

The central architectural distinction is that Ethernet communication is separate from the local access-decision path.

The W5500 supports remote communication, while the STM32 and local database perform access authorization. Consequently, the access-control function does not require an active cloud session for every credential check.

3. Where WIZnet Fits

Evidence of actual W5500 adoption

AXON's official ICM-GE product specification explicitly identifies the W5500:

“A W5500 Ethernet controller on SPI is the master's preferred path to the AXON cloud.”

The same specification identifies the Ethernet interface as W5500 10/100 with RJ-45 connectivity and describes MQTT/TLS communication on TCP port 8883.

The WIZnet Makers project record published on October 26, 2026 independently documents these product-level details and identifies the STM32H743VIT6, W5500, and M95P32 components.

The evidence therefore establishes that the W5500 is part of the published ICM-GE hardware design. It does not independently establish the component population of every production PCB revision.

Why the W5500 is technically relevant

The W5500 integrates a hardwired TCP/IP stack, Ethernet MAC/PHY, and an SPI host interface.

Its principal capabilities include:

These functions reduce the amount of general-purpose TCP/IP processing that needs to run directly on the MCU.

For the ICM-GE, this matters because the STM32 also handles local credential lookups, access policies, CAN messages, event logging, and device management.

The W5500 supports the system in three specific areas.

TCP/IP transport processing. The controller manages hardware socket operations and packet buffering for the Ethernet uplink. This allows the application to use a dedicated network interface rather than implementing all supported TCP/IP functions in MCU software.

Database synchronization and event reporting. The management server can deliver updated access permissions and receive access events using MQTT over TLS, transported over the W5500 Ethernet connection.

Remote firmware management. The Ethernet uplink can carry firmware update data. Image validation, firmware-bank switching, and update recovery remain responsibilities of the MCU firmware.

The W5500 does not implement MQTT or TLS encryption internally. These functions require software running above the W5500 TCP transport layer.

Likewise, hardware TCP/IP offloading does not establish that access decisions are deterministic or guarantee a particular response time. The published sub-2 ms access-decision target relates to the local authorization architecture, not W5500 Ethernet latency.

4. Implementation Notes

Hardware connectivity

The published ICM-GE specification confirms that the W5500 connects to the STM32 through SPI.

A standard STM32-to-W5500 interface uses the following signals:

The AXON publication identifies SPI as the interface but does not provide the complete GPIO mapping, W5500 clock configuration, or interrupt assignments.

Therefore, these signals describe the required interface architecture rather than a verified pin-by-pin ICM-GE connection.

Network configuration

The published Ethernet uplink configuration includes:

The design permits a dedicated Ethernet switch port or managed VLAN, which is useful for isolating access-control infrastructure from general building traffic.

Firmware and driver evidence

The accessible AXON materials describe the controller's architecture and network functions, but a complete public firmware repository and PCB schematic were not available for inspection.

As a result, the actual W5500 driver implementation could not be verified.

In particular, the published sources do not establish the exact SPI initialization routine, W5500 socket-buffer allocation, interrupt configuration, or MQTT/TLS library.

WIZnet ioLibrary is an available implementation option for this class of design, but its use in AXON ICM-GE has not been confirmed.

Separation of local access control and cloud communication

The published architecture follows this sequence:

The manufacturer's specification states that the local decision path does not require a cloud round trip.

However, the manufacturer also identifies durable event-log retention across a power interruption as a feature under development. Network-outage tolerance should therefore be distinguished from guaranteed preservation of every event during a power failure.

CAN and RS-485 architecture

The current ICM-GE product specification describes two independent Classic CAN buses between the master and the AXON Nodes.

The associated access readers communicate with the nodes over secured RS-485 connections.

This distinction matters because the earlier May 2026 AXON technical guide describes an RS-485-based node-bus architecture, while the June 2026 product specification provides a more specific CAN-based configuration.

The hardware implementation described here follows the later ICM-GE product specification. Installers should confirm the appropriate bus architecture for the exact board and firmware revision before selecting cabling, termination, or compatible nodes.

5. Practical Tips and Pitfalls

- Verify SPI wiring and reset sequencing. Check the actual SPI peripheral, chip-select timing, reset control, and W5500 supply requirements against the production schematic. The published product documentation does not provide a complete pin map.

- Monitor Ethernet link and MQTT session states separately. A valid PHY link does not guarantee IP connectivity, TLS authentication, or an active MQTT session. Each condition requires independent diagnostics.

- Choose DHCP or static IP deliberately. Both are described in the AXON specification. Static addressing may simplify diagnostics in managed industrial networks, while DHCP requires appropriate lease and address-reservation policies.

- Treat the 32 KB W5500 buffer as a shared resource. Its TX/RX memory must be allocated across hardware sockets. The appropriate allocation depends on actual socket usage and packet sizes; the AXON buffer configuration has not been published.

- Validate CAN termination and segment loading. The June 2026 specification identifies two independent 250 kbit/s buses with 120Ω termination at both physical ends of each segment. Confirm cable topology, node addresses, power distribution, and electromagnetic interference conditions during installation.

- Test communication and power failures separately. Disconnect the Ethernet uplink, interrupt the CAN network, and power-cycle the controller in distinct tests. Local access continuity during internet failure does not automatically establish event-log durability during power loss.

- Verify TLS and OTA security in firmware. The W5500 supplies TCP/IP transport but not TLS cryptography or firmware authenticity checks. Certificate validation, update verification, and recovery behavior must be confirmed at the application level.

6. FAQ

Q1. Why was the WIZnet W5500 selected for the AXON ICM-GE?

The AXON specification identifies the W5500 as the controller for its primary Ethernet uplink. The W5500 provides 10/100 Mbps Ethernet connectivity and hardware TCP/IP socket processing over SPI, reducing the network-stack responsibilities handled directly by the STM32. This is relevant to a controller that must also process credential validation, CAN communication, and access events. AXON has not published a quantified CPU-load reduction attributable to the W5500.

Q2. How does the W5500 connect to the STM32 controller?

The W5500 communicates with the STM32H743VIT6 through SPI. Standard connections include SCLK, MOSI, MISO, CS, and RESET, with an interrupt signal available for event handling. The exact STM32 GPIO assignments and SPI frequency used by AXON have not been disclosed in the accessible technical materials.

Q3. What exactly does the W5500 do in the access-control system?

The W5500 provides the Ethernet TCP/IP transport between the ICM-GE master and the AXON management server. This connection carries credential database synchronization, access-event reporting, telemetry, and firmware update data. It does not validate credentials or operate door relays directly. Those functions belong to the STM32 master and its associated access nodes.

Q4. Can beginners build a similar system using the W5500?

Developers familiar with SPI, embedded C, and basic TCP/IP networking can begin with WIZnet ioLibrary and a supported MCU development board. Reproducing a complete industrial access-control system is considerably more involved because it requires secure credential handling, CAN networking, local storage integrity, reliable power management, and recovery from communication failures. The publicly accessible ICM-GE materials are not a complete build tutorial.

Q5. Does using the W5500 guarantee access-control operation during an internet outage?

No. The W5500 supplies the Ethernet interface but cannot independently maintain access authorization when the cloud is unavailable. The ICM-GE remains operational during internet outages because the STM32 performs credential verification against a locally stored database. The W5500 is used to restore synchronization and transmit management information when the network connection returns.

7. Source

Project: AXON ICM-GE — AXON Master
Developer: AXON Access
Location: Prishtinë, Kosovo
Application: Building and industrial access-control infrastructure

Original project and supporting documentation

License: No public open-source license for the AXON ICM-GE firmware or PCB design was identified. Product documentation is publicly accessible, but its availability does not establish permission to reproduce or redistribute proprietary firmware and hardware design files.

Hardware revision note: The W5500 is explicitly documented in the manufacturer's published ICM-GE hardware specification. Public materials do not independently establish that every shipped hardware revision uses the same Ethernet controller. The May and June 2026 technical descriptions also differ in their treatment of the master-to-node fieldbus; the later product-specific CAN architecture is used in this article.

8. Tags

#W5500 #WIZnet #AXONICMGE #STM32 #IndustrialIoT #Ethernet #MQTT #TCPIP #AccessControl #CANBus #SmartBuilding #OfflineAccessControl