Thanks for sharing your findings—this is really useful information, especially for anyone working with ESP32-S3 devices. The distinction between the two drivers (JTAG/Serial and the low-level modem driver) explains a lot of the issues people run into when trying to reflash firmware. It sounds like the main challenge is getting proper access to Bootloader mode when the second driver isn’t installed correctly. On Windows and Linux, driver installation can sometimes be tricky depending on permissions or conflicting drivers. It might be worth checking if the correct USB CDC/ACM or WinUSB drivers are being assigned, or trying tools like Zadig on Windows to manually bind the device to the right driver. Also, holding the BOOT button while connecting (or resetting) the device can sometimes force it into Bootloader mode if it’s not entering automatically. Good call on warning users about Flipper/Marauder firmware—getting locked out of reflashing can be a real headache. Hopefully, with more testing, a consistent driver setup for Windows/Linux can be identified. Looking forward to any updates you find!

I have my cardputer connected to wins11. I have a project loaded in UIflow2.0 and when I press upload to device I get a Log in screen. In m5burner view in Opera browser I get a terminal window and eventually there are messages. I am trying the RTC clock.

@Mati said in UIFlow 1.8.4: @m5stack said in UIFlow 1.8.4: We are very sorry, we are working hard to supplement the support of related modules thx for reply, maybe all will be happy if we can see some roadmap with HW implementation. “Good point, Mati. A roadmap would definitely help everyone plan projects better. I’m also waiting on Zigbee support!”

@ajb2k3 said in PSA: Core 2 not powering off.: You may notice that sometimes the Core2 device may not power off when the button is held in for five seconds. I have noticed that the Button used for power is prone to breaking (I have already notified M5Stack about this issue on multiple occasions) You can replace the switch, but a simpler fix is to use the "battery paper trick" and stick a small block of insulated substance on top of the switch to hold the cover down. I haven't included pictures as the switch is so small and difficult to photograph. P.S. This doesn't just affect Core2 devices, and any device that uses this switch may suffer. Thank you for taking the Time treadad. Adam Bryant Forum Admin Team and Unofficial documentation and guide creator. UIFlow, so easy an adult can learn it! If I don't know it, be patient! I've either not learned it or am too drunk to remember it! Author of the WIP UIFlow Handbook! M5Black, Go, Stick, Core2, and so much more, it can't fit in here! Thanks for the heads-up, Adam. I’ve run into the same issue a couple of times and thought it was just me not holding the button long enough. Good to know it might be a hardware fault. I’ll give the battery paper trick a try and see if that helps. Appreciate you sharing the workaround and letting M5Stack know, hopefully they address it in future batches.

@ajb2k3 thanks for confirming. It not so clear from the provided schematic. Do you know which pin on the AXP is providing boosted 5V? If I had to guess, I would say it is 'IPSOUT' but it is not so clear to me from the Schematic nor the AXP datasheet. Do you know the part number of the IC noted 'DCDC' in screenshot below? [image: 1722940828399-screenshot-from-2024-08-06-12-43-37.png] Thanks

@m5stack Happening again (similar) in 1.12.2 In this case the only log message is: >>> reconnect start ... Device looks hanged at thar moment, not executing and not responsive.

@uktechguy I can confirm that M5StickC has no receive, only IR Infrared transmit A workaround, if you have a line follower (HW-006) or similar you can use a Grove2Dupont cable to connect the sensor to the M5StickC but (V. IMPORTANT!!!) swap the 5V input to the sensor with jumper cable to the 3V3 of the hat connector on the stick. This will allow a quick test of the receive block associated with the M5Stack IR module block in UIFlow. What I discovered is that the standard transmit block (under Hardware > IR). Only accepts one byte for data and one byte for address. According to the NEC standard (not extended) the first 8 bits are the address and 17-24 bits are the command (NB 'data' is a bit of a loose term, it would be better as 'command' in the UIFlow block, datagram or 'data' to mean the assembled code). Next gotcha, the bits need to be reversed to use with external equipment, note reversed not inversed. Tool for this: https://www.browserling.com/tools/reverse-binary And this tool to swap between binary and hex https://www.rapidtables.com/convert/number/binary-to-hex.html An example: The code I wanted to send: 0x00F7B04F --> the first byte is not the inverse binary of the second, so it is NEC extended and, so far as I can tell, is unsupported in UIFlow - ideally this needs fixed or second block added! 2nd attempt to use IR to turn on/off LG TV with book code: 0x20DF10EF Logically, I took 20 to be the address and 10 to be the command ('data' in UIFlow block). Sadly, it wasn't. To make this work the addr and data values need to be reversed therefore 20 --> 0x04 and 10 --> 0x08. Hence, I made the UIFlow block: IR(NEC) send addr 0x04 data 0x08 (alt Python ir.tx(0x04, 0x08)). Triggered from button on Atom this worked on my LG tvs. Interestingly, send and receive between Atom and M5StickC didn't reverse the bits. So, I would assume the same would happen if using the receive to scan from a remote. A couple of other examples: https://flow.m5stack.com/?examples=ir_nec_sender_demo https://flow.m5stack.com/?examples=ir_nec_receiver_demo Some other useful references: https://github.com/esikora/ESP32App_Led_IR/blob/PlatformIO/src/ESP32App_Led_IR.cpp https://exploreembedded.com/wiki/NEC_IR_Remote_Control_Interface_with_8051 https://www.sbprojects.net/knowledge/ir/nec.php https://qiita.com/poruruba/items/34220a4dd6aaf48392aa https://docs.m5stack.com/en/unit/ir https://shop.m5stack.com/products/stick-c

@teastain yeh, its happened several times now.

It shows Montserrat 10 in Uiflow, but when trying to use it in Micro Python getting an error: NameError: name 'FONT_MONT_10' isn't defined

@ajb2k3 Kind of. I am using push of data in a time-based function (UIFlow). Tried normal and async save methods of a string and an integer. The Atom then freezes without transmission and the function is never terminated. Previous Firmware 1.9.7 allows continuous transfers of two values and reverts to the main loop after finishing the function.

Hi guys in UiFlow the IoTBaseCatM module can only be used if a SIM card has been inserted. In other words the non IoT related ports (e.g. Modbus) cannot be used w/o SIM card inserted. The reason for that is that as part of the initialization catmiot = module.get(module.CATMIOT) an AT+CPIN? command is sent every 6 seconds forever since w/o SIM card inserted the response from the SIM7080 is ERROR. Thanks Felix

Just for completeness, I'm on a 2021 Macbook Pro M1Max with 64 GB of RAM and macOS Monterey 12.3.1. I've tried it using Python 3.9.11 and 3.10.3