For all of these scenarios, I am able to upload the firmware and monitor via serial usb. But after creating my first firmware, for all new firmware, I can't upload Lua scripts using the nodemcu-tool without getting the following:
Error Message
F:\Development\NodeMCU\helloworld>nodemcu-tool -p COM3 upload init.lua
[NodeMCU-Tool]~ Unable to establish connection
[NodeMCU-Tool]~ Invalid node.chipid() Response: 6935962
Observations
Can reset the board using nodemcu-tool. Leads me to assume the baud rate is fine.
Can see the file system being created from PuTTy after loading any of the firmware. Leads me to assume the firmware is OK.
Have tried multiple dev boards, same results
Found the source of the error message device-info.js. either line 45 or 49
I have no idea what "Response: 6935962" means. Is that my chip id or an error code?
A new commit was made to the firmware source during the last couple of days. No idea if this is relevant.
Was hoping to get this resolved before I go down the Docker rabbit hole. Lazy. I know.
9/6/2019 - created first firmware to start development
Built a firmware using https://nodemcu-build.com/ with these modules (cron, file, gpio, i2c, mdns, mqtt, net, node, sjson, tmr, uart, wifi)
Uploaded the firmare using NodeMCU-PyFlasher-4.0
No issues with this firmware. I've been able to upload lua scripts and test them successfully. Even now, I can revert back to this firmware and use it without issues. I've even redownloaded this firmware from the original link, and it works fine.
9/7/2019 - created a new firmware to use adc and other goodies
Built a firmware using https://nodemcu-build.com/ with these modules (adc, cron, file, gpio, i2c, mdns, mqtt, net, node, rtctime, sjson, tmr, uart, wifi)
Uploaded the firmare using NodeMCU-PyFlasher-4.0
Having the problem described above.
9/8/2019 - built firmware with minimal modules
Built a firmware using https://nodemcu-build.com/ with these modules (file, gpio, net, node, tmr, uart, wifi)
Uploaded the firmare using NodeMCU-PyFlasher-4.0
Having the problem described above.
Platform & Tools
Windows 10
Development board: HiLetgo ESP8266 NodeMCU LUA CP2102 ESP-12E Internet WiFi Development Board Open Source Serial Wireless Module
Firmware builder: https://nodemcu-build.com/
Serial Monitor: PuTTy 0.72
Firmware Loader: NodeMCUPyFlasher 4.0
Lua script loader: nodemcu-tool 3.0.2
fetchDeviceInfo() first calls node.info() at https://github.com/AndiDittrich/NodeMCU-Tool/blob/master/lib/connector/device-info.js#L9. Then it does an if-else to figure out whether it's running on ESP8266 or ESP32.
With the recent upgrade to SDK 3.0 node.info() was changed in PR #2830. See documentation at https://nodemcu.readthedocs.io/en/latest/modules/node/#nodeinfo. It now returns values the script doesn't consider to be coming from ESP8266. The script then calls node.chipId() in the else branch. So, it's getting a chip id from ESP8266 but it is expecting one from ESP32. Hence, the exception.
I have no idea what "Response: 6935962" means. Is that my chip id or an error code?
It's your chip id.
To cut a long story short: NodeMCU-Tool needs to be adjusted as laid out above to work with the current NodeMCU version.
I cached the same issue from the recent cloud build(https://nodemcu-build.com/). It works when i switch back to the old ones. It looks like a problem of the build system or recent source code. You can switch to other build method and try use the older code.
Related
I have an issue with spiffs and arduino.
I'm using ESP07 with 1mbyte of spi flash memory. I'm using arduino IDE.
I have 16 files in my file system being sketched with the option "tools -> ESP8266 Sketch data upload". If i selected 256kbytes as SPIFFS size all works fine. All files are there and the system works fine.
But if I use 512 kbytes for SPIFFS only 8 files are there after using the same "tools -> ESP8266 Sketch data upload" option.
I have verified my flash spi memory with the demo included in arduino IDE "CheckFlashConfig", it is 1mbyte.
I need to use the 512 kbytes model because the customer can upload a file that can be too big for 256kb spiffs model.
As curious stuff, I selected 2 mbytes (even when memory is 1mbyte), asigning 1.5mb/512kbspiffs and it worked fine (probably because the last bit address was ignored and it worked over 1mbyte really doing it 512/512).
I have the option to upload all those files manually and it will probably work but it is slower than just burn the memory in production.
Is it a SPIFFS bug? a problem with spiffs in arduino o maybe something that i'm missing?
Thanks.
NOTE: I'm using esp8266 community version 2.5.0 package
Since I am not allowed to comment:
Please upgrade to ESP8266 v2.6.3:
The SPIFFS as standard file system has been replaced by LittleFS (means small changes in code if using the DIR opject), but offers improvements in regard to reliability.
For testing choose Generic ESP8266 with this params 1MB (FS:512KB OTA:~246KB)
If the problem (unlikely) persists or you dont nred OTA check the partition schemes in
the following boards.txt
C:\Users\YOURUSERNAME\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\X.X.X\
dependingon theversion can be 2.5.0 or 2.6.3
- you can define your custom scheme if you like
I'm new at zynq board. I am trying to work with XADC of zynq-xc7z020 and want to see its quality for my application through vivado and xilinx SDK.
I tested two ways of designing through lab3 and lab4 tutorials. Synthesis, implementation and generating bitstream are OK in vivado. in the Xilinx SDK, after programming of the board, when I run a simple printf through system debugger or GDB but I get "AHB AP transaction Error". I googled it a lot and spent few days for it, but didn't get any solution. Additional, I tried to connect to the arm core of the board through XMD console by "connect arm hw" command. but console get JTAG connection error, while JTAG cable is connected and programming of the board is done.
suggested solutions of here didn't help.
thank you.
I understand what my mistake was.
Through XSCT console in SDK, I run mrd command to access DDR and read its address. but I couldn't. So I got that the problem was from DDR configurations.
I create a new project and at the first step of designing, after adding ZYNQ7 Processing System to block design, click on 'run block automation' and continue all previous steps and it worked. The point was that automation run. It sets some auto configuration of block that have to be set; and my mistake was this, that I connected DDR port manually.
For development purposes I have been using the "NodeMCU Firmware Programmer" to flash the firmware to the ESP-12 NodeMCU Dev Kit V2, and then using ESPlorer to upload the lua files.
This works well for development purposes, but now we are moving into commercial production.
Is there a faster way (one-step?) to upload both the NodeMCU firmware and lua files? I need to program between 1-5k units per month.
Yes, there is a one-step way.
You first build a file system image using spiffsimg and then flash both the firmware and the image to the device (with esptool.py I suggest).
For a project I need wps support in the nodemcu firmware. To enable that I have added wifi.wps.* commands in app/modules/wifi.c and I have added -lwps to the Makefile in app. All builds well, but after flashing the firmware I get problems in that the firmware reboots in a loop.
Commenting out the calls to libwps.a and only having the lua commands in place makes the problem disappear. Is there a know issue, why there is no wps support in nodemcu?
I have a clone of the nodemcu git repository and a docker build environment for building the firmware.
Arnulf
Found the problem myself. There seems to be a limit of the firmware size of 512 KB. I removed some modules when building to stay under that limit and then all worked as expected :)
Found out that if I use the ESPTOOL_FS environment variable of esptool.py to set the correct flash memory size, the firmware size can be greater than 512K and there are no problems starting the module.
Context:
I am writing a program, which uses pcap to capture packets in the monitor mode on the openwrt router with ar9331 chip.
I tested the program on a desktop with pcap 1.1 (which existed in my openwrt version) and found an issue: pcap_can_set_rfmon returned true, pcap_set_rfmon returned success, but attempt to activate capture resulted in “monitor mode isn't supported” error.
Google search showed a bug report of similar issue with wireshark. One of the comments says that with some wi-fi devices the issue is caused by an old version of pcap, which uses old version of another lib.
I updated pcap version to 1.5.3 and the issue was resolved.
Problem:
The issue appears again when I port our program to Openwrt. But now update of libpcap package to version 1.5.3 from newer openwrt branch doesn't help.
Sadly, the libpcap monitor-mode code on Linux works best when libpcap is linked with libnl, and it's often not linked with libnl for various reasons (including problems with a program using libpcap and libnl, and linked with a different version of libnl than the one with which libpcap is linked).
This needs to be redone in libpcap. It may end up being done with a "helper process" that libpcap runs to do various things; that would also improve cleanup if the program using libpcap exits abnormally and would allow packet capture operations requiring special privileges to be confined to the helper process rather than requiring the program using libpcap to run with those privileges. This is on my rather long to-do list.
The best workaround is probably to use airmon-ng to turn monitor mode on, as described in the Wireshark Wiki page on Wi-Fi capturing.