nanoframework / Home

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

Unable to detect device in VS device-manager after updateing to 2.0.65 #1072

Closed AdrianFishy closed 2 years ago

AdrianFishy commented 2 years ago

Tool

nanoff

Description

Hello There!

After updating nanoff from version 2.0.62 to 2.0.65 i am unable to see my device in the device-manager in Visual Studio. I can find and update my device through nanoff cli in version 2.0.65 but it cant be found in the device-manager. Reinstalling to version 2.0.62 fixes the problem.

How to reproduce

Plug the device in the USB Port and try to find it in the device-manager

Expected behaviour

The device should be found and pingable.

Screenshots

Annotation 2022-06-07 160916 Annotation 2022-06-07 160833

Aditional context

Microsoft Visual Studio Professional 2019 Version 16.11.15

josesimoes commented 2 years ago

@AdrianFishy this is most likely due to that warning message that you see there about the hash checksum. The partition table doesn't seem to be updated and it's getting the correct updated table from the update.

At this time I have no suggestion on how to fix that. Suggest that you search at the Espressif forums (or ask there) how to completely wipe the your device and start over so it's usable again by nanoff.

I have here an M5Core which I've flashed yesterday and everything went just fine as usual.

lsd-techno commented 2 years ago

I have same problem with revision 1 devices. Possible it is related to files hash and how do we invoke esptool (since v4.1/4.2 there is note on esptool that if we transfer flash mode e.g. DIO/QIO and/or specify frequency for flash chip then it modifies first 3 bytes of flash image on the fly that makes hash invalid at the end). And in current version of nanoff I didn't find any option to suppress those parameters transfer to esptool command line. I post my output from boot process in the comments on last esptool commit Update esptool to v4.1 (#137)

josesimoes commented 2 years ago

@lsd-techno can you point me to that note so I can investigate this deeper?

AdrianFishy commented 2 years ago

@josesimoes how did you flash your device? I have a M5Core too and i erased the flash with the esptool.py programm. After that i tried to flash with nanoff again but i get the same error while flashing.

AdrianFishy commented 2 years ago

I fixed it. In my unterstanding nanoff executes the esptool. I saw the message in a higher log level when stating : nanoff --verbosity diag --target M5Core --update --serialport COM5

I got this Message: Executing esptool with the following parameters: '--port COM5 --baud 1500000 --chip esp32 --after hard_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 16MB 0x1000 "C:\Users\USER.nanoFramework\fw_cache\M5Core\bootloader.bin" 0x10000 "C:\Users\USER.nanoFramework\fw_cache\M5Core\nanoCLR.bin" 0x8000 "C:\Users\USER.nanoFramework\fw_cache\M5Core\partitions_16mb.bin"'

I copied that CLI command to my own esptool.py and executed it.

C:\Users\USER>esptool.py --port COM5 --baud 1500000 --chip esp32 --after hard_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 16MB 0x1000 "C:\Users\USER.nanoFramework\fw_cache\M5Core\bootloader.bin" 0x10000 "C:\Users\USER.nanoFramework\fw_cache\M5Core\nanoCLR.bin" 0x8000 "C:\Users\USER.nanoFramework\fw_cache\M5Core\partitions_16mb.bin" esptool.py v3.3.1 Serial port COM5 Connecting.... Chip is ESP32-D0WDQ6 (revision 1) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: a4:cf:12:6d:69:a4 Uploading stub... Running stub... Stub running... Changing baud rate to 1500000 Changed. Configuring flash size... Flash will be erased from 0x00001000 to 0x00006fff... Flash will be erased from 0x00010000 to 0x00117fff... Flash will be erased from 0x00008000 to 0x00008fff... Flash params set to 0x0240 Compressed 23728 bytes to 14979... Wrote 23728 bytes (14979 compressed) at 0x00001000 in 0.4 seconds (effective 431.4 kbit/s)... Hash of data verified. Compressed 1079584 bytes to 714646... Wrote 1079584 bytes (714646 compressed) at 0x00010000 in 10.4 seconds (effective 826.9 kbit/s)... Hash of data verified. Compressed 3072 bytes to 136... Wrote 3072 bytes (136 compressed) at 0x00008000 in 0.0 seconds (effective 512.0 kbit/s)... Hash of data verified.

