Hi,
We were able to flash the masterboard following those instructions.
Logs from make flash
App “masterboard” version: real_robot_challenge_phase3-216
Flashing binaries to serial port /dev/ttyUSB0 (app at offset 0x10000)…
esptool.py v2.7-dev
Serial port /dev/ttyUSB0
Connecting……………_____.
Chip is ESP32D0WDQ5 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: 40:f5:20:80:94:30
Uploading stub…
Running stub…
Stub running…
Configuring flash size…
Auto-detected Flash size: 4MB
Flash params set to 0x0220
Compressed 24768 bytes to 14840…
Wrote 24768 bytes (14840 compressed) at 0x00001000 in 1.3 seconds (effective 151.5 kbit/s)…
Hash of data verified.
Compressed 651120 bytes to 401099…
Wrote 651120 bytes (401099 compressed) at 0x00010000 in 35.3 seconds (effective 147.5 kbit/s)…
Hash of data verified.
Compressed 3072 bytes to 103…
Wrote 3072 bytes (103 compressed) at 0x00008000 in 0.0 seconds (effective 1759.4 kbit/s)…
Hash of data verified.
Leaving…
Hard resetting via RTS pin…
But after powering the masterboard, the LED state is stuck on Steady White (= the masterboard is in setup mode).
Is there some more configuration to do to use the masterboard ?
We tried to run the example provided with the sdk, but it fails with a timeout.
We also tried to run make monitor to see what is going on, but the printed values are not understandable for a human and we don’t know how to interpret them.
Best,
Louis
1 Like
After some more tests (on multiple masterboards) :
- Powering the master board (12V on the POWER pins) gives us a steady white led indefinitly. Green Led D1 is lit. Red led D2 blinks with a ~3 sec periode but very dimly.
- Simply plugging in an ethernet cable to a PC sometimes gives us a blinking white LED. But this behavior is not consistant.
@thomas.flayols Any idea what might be wrong ? It’s hard to know if flashing was succesful.
Hello,
Unfortunately, I have not a direct answer that could explain this on multiple master boards.
The fact that you can not read the make monitor commands is problematic.
Can you share the output of the “make flash” command?
Did you do the “burning of the fuse” step?
All those board has been assembled by the same fab?
Hello,
The output of make flash is in the original post.
We did the burning of the fuse step (python espefuse.py set_flash_voltage 3.3V).
The boards were assembled by betaLayout.
Best,
Louis
@thomas.flayols here are close up photos of the boards. We are trying to flash again to troubleshoot the make monitor.
Titouan
Hi,
We changed the model of ESP dev board that we used to match to one from the ReadMe.
The ESP dev board was a Joy-it Development board Node MCU ESP8266 WiFi Modul.
After that, we got a readable output from make monitor
Summary
��J���}�х��� Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
ETH/WIFI init size 4
ETH/WIFI command size 32
ETH/WIFI ack size 3
ETH/WIFI sensor size 60
SPI size 34
I (34) gpio: GPIO[4]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0
I (34) gpio: GPIO[5]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0
I (34) gpio: GPIO[16]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0
I (34) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
E (1034) emac: Timed out waiting for PHY register 0x2 to have value 0x0007(mask 0xffff). Current value 0xffff
E (2034) emac: Timed out waiting for PHY register 0x3 to have value 0xc0f0(mask 0xfff0). Current value 0xffff
E (2034) emac: Initialise PHY device Timeout
ESP_ERROR_CHECK failed: esp_err_t 0xffffffff (ESP_FAIL) at 0x400878f4
0x400878f4: _esp_error_check_failed at /path/esp-idf/components/esp32/panic.c:721
file: “/path/master-board/firmware/components/direct_ethernet/direct_ethernet.c” line 197
func: eth_init
expression: esp_eth_enable()
ELF file SHA256: 9291d083dd0b9e4b90a2d25448f6b94c783c37950f8d39a62a4079115df2562e
Backtrace: 0x40087480:0x3ffbb840 0x400878f7:0x3ffbb860 0x400e72f5:0x3ffbb880 0x400d396c:0x3ffbb8f0 0x400d1552:0x3ffbb930 0x4008d12d:0x3ffbb950
0x40087480: invoke_abort at /path/esp-idf/components/esp32/panic.c:157
0x400878f7: _esp_error_check_failed at /path/esp-idf/components/esp32/panic.c:722
0x400e72f5: eth_init at /path/master-board/firmware/components/direct_ethernet/direct_ethernet.c:197 (discriminator 1)
0x400d396c: app_main at /path/master-board/firmware/main/masterboard_main.c:537
0x400d1552: main_task at /path/esp-idf/components/esp32/cpu_start.c:529
0x4008d12d: vPortTaskWrapper at /path/esp-idf/components/freertos/port.c:143
Rebooting…
The error message already appears here. I’m working on it and will update if a solution is found.
@thomas.flayols Any idea if this is a hardware issue ? We would greatly appreciate your help as being able to use the master-board is the last milestone before everything come online (before more problems show up off course).
As @Louis_bln stated, now that we are using a D1 Dev Board (from AZdelivery) we can read the output of the make monitor.
Not sure yet what was wrong with the previous esp dev board ( Joy-it Development board Node MCU ESP8266 WiFi Modul) but it might be worth it to mention on the github that it was not plug & play with it.
Hi,
This error seems related to the hardware PHY (LAN8720A).
I can offer you to have a look at one of your boards if the shipping cost is not problematic for you.
I’m in Toulouse, France.
About the D1 problem, this is maybe due to the fact that your D1 uses a fake USB to serial bridge and the serial speed is limited. I will document it better on GitHub.
Hey Thomas,
Nimble One is in Toulouse too actually !
I have had several discussions with Philippe Soueres, Ghuilem Saurel, etc… We are working with Justin Carpentier and Rohan at INRIA and Steve Tonneau at Edinbourgh.
We can come to you with our board if LAAS is open.
I am switching to email.
Titouan
What we are currently investigating is the fact that we are using a LAN8720Ai instead of a LAN8720A, because of chip shortages.
Good, so we will investigate this issue together with the real board.
About the A vs Ai, I think this is not the problem. Ai version is just an industrial grade, with better range of operating temperature:
LAN8720A-CP-TR for 24-pin QFN lead-free RoHS compliant package (0 to +85°C temp)
LAN8720Ai-CP-TR for 24-pin QFN lead-free RoHS compliant package (-40 to +85°C temp)
@thomas.flayols I sent you some emails to schedule that, can you tell me if you did not receive anything ?
We will post a detailled report of the troubleshooting to help other in the future.
But I can already say that we managed to make one of our board work (out of 4). So The A vs Ai component change is not impossible.
Was this issue ever resolved or is there a report of the troubleshooting involved? My lab is having a similar issue where we followed the flashing instructions, but the LED is stuck in Steady White. Similar to the original post, we aren’t able to run make monitor.
