nanoframework / Home

:house: The landing page for .NET nanoFramework repositories.
https://www.nanoframework.net
MIT License
844 stars 75 forks source link

On macOS M1, the nanoff command fails to respond to the --nanodevice argument #1512

Closed lable closed 1 week ago

lable commented 2 weeks ago

Tool

nanoff

Description

esp32_c3 CH343 PHY

How to reproduce

No response

Expected behaviour

No response

Screenshots

nanodevice

Aditional context

No response

josesimoes commented 2 weeks ago

Most likely a duplicate of #1445

lable commented 2 weeks ago

Most likely a duplicate of #1445

The issue is not encountered in the Windows environment; it only reproduces on macOS M1 machines.

josesimoes commented 2 weeks ago

Can you add -v diag to the command and run it again? It should output the command line being passed to the esptool Then you can test calling esptool with those same parameters to check what happens.

lable commented 2 weeks ago

nanoff --nanodevice --serialport /dev/tty.wchusbserial54580045901 --devicedetails -v diag .NET nanoFramework Firmware Flasher v2.5.89+6f50e27b38 Copyright (C) 2019 .NET Foundation and nanoFramework project contributors

Error E2001: Error occurred with listing nano devices. (Couldn't connect to specified nano device.)

josesimoes commented 2 weeks ago

If you use --nanodevice you're trying to connect to the CLR. Correct one to get the ESP32 details:

nanoff --platform esp32 --serialport /dev/tty.wchusbserial54580045901 --devicedetails -v diag

lable commented 2 weeks ago

$ nanoff --serialport /dev/tty.wchusbserial54580045901 --devicedetails -v diag .NET nanoFramework Firmware Flasher v2.5.89+6f50e27b38 Copyright (C) 2019 .NET Foundation and nanoFramework project contributors

Using /dev/tty.wchusbserial54580045901 @ 1500000 baud to connect to ESP32. Reading details from chip... Executing esptool with the following parameters: '--port /dev/tty.wchusbserial54580045901 --chip auto --after no_reset_stub flash_id'

OK

Connected to: ESP32-C3 (ESP32-C3 (QFN32) (revision v0.3)) Features WiFi, BLE Flash size 4MB MX25L3205 from MACRONIX (manufacturer 0x194 device 0x8214) PSRAM: not available Crystal 40MHz MAC 60:55:F9:79:C0:2C

josesimoes commented 2 weeks ago

Connection with device is OK.

josesimoes commented 2 weeks ago

Now to exactly replicate the initial one: nanoff --target ESP32_C3 --serialport /dev/tty.wchusbserial54580045901 --update -v diag

lable commented 2 weeks ago

nanoff --target ESP32_C3 --serialport /dev/tty.wchusbserial54580045901 --update -v diag .NET nanoFramework Firmware Flasher v2.5.89+6f50e27b38 Copyright (C) 2019 .NET Foundation and nanoFramework project contributors

Using /dev/tty.wchusbserial54580045901 @ 1500000 baud to connect to ESP32. Reading details from chip... Executing esptool with the following parameters: '--port /dev/tty.wchusbserial54580045901 --chip auto --after no_reset_stub flash_id'

OK

Connected to: ESP32-C3 (ESP32-C3 (QFN32) (revision v0.3)) Features WiFi, BLE Flash size 4MB MX25L3205 from MACRONIX (manufacturer 0x194 device 0x8214) PSRAM: not available Crystal 40MHz MAC 60:55:F9:79:C0:2C

Trying to find ESP32_C3 in stable repository...OK Extracting ESP32_C3-1.9.1.224.zip...OK

Updating to 1.9.1.224

Flashing firmware... Executing esptool with the following parameters: '--port /dev/tty.wchusbserial54580045901 --chip esp32c3 --after no_reset_stub read_flash 0x3C0000 0x40000 "s2vedfiu.alr"'

Read 262144 bytes at 0x003c0000 in 23.6 seconds (88.7 kbit/s)...

Executing esptool with the following parameters: '--port /dev/tty.wchusbserial54580045901 --baud 1500000 --chip esp32c3 --after hard_reset write_flash --flash_size 4MB 0x0 "/Users/jinyong/.nanoFramework/fw_cache/ESP32_C3/bootloader.bin" 0x10000 "/Users/jinyong/.nanoFramework/fw_cache/ESP32_C3/nanoCLR.bin" 0x8000 "/Users/jinyong/.nanoFramework/fw_cache/ESP32_C3/partitions_4mb.bin" 0x3C0000 "s2vedfiu.alr"'

OK

josesimoes commented 2 weeks ago

Operation was fine. If still not detected on VS, connect serial terminal and check the output for any errors.

lable commented 2 weeks ago

Runs on windows11 arm:

PS C:\Users\jinyong> nanoff --nanodevice --devicedetails --serialport com4 -v diag .NET nanoFramework Firmware Flasher v2.5.89+6f50e27b38 Copyright (C) 2019 .NET Foundation and nanoFramework project contributors

Error E2001: Error occurred with listing nano devices. (Couldn't connect to specified nano device.) PS C:\Users\jinyong> nanoff --nanodevice --devicedetails --serialport com4 -v diag .NET nanoFramework Firmware Flasher v2.5.89+6f50e27b38 Copyright (C) 2019 .NET Foundation and nanoFramework project contributors

Error E2001: Error occurred with listing nano devices. (Couldn't connect to specified nano device.) PS C:\Users\jinyong> nanoff --nanodevice --devicedetails --serialport com4 -v diag .NET nanoFramework Firmware Flasher v2.5.89+6f50e27b38 Copyright (C) 2019 .NET Foundation and nanoFramework project contributors

HAL build info: nanoCLR running @ ESP32_C3 built with ESP-IDF v5.1.3 Target: ESP32_C3 Platform: ESP32

Firmware build Info: Date: Jun 16 2024 Type: MinSizeRel build, chip rev. >= 2, without support for PSRAM CLR Version: 1.9.1.224 Compiler: GNU ARM GCC v12.2.0

OEM Product codes (vendor, model, SKU): 0, 0, 0

Serial Numbers (module, system): 00000000000000000000000000000000 0000000000000000

Target capabilities: Has nanoBooter: NO IFU capable: NO Has proprietary bootloader: YES

AppDomains:

Assemblies: nanoFramework.Runtime.Events, 1.11.6.0 nanoFramework.System.Text, 1.2.37.0 System.Device.Gpio, 1.1.28.0 GCStressTest, 1.0.8936.35587

Native Assemblies: mscorlib v100.5.0.19, checksum 0x445C7AF9 nanoFramework.Runtime.Native v100.0.9.0, checksum 0x109F6F22 nanoFramework.Hardware.Esp32 v100.0.10.0, checksum 0x6A20A689 nanoFramework.Hardware.Esp32.Rmt v100.0.4.0, checksum 0x608C5658 nanoFramework.Networking.Sntp v100.0.4.4, checksum 0xE2D9BDED nanoFramework.ResourceManager v100.0.0.1, checksum 0xDCD7DF4D nanoFramework.System.Collections v100.0.1.0, checksum 0x2DC2B090 nanoFramework.System.Text v100.0.0.1, checksum 0x8E6EB73D nanoFramework.System.IO.Hashing v100.0.0.1, checksum 0xEBD8ED20 nanoFramework.System.Security.Cryptography v100.0.0.2, checksum 0xF4AEFE6C nanoFramework.Runtime.Events v100.0.8.0, checksum 0x0EAB00C9 EventSink v1.0.0.0, checksum 0xF32F4C3E System.IO.FileSystem v1.1.0.0, checksum 0xCC556D24 System.Math v100.0.5.5, checksum 0x9F9E2A7E System.Net v100.2.0.1, checksum 0xD82C1452 System.Device.Adc v100.0.0.0, checksum 0xE5B80F0B System.Device.Gpio v100.1.0.6, checksum 0x097E7BC5 System.Device.I2c v100.0.0.2, checksum 0xFA806D33 System.Device.I2c.Slave v1.0.0.0, checksum 0x4238164B System.Device.I2s v100.0.0.1, checksum 0x478490FE System.Device.Pwm v100.1.0.4, checksum 0xABF532C3 System.IO.Ports v100.1.6.1, checksum 0xB798CE30 System.Device.Spi v100.1.2.0, checksum 0x3F6E2A7E System.Runtime.Serialization v100.0.0.0, checksum 0x0A066871 System.Device.Wifi v100.0.6.4, checksum 0x00A058C6 Windows.Storage v100.0.3.0, checksum 0xF0C37E1B

lable commented 2 weeks ago

When testing the flashing of a program on Windows 11 ARM, it writes successfully but fails to run. It's uncertain whether this is due to an incorrect deployment starting address or if the write operation didn't actually succeed.

nanoff --serialport com4 --image U:\projects\nanoframework\Samples\samples\GCStressTest\bin\Debug\GCStressTest.bin --deploy -v diag --address 0x001B0000 --masserase .NET nanoFramework Firmware Flasher v2.5.89+6f50e27b38 Copyright (C) 2019 .NET Foundation and nanoFramework project contributors

Using com4 @ 1500000 baud to connect to ESP32. Reading details from chip... Executing esptool with the following parameters: '--port com4 --chip auto --after no_reset_stub flash_id'

OK

Connected to: ESP32-C3 (ESP32-C3 (QFN32) (revision v0.3)) Features WiFi, BLE Flash size 4MB MX25L3205 from MACRONIX (manufacturer 0x194 device 0x8214) PSRAM: not available Crystal 40MHz MAC 60:55:F9:79:C0:2C

Flashing deployment partition... Executing esptool with the following parameters: '--port com4 --baud 1500000 --chip esp32c3 --after hard_reset write_flash --flash_size 4MB 0x1B0000 "U:\projects\nanoframework\Samples\samples\GCStressTest\bin\Debug\GCStressTest.bin"'

OK

serial terminal:

Xnip2024-06-24_22-28-49

josesimoes commented 1 week ago

@lable you're trying to debug two things at the same time. Not productive. Let's figure out first the issue with the device having a correct imaged flashed and loaded, and then we'll move to the other issue with --nanodevice option.

You can't masserase when deploying a managed application. If you do that, you're erasing the bootloader and the CLR.

I'll ask again: please flash the device with nanoff --target ESP32_C3 --update --masserase --serialport ?????? -v diag After that, connect a serial terminar and share the output.

torbacz commented 1 week ago

@josesimoes Just a side note, maybe there should be validation agains such case? If there is deploy or image parameter and masserase - then return error?

lable commented 1 week ago

I am detailing varying issues observed with the nanoff utility in two separate environments – macOS and Windows 11 ARM. Let me recalibrate and outline the test steps again.

The procedure for testing the windows 11 arm environment is as follows: 1、Flash framework: 1、 烧录固件

2、Serial terminal output 2、串口工具输出

3、Devices can be detected on the vs 2022 3、vs2022上检测到设备

4、vs2022 deployment program 4、部署程序

5、部署成功

5、Serial terminal output again 6、再次看串中工具输出 7、没有打印输出

Shouldn't the steps performed within the IDE for these operations be identical to using the nanoff tool for flashing?

Furthermore, while the nanoff --listdevices command successfully locates the device on Windows 11 ARM, it fails to detect any devices on macOS. Of course, all functionalities work as intended in a Windows x64 environment.

lable commented 1 week ago

o summarize briefly, the nanoff tool is capable of detecting devices under Windows 11 ARM but fails to deploy programs correctly. Conversely, on macOS, it can write firmware but does not respond to the --nanodevice parameter. These examples aim to clarify the specific issues encountered. Please pardon any inadequacies in my explanation!

alberk8 commented 1 week ago

From the screen capture, it looks like your ESP32 C3 module is going into bootloader mode (waiting to receive firmware update). In this mode the VS extension will not be able to detected the device. Essentially, you need to press the Reset Button on the ESP32 for it go into normal running mode.

josesimoes commented 1 week ago

@lable all support for MacOS is experimental, VS Code extension included. Reasons being lack of test equipment (only one Core Team member has access to a Mac) and the very short number of developers using it (when compared to Windows) which is currently our main focus, for the obvious reasons.

josesimoes commented 1 week ago

On the fact that the device fails to respond to --nanodevice parameter, it can be because the device hasn't reboot after the update procedure. Try to hit the reset and give it a few seconds.

josesimoes commented 1 week ago

@josesimoes Just a side note, maybe there should be validation agains such case? If there is deploy or image parameter and masserase - then return error?

I see your point... maybe that can be added. To be honest, my first thoughts on questions like this one is "RTFM" and know your tools... 😉 but OK, for this one is easy to introduce a hard lock in code to prevent the developer from messing the device. 😅

lable commented 1 week ago

Thank you all for your assistance; I will continue to use Windows as my primary development environment. Appreciate your help once again!

josesimoes commented 1 week ago

Sure! Appreciate your feedback and effort on investigating this.