Holyiot 21011 (nRF52810)

Curiosity

Il fratello minore del 25008: stesso produttore, stessa idea (beacon iBeacon CR2032 programmabile), ma chip nRF52810 invece del nRF54L15. Formato rettangolare 41.5 × 31.5 × 10 mm (il 25008 è tondo Ø30).

✅ Al banco: SWD APERTO e firmware dumpato — come il 25008. Holyiot non protegge nessuno dei suoi beacon: due modelli, due chip, entrambi spalancati.

🛒 AliExpress — Holyiot Official Store · €10.69 · modello HOLYIOT-21011

Specs

⚠️ Il nRF52810 non è un nRF52840. 192 KB di flash contro 1 MB, 24 KB di RAM contro 256 KB, niente FPU. Ma per un beacon non conta: il firmware Visla ci gira uguale — il limite reale è la RAM al 92% (vedi sotto).

🔍 Come si distinguono i 5 beacon dell’ordine

L’UUID iBeacon NON serve: è identico su tutti (FDA50693-..., Major 10011, Minor 19641). Servono altri tre discriminanti:

Formato del service data — protocolli proprietari diversi:

Holy-IOT (21011):       41 | 64 | c0 9a c2 7d a0 68 | 04 06 06 00 00
NexBeacon Pro (25008):  01 | f2 28 39 2b 62 c1 | 04 | 64
                        ↑ byte iniziale, lunghezza e UUID diversi

Via SWD — l’ID del debug port distingue il silicio:

0x2BA01477  →  Cortex-M4  (nRF52810)    ← CoreSight vecchio
0x6BA02477  →  Cortex-M33 (nRF54L15)    ← CoreSight nuovo

💡 Il nome NexBeacon Pro è il nome dell’app di configurazione Holyiot → è così che si riconoscono i 25008.

📡 Cosa fa al banco (16/07/2026)

Due esemplari visti, entrambi con nome advertising Holy-IOT:

Holy-IOT   RSSI -43   svc 0x5242: 41 64 c0 9a c2 7d a0 68 04 06 06 00 00
Holy-IOT   RSSI -38   svc 0x5242: 41 5f e0 93 9b 18 c7 f8 04 06 06 00 00
                          └┬┘ └────── MAC ──────┘
                        batteria (0x64=100%, 0x5f=95%)

• ~0.7 advertising/s (i 25008 stanno a 1.0/s)
• Service data proprietario su UUID 0x5242 — diverso dal 0x180A usato dai 25008
• Uno ha MAC pubblico (C0:9A:C2:7D:A0:68), l’altro random-statico → il primo è un ID stabile per sempre, comodo per l’arm/disarm ma tracciabile

🔁 Clonati come tutti gli altri

Stesso identico iBeacon degli altri 4 beacon dell’ordine:

UUID  FDA50693-A4E2-4FB1-AFCF-C6EB07647825    ← il default più diffuso al mondo
Major 10011   Minor 19641   TxPower@1m -55 dBm

Per Visla vanno resi unici. Sul 25008 il problema è stato risolto leggendo il device ID dal silicio (hwinfo): stessa strada qui.

🔓 SWD: APERTO ✅ (banco 17/07/2026)

VTref = 3.295 V
Device "NRF52810_XXAA" selected
Found SW-DP with ID 0x2BA01477      ← ≠ 0x6BA02477 del nRF54L15: CoreSight più vecchio
AP[0]: AHB-AP (IDR: 0x24770011)
AP[0]: Core found                   ← ✅ APPROTECT NON ATTIVO

Stesso cablaggio del 25008, funzionante al primo colpo.

💾 Backup — backup/holyiot_21011_stock.bin

printf "device nRF52810_xxAA\nif SWD\nspeed 4000\nconnect\nhalt\n\
savebin holyiot_21011_stock.bin,0x00000000,0x30000\nexit\n" | JLinkExe -nogui 1

192 KB · 147 KB non vuoti (76.8%)    ← quasi PIENO (il 25008 era al 14.6%)
vettore reset: SP=0x20000400  PC=0x000008E9
stringhe: ' nRF5x'  ·  ' LIS2DH_Device_ID: 0x%x'

