Couple of things to try.
On this board Serial is supposed to be a symbolic link to Serial2
HardwareSerial myserial(USART2_RX, USART2_TX);
setup() {
myserial.begin(115200);
delay(1000);
myserial.print("please print out!");
....
Might need to check i got rx/tx order right in args
Hi @Owen_Williams,
Thank you for your suggestions!
To be sure that we are on the same line: We are both talking about serial over usb right?
I tried both things and it does not help. It is weird because it looks like the code completely blocks after putting something about serial (just serial, serial2 and myserial) in the sketch. If for example in the setup the light must blink, and after that start serial, than it will not blink before serial begin. So it looks like it just completely blocks the code. When serial is removed, the light will blink.
For your own ESC: You do not need to do something special right with serial?
I am thinking about what I did different than you in the configuration of the ESC and the only thing I can think of is that I updated the firmware of the st link. So maybe it has something to do with that? I am going to try to put the original firmware on it. I will keep you up to date!
Do you have other suggestions? Or maybe some crucial steps in the configuration that if might have forgotten to do?
Greetings,
Wittecactus
Yes I’m using usb to program and print / serial. Do you have anything attached to rx/tx on the board? If so remove them as the rx/tx is shared/used by the daughterboard - it kind of proxies the serial comms using same pins.
Can you trying to remove the new line
build_flags =
-D PIO_FRAMEWORK_ARDUINO_ENABLE_CDC
Also - are you using platformio to connect to serial? It seems better at ‘finding the right port’ than other tools such as arduino serial monitor.
I can actually debug that board in platformio e.g. go to run > start debugging and put a break point on Serial.begin(). If you can get debugging working, it I may reveal what the issue is. I may have done some funky things with openocd to get debugging working.
Your issue is puzzling. Do you have an #include <Arduino.h> at the top of your main.cpp - this is needed because platformio does not automatically do this for you (unlike Arduino IDE)
Hi @Owen_Williams,
You solved it for me! It was the new line… Sorry for wasting your time 
. I was so used working in C/C++ past time that I forgot the enter sensitivity on python-ish coding languages.
Because I always get great help from this community, I wanted to do something back and make a new topic on this forum with a small guide on how to set up this board. Is it good that I link some of your videos of you in that post?
Greetings,
Wittecactus
More than happy! I’m glad that I could help. Did you try the debug? I’ve not heard of anyone else getting it to work.
Hi @Owen_Williams,
I did not try debugging! I am not really familiar with that, I am going to try it. I will keep you up to date!
Greetings,
Wittecactus
“Let’s say the mosfets are 90% efficient (unlikely)…”
That’s right. Mosfets are much more efficient than that and these little monsters are rated at a whopping 120 Amps.
specs
Welcome @Jan_Donker.
I’m embarrassed to say I’ve not pushed these tiny boards that hard and haven’t attempted to add heat sinks. I’d be interested to hear what continuous power people can get out of them.
This is not exactly scientific but I tried a power test with this drone kit.
The board’s datasheet has max 6s battery so I fed it 24V from psu and set the voltage_limit=12. My power supply can only manage 5A.
I put the motor into motor.controller = ControlType::angle mode and asked it to hold zero position. By hand, I forced the hoverboard motor clockwise until it reached about 4A from psu. At this point the motor.monitor() was saying that voltage_q was about 6V (hoverboard resistance is quite low). i.e. I was well below my 12v voltage_limit.
The PSU said it was delivering ~100W.
At this power the mosfets temperature (no heatsink apart from my finger!) rose moderately quickly i.e. in about 10s rose to ~50deg and 20s it was too hot to handle (90 degrees).
I’m going to attempt some maths! It’s been 25 years since I last used this stuff - so I’d appreciate someone (maybe @Antun_Skuric) checking my calcs/understanding
As simplefoc was saying voltage_q was 6V, and PSU said 100W.
voltage_q = 6
voltage_peak_2_peak = 12
voltage_avg = voltage_peak_2_peak / pi = 3.8
current = power / voltage = 100 / 3.8 = 26A
Something tells me that I’ve got the above (very) wrong ;). Go easy, it’s been a long while since I studied this!
Anyway, to push these little drivers much above 100W is going to require some decent thermal management.
I’m quite surprised at how much torque you can get out of 100W. I wold struggled to hold the motor for more than 20s.
Thanks @Owen_Williams for the test! Really appreciate it.
Also thanks for the calculation. In my opinion, you don’t need to re-calculate the sine-like PWM wave or take the resistance into account. 100W are 100W. So the 25V peak and 4A rms your PSU is showing are also going through at least 2 or at most 4 MOSFETs at the same time. So PWM apart (that’s what rms is for), they see “only” 4A. At least in my opinion. That’s far away from the claimed 40A peak by ST. But also not surprising giving the tiny package.
I don’t know how much an additional heatsink would improve. Any thoughts?! Or maybe also my simplified thinking above is wrong?!
You should understand that a motor-driver works just like a switched-mode powersupply (SMPS). It can transform voltages and current. It transforms 24 volts at 4 amps into 6 volts at a much higher current. There is also the problem that meter-readings cannot be trusted if the current is not pure DC. It might read peak or average or anything in between.
Thanks @Owen_Williams for all the information you have shared about SimpleFOC in combination with the B-G431B-ESC board.
Have you ever tried to get USART1 or USART3 to work on the B-G431B-ESC? I am now looking into getting USART3 to work by doing the following:
PC10 button → USART3_TX
PC11 CAN_SHDN → USART3_RX
PB9 CAN_TX → USART3_TX
I am using USART2 to communicate between an Arduino nano over software serial. However this is only half-duplex I think. So I can either receive or write code. For debugging it is handy to also be able to read out the B-G431B-ESC via USART3. Do you think this is possible?
Hi all,
thanks to all the info here and after some testing I managed to setup such an esc. My problem (now 
): Phase V is missing. See plot (try to upload separately, doesn’t work in that replay). I have two of those boards and after I run into that problem with the 1st I tested the 2nd out of the box and it shows exactly the same behaviour / bug. So unlikely that two new kits have the same HW bug …
I don’t see really what can go wrong. I looked into examples and copied the one, tried open loop 1st. I needed to change pin names to A_… but everything seems to be connected to the timer channels correctly:
BLDCDriver6PWM driver = BLDCDriver6PWM(A_PHASE_UH, A_PHASE_UL, A_PHASE_VH, A_PHASE_VL, A_PHASE_WH, A_PHASE_WL);
Does anyone have an idea?
Thanks!
don’t manage to upload a jpg … not my day today.
But I can clearly measure with an oscilloscope that phase U,W have voltage output as expected but phase V hasn’t.
Is there any way you could check if the MCU pin itself is outputting the PWM signal? I know the board is really tiny, so just asking.
yes, it’s really tiny… but maybe possible on the high/low drivers. That is the biggest package on the board. Will check schematics tomorrow. But I wouldn’t expect something different than on the H bridge output. Where should that come from…. But I will look a bit more in the oscilloscope….
At that point I’m wondering if anything could be damaged by ESD, so to make sure the problem is really the MCU not putting PWM on the pins. Yes, this is a very tiny board, you would need a needle probe and a magnifying glass.
I will try to do. I have all what I need for that. I will mask the neighbor pins with tape to make sure I don’t short something. But I ruled that out after I saw exactly the same behavior on the same output on one relatively new board and on a brand new one that I took out of the package…
If you can reproduce it then its in the code for sure.