Everything works perfectly over WiFi.
Using bCNC, I can connect with socket://esp32.local:23 and all seems to work perfectly.
The only thing that isnt working is the connection over USB.
I get the following message.
““
ets Jun 8 2016 00:22:57
rst:0x1 (POWERONRESET),boot:0x17 (SPIFASTFLASHBOOT)
configsip: 0, SPIWP:0xee
clkdrv:0x00,qdrv:0x00,ddrv:0x00,cs0drv:0x00,hddrv:0x00,wpdrv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:8896
load:0x40080400,len:5828
entry 0x400806ac
'utf-8' codec can't decode byte 0xff in position 0: invalid start byte
This is probably windows related because I can connect over USB with PlatformIO on my mac.
The problem occcures only with bCNC on mi Windows 10.
I should also mention that it was working before.
Maybe someone Have seen this before and knows what to do?
Thanks!
评论 (5)
#2 – bdring 于 2020-06-16
If you hold some pin low or high, it eliminates the ESP32 boot text.
#3 – blaisebarrette 于 2020-06-16
Wow! Looks like I opened a can of worms! I am clearly not as an advanced coder as you guys are. I will search the web based on the infos you gave me here and report if I find something.
Thanks for taking the time!
#4 – blaisebarrette 于 2020-06-16
Bad news!
I tested the GPIO15 pulled down at boot and sure enough, it no longer write that message… All BUT that funky UTF8 character!
Here is the message with GPIO15 floating:
“
ets Jun 8 2016 00:22:57
rst:0x1 (POWERONRESET),boot:0x13 (SPIFASTFLASHBOOT)
configsip: 0, SPIWP:0xee
clkdrv:0x00,qdrv:0x00,ddrv:0x00,cs0drv:0x00,hddrv:0x00,wpdrv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:8896
load:0x40080400,len:5828
entry 0x400806ac
�
[MSG:Grbl_ESP32 Ver 1.2a Date 20200613]
[MSG:Compiled with ESP32 SDK:v3.2.3-14-gd3e562907]
[MSG:Using machine:Cyclone PCB Factory]
[MSG:Axis count 3]
[MSG:RMT Steps]
[MSG:PWM spindle Output:2, Enbl:-1, Dir:-1, Freq:5000Hz, Res:13bits]
...
`
And here is the message with GPIO15 pulled to ground:
`
�
[MSG:Grbl_ESP32 Ver 1.2a Date 20200613]
[MSG:Compiled with ESP32 SDK:v3.2.3-14-gd3e562907]
[MSG:Using machine:Cyclone PCB Factory]
[MSG:Axis count 3]
[MSG:RMT Steps]
[MSG:PWM spindle Output:2, Enbl:-1, Dir:-1, Freq:5000Hz, Res:13bits]
...
“
I tried to connect it to bCNC with GPIO15 pulled down and that single culprit of a character keeps the connection from happening.
I’ll keep looking!
#5 – blaisebarrette 于 2020-06-16
Good news!!!
I had a strike of luck! In my platform.ini file I added this line:
boardbuild.fflash = 40000000L ; Custom FLASH Frequency
Because my same board kept rebooting with an other sketch at 80Mhz so I thought that this board was maybe more stable at 40Mhz so I added that line.
But here’s the strike of luck… I tried changing that line to
boardbuild.fflash = 80000000L ; Custom FLASH Frequency
and guess wha?!? That UTF8 character no longer shows up. I reverted to 40Mhz to confirm and back is the bad guy! 80Mhz again… gone!
So I now have my fully functional GRBL_ESP32 and I am a happy camper!
So if someone comes to you with that same problem, ask them to check the speed of their flash!
Thanks guys! Nearly two in the morning! Off to bed!
#1 – MitchBradley 于 2020-06-15
I will explain what is going wrong, but I don’t know exactly how to fix it because I am not plugged in to the bCNC community.
The problem starts when GrblEsp32 takes over the serial port from the ESP32 ROM boot code. It is that code, or something deep in the bowels of the ESP32 system, that generates the messages ending with “entry 0x400806ac”. Then GrblEsp32 starts running and takes control of the serial port. That “takeover” causes a glitch on the serial line, which looks like a serial protocol “start bit”. But there is no actual serial data following, so it appears as though a character with hex value 0xff was sent. 0xff is not a valid character in the ASCII character set, and most software will just ignore it.
But not Python. Depending on how a Python program sets up the serial line, one of the choices for interpreting data is UTF-8, which is a way to encode international characters using a stream of 8-bit characters. UTF-8 reserves some 8-bit character values as “start bytes”, which means that the character uses more than one byte. Some other bytes, particularly the ones with values between 0xf5 and 0xff, are invalid.
So what is happening is that bCNC, which is written in Python, is seeing that false character that is caused by the line-switchover glitch, interpreting it according to UTF-8 rules, and freaking out. Maybe there is some way to make bCNC use a different character set. UTF-8 is not a great choice for Grbl_Esp32, which does not use international characters for its messages.