Sketch Fails to Load via USB to ESP8285 using Linux #5073
Comments
Platform
Settings in IDE
Problem DescriptionAttempt using Module: [Generic ESP8285 Module] and set "Flash Size: 1M (No SPIFFS)" and same still open Examples>01.Basics>Blink sketch with the ESP8285 board and ESP8266 core for Arduino V2.4.2.
Debug MessagesCompiler related detailed messages: |
Settings in IDE
Problem DescriptionUsing USB to compile/upload Examples>01.Basics>Blink sketch to an ESP8285 using "Board: Generic ESP8285 Module". Sketch upload via USB using 9600 based on further searching and reading fails on what I believe is the "serialport_receive_C0: 00 instead of C0" part of upload detailed messages. Placed upload detailed messages in the Debug Messages section.
Debug MessagesCompiler related detailed messages: |
keypunch416
changed the title
Platform
Settings in IDE
Problem DescriptionAttempt using Module: [Generic ESP8285 Module] and set "Flash Size: 1M (No SPIFFS)" and same still open Examples>01.Basics>Blink sketch with the ESP8285 board and ESP8266 core for Arduino V2.4.2. Sketch upload via USB using 9600 based on further searching and reading.Sketch upload via USB fails on what I believe is the "serialport_receive_C0: 00 instead of C0" part of upload detailed messages. Placed upload detailed messages in the Debug Messages section.
Debug MessagesCompiler related detailed messages: |
|
repeating the same entry over and over again will not speed up anything. The
is an indication of a communication problem, the module boot loader does not answer correctly on the status request of the esp flasher. Maybe it is not in "flash mode" due to wrongly selected reset methode? Did you ever considder the module or cable you are using to be faulty? Or try uploading the resulting binary (or even AT firmware) with another flashing software? For this type of "requests" please use an appropriate user forum like www.esp8266.com and close this issue ... |
|
Too late now here. Additional testing post 5chufti comments using at least three different USB cables indicates the USB cable is not issue. Tested (Micro) USB cable normally use and two other (Micro) USB cables with Arduino DUE programming port and all work perfect with Due. Issues of past and current with ESP8266 and same issues with ESP8285 persist. Additional creative testing indicates interesting results with the ESP8266 Core (V2.4.2) that I do not have time to post the details. I made the effort to post the details because I cannot assume I know what may, or may not, be a factor in the issue(s). I do know from my many years of software problem analysis that some problems like this one that I have been trying to figure out for a year on the assumption I was doing something incorrect are not always as the problem initially seems to be caused by. Key word here "not". It means I may be doing something incorrect, or not. That said, the creative tests I have done quickly that will take time to post the results details suggests there may be more to this issue than I was assuming over the past year. The past year I was assuming I was at fault in some manner. This means I did not report this issue over the time I noted previously of issue(s) existing in V2.3.0, V2.4.0, V2.4.1, and V2.4.2 to same net effect. This is far from the first time I have suspected cables and have tried many different USB cables over the past year that all work with STM32 devices, ESP32, and the Due that have a Micro USB as opposed to Mini USB never having a glitch in loading sketches. Linux is noted as it is the OS these issues were experienced with. I do not have Windows, nor have had Windows on any machine of mine. Therefore I cannot do any comparative tests with Windows. |
|
esp8285 are DIO and 1MB (only, when you select generic esp8266 board) |
|
@d-a-v but this (DIO, 1MB) should not cause any basic communication problem like this. |
|
This is why as I noted in my entries with the ESP8266 tests I selected "Flash Size: [1MB (no SPIFFS)]". Did the ESP8266 test using DIO and "Flash Size: [1MB (no SPIFFS)]" to the ESP8285 board. Failed, but different messages for failure. I need to go to sleep soon. Saved screen shot from Tools and Arduino detailed text output. Key appears to be different failed results from load via flash of sketch, but still fails. My creative tests hinted in my last post I think will be interesting. I will not be able to redo those tests and save those results until later tomorrow or the following day. I think those tests wil indirectly answer question about different reset method. @5chufti I would suggest to you that if three USB cables, including one I used with the ESP8285 all work with the Arduino Due then the communications failure is "probability" not the USB cable. Further based on test I did for d-a-v and the creative tests I did since your first comment it suggests the issue is not likely the USB cables. |
|
@keypunch416 I didn't mention cables except for the first reply, seems you need a good nights sleep ;) |
|
Comm errors like these are documented for the most part, and their occurrence are usually bad hw (faulty, wrong design, bad power source, wrong reset circuit, etc), bad cable, bad reset (wrong type selected, done incorrectly, etc), user error (wrong IDE settings,etc), or similar. I don't remember seeing an issue where a comm error turned out to be a bug in the core or its tools. |
|
Sorry, but I believe this is a bug based on the quick additional testing I did last night I did not have time to save the results at time with intent of redoing those interesting reveling tests that in combination with testing the thre USB cables with Zero and Due all worked just fine. Given the ongoing assumptions this is a hardware or USB cable issue that has been already proved not to be case I feel there is no point in my making the effort to prove there is a good possibly of a bug based on the interesting quick test results that can be duplicated 100%. It appears there is little to no interest in this being considered a actual issue/bug. Therefore I will not spend my time to demonstrate given assumptions despite the "for most part", "usually" or " turned out to be a bug". I have worked with software and software engineers as a career for 45 years. I know first hand how many times the engineering teams I worked with dismissed a customer bug I spent some time in lab testing to validate the bug the engineers denied as being a bug. A bug report with automated scripts and/or custom "C"/scripts delivered to engineering with the repeatable test case. Only after alot of time, at times a few months, engineering had to admit as a bug after where I spent much time and effort explaining as the bug reports were the simple and summarized issue in a package sent to engineering with all the technical details and background to arrive at comfirming the customer issue being a bug in the bug log. I had the same extended duty cycle with bugs of similar nature where developers claimed the bug did not exist. In one a few of these cases these bugs actually brought down the national systems for several hours each day that management claimed was not occurring, but the first line support staff were dealing with the hours of system down each day as result not knowing the why and developers denying the bug report opened for months that was actually getting much worse with each code drop. A bug in the end management had me assigned to developers to help them them to fix what actually several bugs all pilling up to the one major overall bug. Be clear I am not patting myself on the back as I had other customer or QA bugs to address rather than do these types of battles that were in fact several months long, I kid not. For sure not all bugs/issues were this challenging technically or to have engineering address, but usually at least a handful a year were this way. Also many bugs that are reported to or found by the ESP8266 Library many users likely have not encountered and therefore did not know about. That means just because software engineer has not seen or believes there is a bug that no bug exists. It just means 99% of users do not see or know there was a bug. Given how I know how much time and effort it takes to prove an issue to engineers I will not spend time trying to convince there just may be an issue given the additional interesting testing I did last night quickly. Interesting testing that clearly needs the supporting documentation and observations to be logged and time I was willing to take to do so that now is now not considered to be helpful I will now not make the time or effort to do so. Please do not ask me to spend more time on this issue. Only one person seemed to ask important and useful information that I followed up with related test that clearly had very different results as I noted is short summary. There clearly is no interest of yourself in learning about these interesting results that were to be documented let alone I have already clearly tested that the USB cables were not an issue. |
|
Additional interesting tests now confirms issue is bug and not USB cables at all. Therefor bug is not a communications error despite error messages of issue indicating such. Will not document this nor the other interesting tests that now clearly prove this is a bug in the library. It means there are issue(s) in the library and/or tools. |
|
@keypunch416 Can you tell us exactly which esp8285 board is it ? |
|
This issue has been closed when I had indicated there was interesting information to still be documented in this issue. That means there was now no interest in the interesing information that clearly indicated the issue was not a communications related matter or the 99% of time isses. This notwithstanding I had clearly proven the USB cables were not the issue. I suspect those with the issues I reported in this issue and never stating what had been the issues over the past year that varied in ways that collectively and just on each issue of its own all clearly related to this same issue I opened would never be believed based on just rerporting current state as I did in this issue. I really do mean what was occuring in prior attempts one could not imagine in their widest dreams. This of course skips the point I made that I had been working on this for a year to resolve never having reported any of the prior cannot imagine issues with the prior versions of the libraries. My position remains the same. I will not put any more effort nor time to documenting this issue/issues as it it is clear it will take alot of my time and effort with the likely outcome of one or more times the issue will be closed again or that the issue is my error or some other cause than the ESP8266 Arduino library/tools. I have enough information from the additional and interesting testing I have done that has not been documented (was to be until issue was closed) and the follow on testing once the issue was closed prior to my providing the additional information when I have more time to look at the code and see if I can fix the issues as I see the issues. Should I get that far with the learning curve of the code for the issues I will make changes, validate and test the changes. If those changes resolve and/or address other secondary issues as I see them I will effect on my system, not on any code respository or online posting simply because even if I do experience has demonstrated, like this issue, the changes I make will be challenged and/or dismissed as not correct or meet the design in some manner. Far worse has occurred when I create patches for bugs or feature enhancements in past I had contributed multiple times multiple projects, so I no longer do so. In conclusion this issue is to remain closed. That is what many appear to wish or believe. So be it. I know from my years of on the job experience what the progression and path this issue would likley take and why. That is in a situation where that was my job to analyze or predict bugs and I have no interest in the challenges in that progression or path for a role known to the developers, technical staff, and devops from mainframe to embedded on any OS or hardware local to world wide systems internally or by customers that most of time I would never had known or used prior to the issue reported or I would predict bugs for. That means my career was based mostly on dealing with software issues on systems and software I had never seen or known about prior to the issues reported or being asked to predict for. I know what is involved and the time and challenges to make the case of an issue all too well. Ergo this issue remains closed as I have no interest in the challenges to justify reopening the issue. I have lost interest in reporting other ESP8266 Library issues I also know about that still exist or new with the 2.4.x releases I have added code to work about when I can to work about the issues new with 2.4.x. @d-a-v Thanks for your interest and concerns. This issue is now concluded. |
|
@keypunch416 I don't have 45 years experience working as a software engineer, but I do have 25 or so. Given that you're a fellow engineer I'm going to take the time to clarify a few things here. |
|
FWIW, the only readily available ESP8285 board with usb-serial adapter is D1 Mini lite, and i have ordered one to check flashing with esptool-ck on Linux. |
|
FWIW, I have some of them and I am regularly using esptool-ck under linux without any issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Basic Infos
Platform
Settings in IDE
Problem Description
Using USB to compile/upload Examples>01.Basics>Blink sketch to an ESP8285 using "Board: Generic ESP8285 Module". Sketch upload via USB fails on what I believe is the "serialport_receive_C0: 00 instead of C0" part of upload detailed messages. Placed upload detailed messages in the Debug Messages section. This issue has existed with ESP8266 core for Arduino V2.3.0, V2.4.0, V2.4.1 and now with V2.4.2.
Nano, Uno, Leonardo, Due, STM32duino (Maple Mini STM32F103), ESP8266 all work fine via USB using Arduino IDE 1.8.5 (and in past 1.8.2, 1.8.3, 1,8,4).
MCVE Sketch
Debug Messages
System Information:
Compiler related detailed messages:
The text was updated successfully, but these errors were encountered: