Hopefully I can shed a little light on this topic. The AIN4-20mA unit uses a STM32 processor to handle the I2C interface in software. For some reason, the timing is not wholly compatible with the Raspberry Pi kernel I2C drivers. However, the Espressif I2C implementation is a lot more tolerant and flexible and works just fine. That's why it works with the M5 controllers. There was a an update to the github repo for this unit's firmware (https://github.com/m5stack/M5Module-4-20mA-Internal-FW) which changed the I2C library that was used. It's possible that this will fix it, but I haven't bothered to set up a STM32 development system to try it. If you really want to use a Pi or other Linux host board, you could use any inexpensive ESP device (like an M5Stamp) as a go-between. Another option is to use something like the Arduino UNO Q, which runs Linux on the main processor and allows you to run C++ code on the STM32 microcontroller to talk to I2C devices. It's really better to run real-time control on a separate microcontroller anyway.

I hope M5Stack comes up with some kind of Stamp S3B which can be inserted right into the Cardputer ADV without the need to upgrade the Cardputer itself. Or someone else could maybe make a Stamp S3 clone that has PSRAM? Would love to see that.

Привет, разобрался? такая же тема после прошивки

@lishi 我CoreS3+GPSv2.1，一样的，只要loop里更新label就会闪退重启。不止是GPS，用LoRaWAN-EU868也会这样。老哥有找到原因吗？

Your RFID 2 module is likely not broken. The "Failed authenticating" error is the key clue here. Mifare 1KB cards use sector-based authentication with crypto keys. Bruce (and most generic RFID readers) will attempt the default keys (e.g. FF FF FF FF FF FF or A0 A1 A2 A3 A4 A5) to authenticate, but if FlipperZero or NFC Tools wrote data using custom or non-default keys, authentication will fail even though the UID and card type are read correctly. Things to try: Test with a blank/factory card. If it reads fine, your module is working. Check what keys were used when writing via FlipperZero or NFC Tools and make sure Bruce is configured to use those same keys. If the card was written with default keys, try a different card; it may have been locked or write-protected. The fact that UID, ATQA, and SAK are being detected correctly strongly suggests the module is functional.

Additional finding: Secondary firmware bug — boot sequence crash on cold boot (MEPC: 0x00000006) While investigating the sta.scan() crash, I discovered a second distinct firmware bug affecting the Tab5 in UIFlow2 v2.4.4. Description: On every cold boot, the device crashes during UIFlow2's initialization sequence before any user code runs. The device automatically reboots and boots successfully on the second attempt. Crash signature: Guru Meditation Error: Core 1 panic'ed (Instruction access fault). Exception was unhandled. MEPC : 0x00000006 MCAUSE : 0x00000001 MTVAL : 0x00000006 Key observation: The stack contains 0x7474696c (ASCII: "litt") pointing to a crash inside UIFlow2's LittlevGL/LVGL initialization sequence — not in user code. Reproducibility: 100% reproducible on cold boot Device always self-recovers on automatic reboot Completely independent of user code — happens before any user application starts This is a separate bug from issue #94 (sta.scan() at MEPC: 0x4ff13582). Both bugs share the same root environment (UIFlow2 v2.4.4 on Tab5) but occur at different stages and involve different subsystems.

@Aleximdh same settings on mine, have you tried it on diff wifi?

Hi, this would do the work https://github.com/ThatsLucas/M5Unit-ACMeasure-Internal-FW You need to reflash it though

@johnericsutton Hello, i had the same issue and fixed it on my github, you can use it : https://github.com/ThatsLucas/M5Unit-ACMeasure-Internal-FW