Leaving... Hard resetting via RTS pin...

Now i see my device in the Device-Manager in Visual Studio and i didnt get the warning i got in nanoff.

josesimoes commented 2 years ago

Most likely because you're using your esptool (which seems to be v3.3.1). But if you've got it working that's great. Please close the issue.

josesimoes commented 2 years ago

And if you can, still interested in that documentation about those byte changes on the recent version.

lsd-techno commented 2 years ago

here is link to esptool commit elf2image: Add argument to disable appending SHA256 digests with some description related to hash and flash parameters.

josesimoes commented 2 years ago

For reference: I've suggested to add a new CONFIG option in IDF espressif/esp-idf#9126.

josesimoes commented 2 years ago

Espressif has made changes on the IDF to solve this at build time. Bad news is that will be available only with IDF v5.0.

For the time being, I'm reverting the migration of esptool to the version before this breaking change was introduced. Reverted with nanoframework/nanoFirmwareFlasher#138.

MikeFarrington commented 2 years ago

Looks like I'm having the same issue with my M5Core2. I just can't get it to be seen via the VS extension ("Found 0 devices"). The output is below. I also tried the suggested "keep" parameter, but still nothing.

D:\GitHub\Espressif\esptool>python -m esptool --port com5 --baud 1500000 --chip esp32 --after hard_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 16MB 0x1000 "d:\m5core2\bootloader.bin" 0x10000 "d:\m5core2\nanoCLR.bin" 0x8000 "d:\m5core2\partitions_16mb.bin"
esptool.py v4.2-dev
Serial port com5
Connecting...
Failed to get PID of a device on com5, using standard reset sequence.
.
Chip is ESP32-D0WDQ6-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 78:21:84:8d:d5:68
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 1500000
Changed.
Configuring flash size...
Flash will be erased from 0x00001000 to 0x00006fff...
Flash will be erased from 0x00010000 to 0x00149fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Warning: Image file at 0x1000 is protected with a hash checksum, so not changing the flash size setting. Use the --flash_size=keep option instead of --flash_size=16MB in order to remove this warning, or use the --dont-append-digest option for the elf2image command in order to generate an image file without a hash checksum
Compressed 23728 bytes to 14982...
Wrote 23728 bytes (14982 compressed) at 0x00001000 in 0.5 seconds (effective 370.7 kbit/s)...
Hash of data verified.
Compressed 1283024 bytes to 846520...
Wrote 1283024 bytes (846520 compressed) at 0x00010000 in 12.6 seconds (effective 817.6 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 136...
Wrote 3072 bytes (136 compressed) at 0x00008000 in 0.1 seconds (effective 419.7 kbit/s)...
Hash of data verified.
dobairoland commented 2 years ago

Espressif has made changes on the IDF to solve this at build time. Bad news is that will be available only with IDF v5.0.

I think the issue is present only in the master branch of ESP-IDF (v5.0 in progress). Previous releases should not be affected. The fix will be published soon on Github (in the master branch) and you don't have to wait for the final release of v5.0.

I don't know how you exactly integrate ESP-IDF and esptool but after generating the images with idf.py build it is possible to run esptool.py elf2image --dont-append-digest ... manually and re-generate the bootloader image. That would allow you to change the flash size during flashing.

josesimoes commented 2 years ago

@dobairoland understood! Thanks for the heads up.

We are using our nanoff CLI as a wrapper to esptool. For the time being reverting to esptool 3.3 seems the less disruptive option. Everything was working just fine with that one. The move to 4.1 was just part of the regular maintenance (which triggered all this).