Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot seem to connect to xsbug on example helloworld #177

Closed
jim80 opened this issue May 3, 2019 · 22 comments
Closed

Cannot seem to connect to xsbug on example helloworld #177

jim80 opened this issue May 3, 2019 · 22 comments

Comments

@jim80
Copy link

jim80 commented May 3, 2019

Hi, I've got a bit stuck here, I've followed the getting started docs with no problem, had a small problem with upload speed, overcome that and everything builds and is uploaded to wemos D1 mini. However, It does not seem to connect to xsbug. Terminal output is below - I suspect a problem with the serial speed, since initially upload did not work at the default, I tried the same speed (115200) that worked for upload for the debug connection (see end of terminal output, restarted the 8266 on the manual switch, but no joy with that.
Any pointers would be much appreciated, I'd really like to get this working!

`parallels@parallels-Parallels-Virtual-Platform:$ cd $MODDABLE/examples/helloworld
parallels@parallels-Parallels-Virtual-Platform:
/Projects/moddable/examples/helloworld$ mcconfig -v -d -m -p esp
/home/parallels/esp/ESP8266_RTOS_SDK/components/esptool_py/esptool/esptool.py -b 921600 -p /dev/ttyUSB0 write_flash --flash_freq 40m --flash_mode dout --flash_size 4MB 0x0000 /home/parallels/esp/ESP8266_RTOS_SDK/components/esp8266/firmware/boot_v1.7.bin 0x1000 /home/parallels/Projects/moddable/build/bin/esp/debug/helloworld/main.bin 0x3FC000 /home/parallels/esp/ESP8266_RTOS_SDK/components/esp8266/firmware/esp_init_data_default.bin
esptool.py v2.4.0
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: 18:fe:34:e0:c5:ae
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...

A fatal error occurred: Invalid head of packet (0xE0)
/home/parallels/Projects/moddable/build/tmp/esp/debug/helloworld/makefile:415: recipe for target 'debuglin' failed
make: *** [debuglin] Error 2
parallels@parallels-Parallels-Virtual-Platform:/Projects/moddable/examples/helloworld$ export UPLOAD_SPEED=115200
parallels@parallels-Parallels-Virtual-Platform:
/Projects/moddable/examples/helloworld$ mcconfig -v -d -m -p esp
/home/parallels/esp/ESP8266_RTOS_SDK/components/esptool_py/esptool/esptool.py -b 115200 -p /dev/ttyUSB0 write_flash --flash_freq 40m --flash_mode dout --flash_size 4MB 0x0000 /home/parallels/esp/ESP8266_RTOS_SDK/components/esp8266/firmware/boot_v1.7.bin 0x1000 /home/parallels/Projects/moddable/build/bin/esp/debug/helloworld/main.bin 0x3FC000 /home/parallels/esp/ESP8266_RTOS_SDK/components/esp8266/firmware/esp_init_data_default.bin
esptool.py v2.4.0
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: 18:fe:34:e0:c5:ae
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash params set to 0x0340
Compressed 4080 bytes to 2936...
Wrote 4080 bytes (2936 compressed) at 0x00000000 in 0.3 seconds (effective 124.7 kbit/s)...
Hash of data verified.
Compressed 419780 bytes to 269351...
Wrote 419780 bytes (269351 compressed) at 0x00001000 in 23.6 seconds (effective 142.3 kbit/s)...
Hash of data verified.
Compressed 128 bytes to 75...
Wrote 128 bytes (75 compressed) at 0x003fc000 in 0.0 seconds (effective 77.4 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
/home/parallels/Projects/moddable/build/bin/lin/debug/serial2xsbug /dev/ttyUSB0 921600 8N1
^C
parallels@parallels-Parallels-Virtual-Platform:/Projects/moddable/examples/helloworld$ /home/parallels/Projects/moddable/build/bin/lin/debug/serial2xsbug /dev/ttyUSB0 115200 8N1
^Cparallels@parallels-Parallels-Virtual-Platform:
/Projects/moddable/examples/helloworld$
`

@jim80
Copy link
Author

jim80 commented May 4, 2019

The Blink example works just fine, so I'm sure code gets onto device and run, by the way. Just no connection to xsbug :(

@lprader
Copy link
Contributor

lprader commented May 4, 2019

Odd. You shouldn't have to launch serial2xsbug manually, but I'm guessing you were trying that because the connection wasn't established automatically--is that correct?

If you launch helloworld on the simulator, does it connect to xsbug?

@jim80
Copy link
Author

jim80 commented May 4, 2019

It is indeed odd! Yes, once I had the -v option I could see serial2xsbug being launched and tried running it myself with different baud rates to see if it might make it work.
Yes, launching helloworld via the simulator connects to xsbug just fine - first thing I did!
I did skim readthe source for serial2xsbug, but nothing stood out to me (I should say I have extremely limited c skills, however). Is it connecting to xsbug via a network connection?

@lprader
Copy link
Contributor

lprader commented May 6, 2019

Is it connecting to xsbug via a network connection?

It's connecting to xsbug via serial.

Looking closer at your terminal output, it looks like you might be running Linux on a Mac using Parallels. If that's true, can you try setting up your host environment for Mac instead and see if that fixes the problem?

@phoddie
Copy link
Collaborator

phoddie commented May 6, 2019

Reinforcing @lprader's point, if you are running under Parallels, there are a few more layers to get the USB serial connection, which could possibly be causing problem.

serial2xsbug is a bridge. It connects to USB to communicate with the microcontrollers using serial. It connects to xsbug using a network connection. It shuttles messages back and forth between the two.

If you launch serial2xsbug manually, you will need to press the reset button on the microcontroller afterwards. On boot, the microcontroller sends the xsbug login message once. If serial2xsbug is not running to receive that, it is lost and the debugging connection will never be established. Reseting the device causes the login message to be sent again.

@jim80
Copy link
Author

jim80 commented May 7, 2019

Yes, I did suspect parallels being the problem - My osx is one version too old to compile the source though. I'll ask a colleague if they can cook it up for me perhaps. Yes, I understand about the button/login message, thanks, I'd assumed that was the case since I can see the code resetting it.
serial2xsbug is silent on the loopback interface when run, if I compile helloworld example for linux then i see packets to and from 5002. Maybe I should try it as root.
Anyway, I'll dual boot my chromebook from a flash drive and see if that works for me.
Many thanks for your time.

@jim80
Copy link
Author

jim80 commented May 25, 2019

Ah. I just got myself an esp32 board, and it works for that.
Unfortunately I don't have the wemos 'D1 mini 8266 I was using before with me right now or i'd try that again.
The serial chip is probably different on this one, but then I'd tried using another 8266 with yet another chip (I forget which one, and I don't have that one to hand either).

