Bug A very strange problem with serial communication

sometime my boot message is:
⸮ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
modeIO, clock div:1
load:0x3fff0030,len:1252
load:0x40078000,len:12732
load:0x40080400,len:3100
entry 0x400805ec
⸮Load
Axis 1: 100
Axis 2: 100
Axis 3: 100
Axis 4: 100
Axis 5: 100
Axis 6: 100
lpfVec vector loadedStarting BLE init!
init Estop check:0

and after compile control.ino, the message is :
Sketch uses 1168581 bytes (89%) of program storage space. Maximum is 1310720 bytes.
Global variables use 29544 bytes (9%) of dynamic memory, leaving 298136 bytes for local variables. Maximum is 327680 bytes.
esptool.py v3.1
Serial port COM3
Connecting....
Chip is ESP32-D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 3c:61:05:14:ec:f0
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00001000 to 0x00005fff...
Flash will be erased from 0x00010000 to 0x0012efff...
Flash will be erased from 0x00008000 to 0x00008fff...
Compressed 8192 bytes to 47...
Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.1 seconds (effective 605.0 kbit/s)...
Hash of data verified.
Compressed 17168 bytes to 11592...
Writing at 0x00001000... (100 %)
Wrote 17168 bytes (11592 compressed) at 0x00001000 in 1.3 seconds (effective 104.6 kbit/s)...
Hash of data verified.
Compressed 1174352 bytes to 724463...
Writing at 0x00010000... (2 %)
Writing at 0x0001a746... (4 %)
Writing at 0x000239cc... (6 %)
Writing at 0x0003644e... (8 %)
Writing at 0x00040313... (11 %)
Writing at 0x00045e08... (13 %)
Writing at 0x0004b8a9... (15 %)
Writing at 0x00050e28... (17 %)
Writing at 0x000562fc... (20 %)
Writing at 0x0005c466... (22 %)
Writing at 0x00061cf8... (24 %)
Writing at 0x000673ce... (26 %)
Writing at 0x0006c887... (28 %)
Writing at 0x00071ccc... (31 %)
Writing at 0x00077fe8... (33 %)
Writing at 0x0007db49... (35 %)
Writing at 0x00083320... (37 %)
Writing at 0x00089049... (40 %)
Writing at 0x0008ea42... (42 %)
Writing at 0x00094261... (44 %)
Writing at 0x00099d1f... (46 %)
Writing at 0x0009f479... (48 %)
Writing at 0x000a4c7d... (51 %)
Writing at 0x000aa56c... (53 %)
Writing at 0x000affbb... (55 %)
Writing at 0x000b54c1... (57 %)
Writing at 0x000ba86c... (60 %)
Writing at 0x000c015c... (62 %)
Writing at 0x000c5f29... (64 %)
Writing at 0x000cc306... (66 %)
Writing at 0x000d2084... (68 %)
Writing at 0x000d7e79... (71 %)
Writing at 0x000de37f... (73 %)
Writing at 0x000e6096... (75 %)
Writing at 0x000edb53... (77 %)
Writing at 0x000f4c83... (80 %)
Writing at 0x000fa45e... (82 %)
Writing at 0x00101aac... (84 %)
Writing at 0x001086dc... (86 %)
Writing at 0x0010fae4... (88 %)
Writing at 0x001170e4... (91 %)
Writing at 0x0011c9cf... (93 %)
Writing at 0x001228a0... (95 %)
Writing at 0x00127b90... (97 %)
Writing at 0x0012d58d... (100 %)
Wrote 1174352 bytes (724463 compressed) at 0x00010000 in 64.0 seconds (effective 146.8 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 128...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (128 compressed) at 0x00008000 in 0.1 seconds (effective 350.8 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...

Try this one.

https://www.silabs.com/developers/usb-to-uart-bridge-vcp-drivers

It should ALWAYS report that,.. or variations of it depending on your setup. I suspect the connection is dying,.. and possibly because of the driver you are using,.... I vaguely remember having driver issues early on.. I would start with changing the driver used for the esp32

This looks fine.

I uncomment the DEBUG_NO_ESTOP and DEBUG_MOTORS
the start message is :
ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
modeIO, clock div:1
load:0x3fff0030,len:1252
load:0x40078000,len:12732
load:0x40080400,len:3100
entry 0x400805ec
⸮Load
Axis 1: 100
Axis 2: 100
Axis 3: 100
Axis 4: 100
Axis 5: 100
Axis 6: 100
lpfVec vector loadedStarting BLE init!
⸮0,0,0,0,0,0,
0,0,0,0,0,0,
0,0,0,0,0,0,
0,0,0,0,0,0,
0,0,0,0,0,0,
0,0,0,0,0,0,
0,0,0,0,0,0,
0,0,0,0,0,0,
0,0,0,0,0,0,
0,0,0,0,0,0,
0,0,0,0,0,0,
.........

Because I use CH9102 vesion ESP32, so I install the 9102 driver.

With those 2 uncommented - this will ignore the estop, as well move very slow.. so you can visually confirm and count steps each motor performing -

the esp32 will spit out every second or so, the current motor position 0,0,0,0,0,0 means they are all at home position, this is a separate meaning than the signal that comes from simtools.

Now send the commands over serial monitor -

• "2047,2047,1047,2047,2047,2047X" - will lower all the arms
• "2047,2047,3047,2047,2047,2047X" - will raise all the arms
• "2047,2047,2047,2047,2047,2047X" - will put all arms at home 0,0,0,0,0

This still may be the root cause, I am not ruling it out just yet,... you seem to be having difficulty communicating to it. .. if you cant send commands to the esp32... then we are stuck

I change your code:
void setupBle(){

Serial.println("Starting BLE init!");
#ifdef DEBUG_ESP
Serial.println("BLE init 0");
#endif
BLEDevice::init("Open 6DOF Services");
#ifdef DEBUG_ESP
Serial.println("BLE init 1");
#endif
BLEServer *pServer = BLEDevice::createServer();
#ifdef DEBUG_ESP
Serial.println("BLE init 2");
#endif
pServer->setCallbacks(new ServerCallbacks());
#ifdef DEBUG_ESP
Serial.println("BLE init 3");
.....
and the message :
Axis 1: 100
Axis 2: 100
Axis 3: 100
Axis 4: 100
Axis 5: 100
Axis 6: 100
lpfVec vector loadedStarting BLE init!
BLE init 0

it look like the ble is not init

and that is fine,.. comment out the ble stuff ( //setupBle(); ),... we dont need it.. do you get any furthur?

yes, "estop check" can see
Axis 1: 100
Axis 2: 100
Axis 3: 100
Axis 4: 100
Axis 5: 100
Axis 6: 100
lpfVec vector loadedinit Estop check:0

Can you send a command to it?
or does it still crash?

• "2047,2047,1047,2047,2047,2047X" - will lower all the arms
• "2047,2047,3047,2047,2047,2047X" - will raise all the arms
• "2047,2047,2047,2047,2047,2047X" - will put all arms at home 0,0,0,0,0

I wired the PCB and send the below data, the 9pin raise its voltage, but when I connect the servo, the servo cannot move. And the 9pin lost its voltage.

• "2047,2047,1047,2047,2047,2047X" - will lower all the arms
• "2047,2047,3047,2047,2047,2047X" - will raise all the arms
• "2047,2047,2047,2047,2047,2047X" - will put all arms at home 0,0,0,0,0

1) In the output of the serial, do you indeed see the 0,0,0,0,0,0 values, change after you submit the command?
2) the pins voltage only go high when needed and very fast switching..., after you submit a command that could be over in a split second....so its expected to turn off,...

I uncomment the DEBUG_MOTORS and DEBUG_NO_ESTOP and type your data in the serial monitor, I can see the number of servo position change slowly from 0 to increase to very big and then decrease to 0. But I connect the servo to the pcb ,the servo don't move.

ok, well then we know more information.
1) you are sending commands to the board and the logic is reacting. and your serial port is working.

the reason your servos are not working could be a thousand reasons..

didnt you say in the youtube thread that the motor does move, when you use the PCB_debugger.ino program?

that would indicate that the motor is setup correct,.. and would move 1 position every 5 seconds or so....

the Controler.ino code should drive them the same way,.

Have you checked for the same results on each of the motor ports,...

Post a good picture of your PCB......maybe there is something I am missing...

Those look good, nothing jumps out at me.

I remember someone reversing the multiplexer once... I was looking for something like that...

didn't you say in the youtube thread that the motor does move, when you use the PCB_debugger.ino program?

that would indicate that the motor is setup correct for "position mode",.. and would move 1 position every 5 seconds or so....

do you have a powered USB hub you can use?

My thinking is this,... maybe your PC is not suppling enough power to activate all of the circuits and then activate the 5v at the servos? ... if you use a Powered USB hub, that has its own clean 5v power source.. maybe that will be enough to drive the motors..... or try a different usb port?... or different computer?.. running out of ideas...

you would need to create a simpler test if you cant get this to work,... a simple circuit to drive the motors manually,.. just to verify pins/ports are working....