Subcategories

• Core2 for AWS
  53 Topics

  243 Posts

  G

  TL;DR: The factory certificate in slot 10 is in a compressed format that AWS IoT rejects. You need to generate a new properly-formatted certificate. Full working example here: https://github.com/scarolan/grafana-core2aws-iot The Problem Everyone Hits If you've tried to use the Core2 for AWS with its built-in ATECC608 secure element, you've probably hit this error when registering the certificate: CertificateValidationException: The certificate could not be parsed You're not crazy. The factory certificate in slot 10 is stored in Microchip's compressed format with: Empty issuer/subject fields Invalid dates (Aug 28, 2005) Missing X.509 structure AWS IoT's register-certificate-without-ca API rejects it outright. The Solution Generate a new properly-formatted certificate that still uses the locked private key in slot 0 (so you maintain hardware security): 1. Clone the Working Example git clone https://github.com/scarolan/grafana-core2aws-iot cd grafana-core2aws-iot/extras/generate_cert 2. Flash the Certificate Generator pio run -t upload --upload-port COM3 pio device monitor --port COM3 --baud 115200 3. Save the Certificate Copy the certificate output (including -----BEGIN CERTIFICATE----- lines) to a file. 4. Register with AWS IoT aws iot register-certificate-without-ca \ --certificate-pem file://device_new.pem \ --status ACTIVE \ --region us-east-1 Then attach your policy and thing as usual. 5. Use in Your Firmware Update secrets.h with the new certificate and you're done! Why This Works The certificate generator: Reads the public key from slot 0 (the private key never leaves the chip) Creates a proper X.509 certificate with valid dates and subject fields Signs it using the locked private key (signing happens inside the ATECC608) Returns a properly-formatted certificate AWS IoT accepts Hardware security is maintained - the private key in slot 0 is never exposed, it's just used differently. Complete Documentation I've documented the full solution with explanations of what's happening: ATECC608 Architecture - How the secure element works, slot configuration, lock mechanism Certificate Solution - Why the factory cert fails and how to fix it Full Working Example - Complete vibration monitoring IoT demo with AWS IoT Core + Timestream Why M5Stack Doesn't Document This The compressed certificate format is a Microchip design decision (saves space on the chip). It's meant to work with: Microchip's Trust Platform provisioning tools Their specific certificate reconstruction libraries Microchip-managed certificate authorities It was never designed to work directly with third-party services like AWS IoT without special handling. M5Stack provides a complex registration helper (registration_helper.py) that reconstructs the certificate with special manifest-based APIs, but it's 800+ lines of Python with tons of dependencies. The approach above is much simpler - just generate a new cert and register it normally. Tested and Working This solution is running in production on my demo device: MQTTS publishing to AWS IoT Core every 5 seconds Data flowing to Amazon Timestream Hardware-backed authentication with ATECC608 Zero issues with certificate validation Hope This Saves Someone's Week I fought with this for a week a couple years ago and gave up in frustration. Revisited it recently and finally cracked it. Hopefully this saves others the same pain! Questions/issues? Comment here or open an issue on GitHub. Repository: https://github.com/scarolan/grafana-core2aws-iot Hardware: M5Stack Core2 for AWS Libraries: ArduinoECCX08, ArduinoBearSSL, M5Unified Tested: PlatformIO, Arduino framework on ESP32
• M5Stack Fire
  89 Topics

  337 Posts

  S

  @felmue That helps a lot, thank you!
• M5stack Grey
  65 Topics

  228 Posts

  H

  Has anyone installed firmware and upon starting gets stuck in a menu selection loop where the highlight selection continues to scroll?
• M5 Stick/StickC

  M5Stack's little brother. Discuss M5 Stick hardware and software related issues here
  403 Topics

  2k Posts

  M

  Does anyone's built-in IR receiver work?
• M5GO
  18 Topics

  71 Posts

  P

  I just got the M5GO Kit, and I'm trying to make a Voice Assistant. For some reasons, the Demo of the kit made me think that accessing the microphone is easy. But, after hours of finding, it seems that there is no library or support for the kit to record audio. Does anyone have any resource regarding this?
• FACES Kit
  27 Topics

  114 Posts

  M

  Problem: Der Schrittmotor funktioniert nur korrekt in der Z-Achse bei normalen (langsamen) Drehgeschwindigkeiten. Beim Versuch, die X- und Y-Achsen zu verwenden, funktioniert der Motor nur, wenn ich die Vorschubgeschwindigkeiten auf das 10-fache oder höher erhöhe. Wenn ich versuche, die Adresse auf 0x71 zu ändern, wird das Modul nicht erkannt.
