Multiple ESP32C and mmwave lite problems

Community
#21

Hi!!

I have some problem

#22

What specific problem did you encounter?

#23

For me it’s still mmwave lite not talking to the esp32c3.

Tried different pins and also tried flashing the new firmware but it just doesn’t want communicate with esp32c3 or usb to uart.

1 Like
#24

Igual problem… canto get working on homeassist
Cant receive any data from the sensor on esp32C3

#25

Can you confirm that you have updated the .yaml file and changed the pins to D2/D3 as instructed by the new Wiki?

#26

Which specific step are you having problems with?
You can describe your problem in detail so that we can better solve it for you.

#27

Yaml updated as well as the new pins soldered on. The firmware won’t flash to the mmwave lite using a usb uart.

#28

Same issues here. The sensor doesn’t seem to communicate with the Xiao

#29

I am having the same problem. I got 4 of the mmwave units on Friday. Got one connected to the esp32c3 and it started working immediately. As of yesterday, about 3 days later, the mmwave stopped working. I connected another mmwave to the same esp32c3 and it is working right now. Perhaps I have a bad mmwave?

#30

I’m using the latest yml files with the new connectors. My problem is that I have to reinstall everytime HA or the device restarts. It will not send data after a restart.
This is the screen I see when I look at the logs:

image
image680×579 15.2 KB

But when I reinstall it then almost every data is coming to the HA.
I have tried 2 ESP32C and both got the same issue.

#31

image
image312×876 33 KB

#32

INFO Reading configuration /config/esphome/mmwave.yaml…
INFO Generating C++ source…
INFO Compiling app…
Processing mmwave (board: esp32-c3-devkitm-1; framework: espidf; platform: platformio/espressif32@5.3.0)

