Closed mrwgx3 closed 6 years ago
jantje
commented
7 years ago I propose to give it a try by using the old esp tool for all boards.
That is "how it should be" anyway.
Can you change in the platform.txt the line
tools.esptool.path={runtime.tools.esptool-0.4.9.path}
to
tools.esptool.path={packages}/esp8266/tools/esptool/0.4.5
And test with both boards you have?
mrwgx3
commented
7 years ago Made the requested change to 'platform.txt' and didn't see any change in 'esptool' arguments:
LaunchingC:\SloeberBeR1\/arduinoPlugin/packages/esp8266/tools/esptool/0.4.9/esptool.exe -cd ck -cb 921600 -cp COM4 -ca 0x00000 -cf C:\Users\DELL\SloeberWork\Wksr1\blink_wtdelay_gdbA_r1p65/debug/blink_wtdelay_gdbA_r1p65.bin
Output:
warning: espcomm_sync failed
error: espcomm_open failed
error: espcomm_upload_mem failed
/arduinoPlugin/packages/esp8266/tools/esptool/0.4.9/esptool.exe finished
upload doneTo be sure we're both on the same page regarding file location and syntax...
I changed file 'C:\SloeberHrdw\jantje\ESP8266\platform.txt', where 'C:\SloeberHrdw' is where I unzipped your hardware install.
Here are the changes I've made so far to 'platform.txt'.
# ------------------------------
tools.esptool.cmd=esptool
tools.esptool.cmd.windows=esptool.exe
# Attempts to solve Huzzah Feather upload problem
# Jantje's suggestion
tools.esptool.path={packages}/esp8266/tools/esptool/0.4.5
# My attempt(s)
# tools.esptool.path={runtime.tools.esptool.path}
# Original, comment out when testing alternate
# tools.esptool.path={runtime.tools.esptool-0.4.9.path}
tools.esptool.network_cmd=python
tools.esptool.network_cmd.windows=python.exeBefore doing a test, I close and clean all projects, exit Sloeber, then restart it.
I too did a correction attempt on this file by doing a file search on '0.4.9' to locate the file, but got the same result. Since it didn't work, I assumed I entered an incorrect path specification and got a default invocation for 'esptool'. If there is such a check, could it be failing due to a corrupt string? Erroneous conditional compile? Just tossing out ideas...
jantje
commented
7 years ago have you done project properties->arduino->apply->ok?
mrwgx3
commented
7 years ago jantje commented 3 hours ago
have you done project properties->arduino->apply->ok?Didn't know that I needed to. Seems that I have to do this everytime I switch to a different project within the same workspace. Any way to do this automatically upon startup and/or change-of-sketch?
Progress has been made; I now see the expected 'esptool' version (old) and arguments, and the upload now occurs for the Huzzah Feather board. I still don't get a proper debug launch:
Error in final launch sequence
Failed to execute MI command:
-target-select remote /./COM4
Error message from debugger back end:
Bogus trace status reply from target: timeout
Bogus trace status reply from target: timeoutNote also that the blink LED turns on upon debugger launch, and turns off when the 'Problem Occured' message appears.
The Huzzah breakout board still works fine, good upload and debugger launch.
jantje
commented
7 years ago You only need to do project properties->arduino->apply->ok when you changed one of the underlying files. Note that V4.1 is better at noticing change and doing this for you. Did you see the comment of Paul van Veen?
Use \.\COMX instead of /./ !
mrwgx3
commented
7 years ago No, I hadn't. No difference between Use ' .\COM4 instead of /./COM4', still getting 'Error in final launch sequence'. Thanks for your help!
jantje
commented
7 years ago We are way out of my comfort zone here. So I don't think I can help any further. Someone more experienced in the whole gdb remote debugging will be more helpful. If you find a solution please feed back so I can modify Sloeber or the documentation.
mrwgx3
commented
7 years ago I've had a partial success, meaning that I've seen the debugger start correctly, but not consistently.
The whole problem to me seemed to be one of timing, i.e., things were just on the verge of working, but just not quite. I decided to do some baudrate tests, as this being the only timing parameter than be changed easily. To my surprise, I can get enter debugging mode if:
a) The upload baudrate is 115200 or below.
b) The debugger baudrate is also 115200 or below.It's surprising that the upload baudrate is a variable here; I suspect it might have something to do with the reset function. If you have any information on adjusting serial timing in Eclipse/Sloeber, it would be useful.
Ultimately, I'll probably need a logic analyzer to resolve the issue, a task for a later day.
jantje
commented
7 years ago You know far more about this than I do. Good :-) this way it can get fixed. The debug launcher is from gnuarm https://github.com/gnuarmeclipse the gnuarm documentation http://gnuarmeclipse.github.io/ or @ilg-ul can help you with " information on adjusting serial timing in Eclipse/Sloeber,"
jantje
commented
6 years ago Is this still a issue? Did you fix it? Can you contribute the fix to the repository?
mrwgx3
commented
6 years ago Hi @jantje
Yes, I believe its still an issue, but I haven't had the tools or time to look into it properly. Given my chedule, I'd mark this issue as 'needs to be looked into' and give it a low priority, or even close it. Best regards, mrwgx3
jantje
commented
6 years ago I'm seriously out of my depth here so I propose to close it and we can always reopen.
mrwgx3
commented
6 years ago I'm seriously out of my depth here so I propose to close it and we can always reopen.
I concur, close the issue.
Per Janjte's request, the following issue was closed in 'Sloeber/arduino-eclipse-plugin' and recreated here (san's Janjte's comments):
V4 ESP8266 Hardware Debug Works for 'Huzzah Breakout' board, but not for 'Huzzah Feather' board, #752
See https://github.com/Sloeber/arduino-eclipse-plugin/issues/752
1st Comment
Basic Infos
Hardware
OS, IDE
Description
Per your Youtube video on how to setup Sloeber for hardware debugging of the ESP8266, I successfully got debugging to work for the Adafruit Huzzah Breakout Board. The Huzzah Feather Board, however, seems to have timing issues with both the uploading of the debug sketch and initiating a debugger dialog.
Discussion
To facilitate testing, (2) 'blink' example projects were created:
Initially, only project A existed; project B was created after project A's debug sketch wouldn't upload. Project B's debug sketch did upload, and invoking the Debug perspective resulted in a successful debug session. Project A's debug sketch was then uploaded using the admin. command prompt to run a different 'esptool', but switching to the Debug perspective only resulted in a partial load and the following timeout message:
Hence it was concluded that the Huzzah Feather Board likely has some software/hardware timing issues.
Messages of Interest
Project B Compiler/Upload Messages, Successful Debug Session
Project A Compiler/Upload Messages, Failed Upload
Command Line Used to Succesfully Upload Project A's Debug Sketch (use version 0.4.5 rather than 0.4.9)
Requested Install Information
2nd Comment
Yes, that is correct; I've verified this for (2) separate installations. You did comment in the video that both the 1.65 and 2.30 SDK's were needed for debugging; I thought perhaps this was the reason.
To explore what 'esptool' version would upload Project A's debug sketch, I did some experimentation using the command prompt for:
Test case B was added as a cross-check, as my original circuit needs all the lines controlling the ESP-12 boot mode for I/O. During reset, external logic fixes these line states to insure proper booting, then connects them to where they're needed.
Included below are excerpts from my notes recording the command prompt results for various esptool uploads:
Given the upload failures for both Feather boards, I conclude my peripheral hardware is not affecting the outcome. A successful upload to the Breakout board indicates the Feather board may be a key variable.
Given all uploads worked using the 'older' esptool with identical args, it would seem the 'newer' esptool needs a different set of arguments. Hence its likely the invocation of the 'newer' tool here is most likely an error.
This last test would indicate that the 'newer' esptool doesn't have an intrisic fault; it just needs different args.
Given this additional testing, its likely that
would correct the problems seen the Huzzah Feather board.