• M5Stick V
  50 Topics

  133 Posts

  Y

  @samantha_martin Hola Samantha. El M5StickC Plus (SKU:K016-P) utiliza el chip ESP32-PICO-D4, que integra Bluetooth LE. Para reducir la latencia en la transmisión HID, puedes probar las siguientes acciones: Optimizar la frecuencia de envío de datos: En las librerías ESP32-BLE-Keyboard o BleGamepad, ajusta el intervalo de notificación BLE a un valor más bajo (por ejemplo, 10-20 ms). Algunas librerías permiten configurar esto al inicializar el dispositivo HID. Minimizar el código en el loop(): Asegúrate de que no haya delays innecesarios ni tareas bloqueantes (como impresiones Serial) que ralenticen la detección de botones y el envío de comandos. Configurar el modo BLE de bajo consumo: Aunque el ESP32-PICO-D4 es eficiente, verifica que no se encuentre en modos de suspensión prolongada. Asegúrate de que el dispositivo BLE esté configurado para enviar notificaciones inmediatamente al detectar una pulsación. Actualizar el firmware del ESP32: Usa la última versión del core ESP32 en Arduino IDE, ya que a menudo incluyen optimizaciones en el stack BLE. Verificar la configuración de Android: En el menú de configuración de Bluetooth de tu teléfono, desactiva opciones como "Ahorro de batería" para el dispositivo M5StickC Plus, ya que pueden restringir la frecuencia de actualizaciones HID. https://chat.m5stack.com/
• Core 2

  For Topics related to the Core 2
  337 Topics

  1k Posts

  Y

  Root Cause Analysis A detailed schematic review revealed the source of the problem. All three components — Core2, Audio Module, and Bottom2 — are interconnected through the shared M5 BUS. The Bottom2 module includes a SPM1423 MEMS microphone, which uses: GPIO0 (BUS pin 24) for the clock signal (CLK) GPIO34 (BUS pin 26) for the data signal (DAT, digital output) The Audio Module, based on the ES8388 codec, uses: GPIO0 (BUS pin 24) for I2S_MCLK GPIO34 (BUS pin 26) for I2S_MAIN_DIN This creates a fundamental hardware conflict on the I2S bus. The Core Conflict Two independent devices attempt to drive the same data line: The ES8388 (M144 Audio Module) uses GPIO34 to send digitized audio data from its ADC (line-in or microphone) to the ESP32 via I2S. The SPM1423 (Bottom2) uses the same GPIO34 to output PDM audio data from its internal MEMS microphone. From the ESP32’s perspective: GPIO34 is input-only However, on the physical PCB traces, both devices are electrically connected to this same line and actively drive it. This results in a classic and severe bus contention scenario: Two outputs connected together No arbitration No isolation No possibility for coexistence Why This Cannot Be Solved in Software At first glance, one might consider disabling the microphone via software. Unfortunately, this is not feasible due to both architectural and hardware constraints. The Bottom2 doesn’t expose the SPM1423 MEMS dedicated enable/disable (chip select) pin. The only way to silence it — effectively forcing its data output into a high-impedance (Hi-Z) state — is to stop its clock signal on GPIO0. This leads directly to a deadlock: If the M144 switch is set to position A: GPIO0 is used as MCLK (mandatory master clock for ES8388 operation, typically 12.288 MHz) If the switch is set to position B: GPIO0 becomes I2S SCLK (bit clock) Additionally: The internal amplifier of the Core2 (NS4168) also uses GPIO0 for BCLK In other words, GPIO0 is always actively used in any valid configuration. Stopping the clock to disable the microphone would simultaneously break: the ES8388 codec or the Core2 internal audio path Thus, there is no viable way to control the microphone via software without disrupting essential system functionality. Design Oversight The A/B switch on the M144 Audio Module was clearly designed to avoid clock conflicts (MCLK vs SCLK) with other peripherals. However, the design completely overlooks the data line conflict on GPIO34. This is particularly problematic because: the Bottom2 module is an official M5Stack accessory the SPM1423 microphone is always active by default both modules are intended to be used within the same ecosystem Despite this, their coexistence leads to a non-functional configuration when using the ES8388 input path. Conclusion This issue is not a matter of configuration, firmware, or library incompatibility. It is a fundamental hardware design conflict on the shared M5 BUS. When Bottom2 is attached: the SPM1423 microphone continuously drives the I2S data line the ES8388 is unable to deliver valid audio data the result is severe noise and corrupted signal There is no reliable software workaround. The only effective solutions are hardware-level: physically removing or isolating the SPM1423 microphone redesigning the Bottom2 PCB to include a switch or gating mechanism routing the microphone control (e.g., SELECT or enable logic) to a dedicated GPIO Until such changes are implemented, the ES8388 input functionality cannot be used in conjunction with the Bottom2 module in a stable and predictable way. My solution was to remove the SPM1423 Microphone from the PCB. Another solution is to cut the relevant pins from the Bottom2 BUS with the same effect - removing SPM1423 from the circuit.