HARDWARE: ESP32C3 160MHz, 320KB RAM, 4MB Flash

  • framework-espidf @ 3.40404.0 (4.4.4)
  • tool-cmake @ 3.16.4
  • tool-ninja @ 1.7.1
  • toolchain-esp32ulp @ 2.35.0-20220830
  • toolchain-riscv32-esp @ 8.4.0+2021r2-patch5
    Reading CMake configuration…
    Dependency Graph
    |-- noise-c @ 0.1.4
    | |-- libsodium @ 1.10018.1
    Compiling /data/mmwave/.pioenvs/mmwave/src/main.o
    In file included from src/main.cpp:112:
    src/R24dvd.h: In member function ‘void UartReadLineSensor::R24_frame_parse_human_information(uint8_t*)’:
    src/R24dvd.h:726:66: warning: comparison is always true due to limited range of data type [-Wtype-limits]
    if (data[FRAME_DATA_INDEX] < 3 && data[FRAME_DATA_INDEX] >= 0) {
    ~~~~~~~~~~~~~~~~~~~~~^~
    src/R24dvd.h:742:66: warning: comparison is always true due to limited range of data type [-Wtype-limits]
    if (data[FRAME_DATA_INDEX] < 9 && data[FRAME_DATA_INDEX] >= 0) {
    ~~~~~~~~~~~~~~~~~~~~~^~
    src/R24dvd.h:749:66: warning: comparison is always true due to limited range of data type [-Wtype-limits]
    if (data[FRAME_DATA_INDEX] < 3 && data[FRAME_DATA_INDEX] >= 0) {
    ~~~~~~~~~~~~~~~~~~~~~^~
    src/R24dvd.h:762:66: warning: comparison is always true due to limited range of data type [-Wtype-limits]
    if (data[FRAME_DATA_INDEX] < 3 && data[FRAME_DATA_INDEX] >= 0) {
    ~~~~~~~~~~~~~~~~~~~~~^~
    src/R24dvd.h:777:66: warning: comparison is always true due to limited range of data type [-Wtype-limits]
    if (data[FRAME_DATA_INDEX] < 9 && data[FRAME_DATA_INDEX] >= 0) {
    ~~~~~~~~~~~~~~~~~~~~~^~
    src/R24dvd.h:784:66: warning: comparison is always true due to limited range of data type [-Wtype-limits]
    if (data[FRAME_DATA_INDEX] < 3 && data[FRAME_DATA_INDEX] >= 0) {
    ~~~~~~~~~~~~~~~~~~~~~^~
    src/R24dvd.h: In member function ‘void UartReadLineSensor::R24_frame_parse_open_underlying_information(uint8_t*)’:
    src/R24dvd.h:918:66: warning: comparison is always true due to limited range of data type [-Wtype-limits]
    if (data[FRAME_DATA_INDEX] < 3 && data[FRAME_DATA_INDEX] >= 0) {
#33

My mmwave has been picked up by shipping company to return to Seeed Studio.

Hopefully they will find out what’s going on.

#34

3 of 4 of my MR24HPC1 devices have died. I was following the Seeed Studio guide to integrate it into Home Assistant (HA) and ESPHome, using the XIAO ESP32C3. They all died shortly after I adjusted some settings in HA. There is a FAQ4 entry that talks about the problem, but indicates it should have been fixed as of Jul 30.

I just started setting up the devices yesterday, so I thought I was fine. However, there is a discrepancy in the guide. In step 5, for the second part of the YAML file there is a “Click here to preview the full code” and a “Download the Code” option. The code is different between those 2 options. That is because there were several commits on Aug 21 in the GitHub repo that the “Download the Code” option links to. There appear to be several regressions to an earlier version of the code. I was using the latest GitHub version when 3 of my devices died. I switched to the code in “Click here to preview the full code” later, but I’m scared to try to adjust settings on my last remaining device. Which is the preferred version?

The next issue is that the devices that died will not take a UART firmware re-flash. They just don’t respond to the steps. I know it works because I successfully re-flashed my working device. However it appears it isn’t actually an upgrade. After re-flashing it, the version still says “G24VD1SYV001006”, which is what I had. I noticed it doesn’t say anywhere what version the UART_MR24HPC1-20230302.bin firmware actually is. From a hex dump it looks like it is actually still G24VD1SYV001006. This is rather confusing. As the page says, version 1006 is the first one to support UART flashing, but the provided firmware is the same version. What is the point? If it is to try to fix broken devices, it isn’t working in this case, as they won’t re-flash. It would be helpful if a firmware version was released that didn’t allow the device to be bricked just because a few settings were changed.

I also tried the Arduino sketch in “exclusion 4” and it doesn’t show any output. It is also fairly clear to see just by connecting the device to a USB-Serial adapter, as it just never sends any radar output, while a working device does. And it doesn’t respond to any commands. The only thing it sends, right after startup is “53 59 80 01 00 01 00 2E 54 43” once, then nothing more. That seems to decode to a human presence report indicating absence.

So is there any way to fix my devices now that they are in this state, short of a JLink?

#35

FYI, I am in the same situation. I have bricked 3 or 4 MR24HPC1 devices trying to get them working in home assistant. In my opinion, they seem extremely fragile when being handled with bare hands. I have never had any issues with MCU’s or other semiconductor devices, as I live in Florida and there is no problems with static electricity. But any handling of the MR24HPC1 Lite board seems to render them useless. I cannot re-flash them with the UART tool as them just stop responding to input. Now to be fair, the data sheet warns you to not touch the boards, and handle them only along the edges, But…

When it comes to handling, the biggest problem I am encountering is the 6 pin connector for the UART. It’s using 2.0mm pitch like for GROVE, but there is no GROVE connector for two rows of pins!. And, the spacing between rows is too narrow for two GROVE or standard JST-PH connectors to fit side by side. so getting a good connection is nearly impossible without grabbing the board. If Seeed would only make a 4 or 6 pin connector for that UART side of the board, I wouldn’t have to hold the board with my bare hands to try to get breadboard jumpers to attach to it.

I have also noticed that when using the Arduino example MR24HPCB1_rawdata_print.ino on a working board that it stops putting out frames evern second after about 2 hours. A re-boot of the board is needed to get it to output again.

I would like to think that the bricked modules can be salvaged, but for now, I’m thinking they are trashed, and I’m being very careful with the few I have remaining…