However, in setting up for the esp32 it seemed some of the python tools required needed python 3, so I aliased my python to use v3.
I'd hazard a guess that this might make the difference.

In addition, I performed this step in the esp32 getting started guide - it may be pertinent..
"Set the UPLOAD_PORT environment variable in your ~/.bashrc to the ESP32 serial port:

UPLOAD_PORT=/dev/ttyUSB0
export UPLOAD_PORT"

I'll check when I'm reunited with my box of 8266's and confirm one way or another...

@jim80
Copy link
Author

jim80 commented May 26, 2019

So - still not working under parallels for the Wemos D1 mini 8266.
Is it the serial chip?

working on esp32 - (from lsusb) "Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light"

Not working on 8266 - "QinHeng Electronics HL-340 USB-Serial adapter"

Connecting another 8266 via a usb-ttl adapter - " Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light". - not working !

So it appears not.

Oh well! The only other thing I note is that running the esp32build with the -v verbose option does not show the line "/home/parallels/Projects/moddable/build/bin/lin/debug/serial2xsbug /dev/ttyUSB0 921600 8N1" - maybe it works a little differently?

Anyway, just leaving this here in case the info proves useful to anyone in the future, I should have it all set up under Mint on my chromebook booting from USB now, so I have options... I'll go give that a try now.

@wilberforce
Copy link
Contributor

@jim80
When you plug in each device - the /dev/tty/USBx might be changing....

ls -l /dev/ttyU*
then plug in the device and look for changes

@jim80
Copy link
Author

jim80 commented May 27, 2019