🔬 Due beacon, due mondi

⭐ Ha l’accelerometro e il firmware lo interroga davvero (LIS2DH_Device_ID). ⚠️ 76.8% di flash occupata: il firmware Visla (124 KB) ci starebbe, ma con soli 68 KB di margine — contro gli 1.4 MB liberi del 25008.

✅ Confermato al banco: stesso cablaggio del 25008, connesso al primo colpo.

🔔 Firmware VISLA — gira anche qui ✅

Lo stesso identico main.c del 25008 compila e funziona su questo chip senza toccare una riga. È il valore di Zephyr: il devicetree astrae il pinout (DT_ALIAS(sw0)), la board fa il resto.

west build -p -b holyiot_21014 -d build_21014 visla-beacon

⚠️ Ma la RAM è al limite — ed è la differenza VERA tra i due chip

                 nRF52810 (21011)        nRF54L15 (25008)
FLASH   120.044 B / 192 KB  = 61%    124 KB / 1524 KB =  8%
RAM      22.720 B /  24 KB  = 92% ⚠️   21 KB /  256 KB =  8%

Non è la flash il collo di bottiglia: è la RAM. Lo stack BLE di Zephyr da solo si mangia quasi tutti i 24 KB del 52810 → 1.3 KB liberi. Funziona, ma aggiungere una connessione, un buffer o una feature = stack overflow.

→ Risposta a “si possono fare meno cose?”: sì, e il limite è la RAM.

🏆 Due chip, due device ID, stesso firmware

🎉 VislaBeacon #1   devID 81403C51   ← nRF54L15 (25008)
🎉 VislaBeacon #2   devID D295C383   ← nRF52810 (21011)

Il device ID dal silicio (hwinfo_get_device_id) funziona su entrambe le generazioni → anti-clonazione gratis, senza assegnare UUID a mano.

🔧 Note sul build

Zephyr ha la board holyiot_21014 (nRF52810) — ⚠️ 21014 ≠ 21011: modelli diversi dello stesso produttore, il pinout va verificato.

Pinout dichiarato dal 21014, e nota la differenza col 25008:

21014 (nRF52810):  button0 → gpio0 31, GPIO_ACTIVE_HIGH   ← polarità OPPOSTA
                   led0    → gpio0 29, GPIO_ACTIVE_LOW
                   led1    → led0_green
25008 (nRF54L15):  button0 → gpio1 13, GPIO_ACTIVE_LOW

→ il firmware del 25008 non si porta qui senza toccare il devicetree.

west build -b holyiot_21014 visla-beacon

⚠️ Gotchas (attesi, dal 25008)

• ❌ Nessun DFU → si passa dai pad SWD.
• 🇨🇳 Configurazione via app cinese senza documentazione.
• 📱 iOS/macOS filtrano gli iBeacon: passano solo perché usano manufacturer ID FFFF invece di quello Apple (4C00).
• ⏱️ 0.7 adv/s → la finestra di scan del tag deve essere ≥1.5 s per beccarlo in modo affidabile (peggio dei 25008).

🎯 Note per Visla

• Per l’arm/disarm va già bene così com’è: il MAC pubblico C0:9A:C2:7D:A0:68 è un ID stabile e l’RSSI basta per la soglia di prossimità. Nessuna riprogrammazione necessaria.
• Come dev board è inferiore al 25008: il 25008 monta il nRF54L15, cioè lo stesso chip del Visla Tag di produzione, e ha 1.5 MB di flash. Questo ha un nRF52810 con 192 KB — utile per imparare, meno per prototipare il Tag.
• ✅ SWD verificato e firmware stock dumpato — la via di ritorno c’è ([[feedback_never_raise_voltage_without_sweep]]).

🔗 Risorse

• 🛒 AliExpress — Holyiot 21011
• 📖 Zephyr — board holyiot_21014 (⚠️ modello diverso)
• 🔧 Holyiot 25008 — il fratello nRF54L15, testato a fondo
• 💻 GitHub — firmware Visla beacon