Many thanks for the thought @wilberforce , but no, not that.
I've just run it through with a linux machine, rather than parallels virtual machine under osx, and I'm getting exactly the same results, my esp32 works, my esp8266's do not - they don't connect to xsbug.
I don't know, maybe a hardware issue? maybe I'm running on untested hardware, but the wemos mini is common enough so far as I know. Maybe I should buy something known to work and test that?
What devices are you using for esp8266
Thanks for your input in any case, I'll be having a test of your onewire temp sensors code soon enough...

@barbiani
Copy link

barbiani commented May 27, 2019 via email

@jim80
Copy link
Author

jim80 commented May 27, 2019

Ah, that's what I suspected after getting some trouble with baud rate on the upload.
I tried "/home/parallels/Projects/moddable/build/bin/lin/debug/serial2xsbug /dev/ttyUSB0 115200 8N1"
where 115200 worked to upload to device where 96whatever did not.

Which build file should I be looking at @barbiani ?
many thanks for your input, much appreciated. Jim

@jim80
Copy link
Author

jim80 commented May 27, 2019

@wilberforce
Copy link
Contributor

What devices are you using for esp8266
NodeMCU type board (4mb) and a sonoff basic with 1Mb flash

The baudrates I seen used by xsbug are 460800 and 921600

Searching here:
https://github.com/Moddable-OpenSource/moddable/search?q=921600&unscoped_q=921600

It seems that an env var is used DEBUGGER_SPEED ?= 921600 but it's not consistent across the makefiles

@jim80
Copy link
Author

jim80 commented May 27, 2019

https://www.youtube.com/watch?v=daWObuUptrQ

Apologies! I think there may be something in this, but it's late here and I'm off bed, many thanks for your help guys!

@phoddie
Copy link
Collaborator

phoddie commented May 27, 2019

The serial connection baud rate is consistently 921600 for ESP866 and 460800 for ESP32.

@jim80
Copy link
Author

jim80 commented May 27, 2019

921600 didn't work for the 2 8266's I tried, I fixed that (for the upload, at least) with "export UPLOAD_SPEED=115200", which I seem to recall I found somewhere in a now closed issue.

@jim80
Copy link
Author

jim80 commented May 27, 2019

Ok, after all that, it's looking like it's the baud rate, for the 8266 hardware that I have.
Changing lines 66 / 68 in build/devices/esp/main.cpp to replace 92100 with 115200 made it connect to xsbug in helloworld :

e.g -
gUART = uart_init(UART0, 115200, SERIAL_8N1, SERIAL_FULL, 1);

Of course I'll lose this change next time I update, could it be made configurable for the esp build?

Thanks for the help everyone, much appreciated! Apologies for the noise also.
I'm happy I've got it to work.

@phoddie
Copy link
Collaborator

phoddie commented Jun 26, 2019

Glad you solved that. I haven't seen an Espressif board in long time that needs to operate at 115200. Is it an unusual board or perhaps a low quality USB cable?

@mkellner
Copy link
Collaborator

In the next open-source drop, the esp8266 will now respect DEBUGGER_SPEED in addition to UPLOAD _SPEED.

Set DEBUGGER_SPEED from the command line. Make sure that build/devices/esp/main.cpp is rebuilt to pick up the DEBUGGER_SPEED change (ie. # touch $MODDABLE/build/devices/esp/main.cpp then use mcconfig.)

@jim80
Copy link
Author

jim80 commented Jun 27, 2019

I've got about 5 cables, and no reason to doubt any of them. I did try a few different ones early on just to see if it made any difference, but it didn't. I also eliminated power supply as a factor.
On 8266's I have 3 Wemos D1 minis, genuine ones bought from Wemos a couple of years back, and another small scale UK made dev board with no usb onboard - nothing special about it really, but that must be 2 years old I guess, maybe more.
Nothing unusual about the Wemos boards, I think they are now a pretty cheap standard china clone item?
But mine are a couple of years old at least, maybe the design got updated since then? I seem to recall something about the clock frequency being a little unusual on some 8266 boards, which might well explain the baud rate changing/no longer working.
Don't know really! It would be nice if the rates could be configurable, and anyone new to moddable got a heads up in the docs, but if it doesn't seem to be problem then maybe not.
Cheers anyway! Jim.

@jim80
Copy link
Author

jim80 commented Jun 27, 2019

@mkellner thanks! We crossed over a little there...

mkellner added a commit that referenced this issue Jul 3, 2019
(esp8266)
respect DEBUGGER_SPEED on esp
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants