10S custom skate ESC: testers wanted!

[lizard]

Hello,
A collegue compiled a windows version of BLDC-tools for me (revisiting some Qt serial port library) and this worked fine for setting the parameters and showing real time graphs.

It would be cool if you could put that online somewhere. Preferebly the BLDC tool for the firmware version that the VESCs from vedder came with

 

[pf26]

I put temporarly a compiled version for windows of Vedder BLDC-tools, along with the .dll you need and also the USB driver for ST (stsw-stm32102.zip)
http://www.omegawatt.fr/paille/bdlc-tool-windows.zip
No install required except for the driver. Just copy the .exe file and .dlls in a directory. Launch and write your COMx port in the top right window (connection group).
Please be aware that it failed to properly upgrade the firmware for me, and left the VESC requiring a programmer (by the way, can anyone confirm I can use a STM32F0DISCOVERY kit to program the STM32, using a straight 6 wires from P2- 6pin JST to SWD connector ?)
Once we make sure the soft works, we try to put it online on Github (never used so far, so it might take some time).

 

[silviasol]

I put temporarly a compiled version for windows of Vedder BLDC-tools, along with the .dll you need and also the USB driver for ST (stsw-stm32102.zip)
http://www.omegawatt.fr/paille/bdlc-tool-windows.zip
No install required except for the driver. Just copy the .exe file and .dlls in a directory. Launch and write your COMx port in the top right window (connection group).
Please be aware that it failed to properly upgrade the firmware for me, and left the VESC requiring a programmer (by the way, can anyone confirm I can use a STM32F0DISCOVERY kit to program the STM32, using a straight 6 wires from P2- 6pin JST to SWD connector ?)
Once we make sure the soft works, we try to put it online on Github (never used so far, so it might take some time).

I use this one http://www.ebay.com/itm/STM32F4-DISCOVERY-USB-STM32F407VGT6-STM32-ARM-Cortex-M4-Development-Board-/161564201263?pt=LH_DefaultDomain_0&hash=item259dfa112f

I am going to test out the windows bldc firmware now. To make the firmware upload inside the bldc tool work you also have to build and upload the bootloader:
https://github.com/vedderb/bldc-bootloader
To do that you need a discovery board.

 

[silviasol]

I just installed everything but am stuck at what to put for the port in the connection box. I see the STmicroelectronics Virtual COM Port (COM3) in device manager, what would the location be?

Ok got it, I am stupid it is just com3

Just upgraded from firmware 1.2 to 1.3. Worked perfectly!

 

[Vanarian]

I'm taking the trail with the new batch and sending back my units to Onloop, will need to be patient again!

 

[pf26]

Just upgraded from firmware 1.2 to 1.3. Worked perfectly!

Great! Can you tell me which .bin firmware you used ? I tried VESC_Default.bin. Maybe I had a timing issue because my PC is slow (1.6GHz Pentium M).
Anyway, now I understand that the bootloaded is not included in the .bin;
Can I download somewhere a .bin file of the bootloader alone (or maybe along with the 1.3 firmware) ?
I don't really feel like installing the STM tool chain to compile the bootloader.
Maybe I can extract a complete .bin file from the second VESC I have (still on firmware 1.2) ?

 

[lizard]

Just connected it, did read configuration and then did "start detection". Motor did not move, but there was a short (not very loud) "pop" or something noise coming from the ESC. Disconnected it immediately. Cannot see any damage, no burnt smell. It did not get hot and the LEDs were still on after it made that sound. Used a 12V 55/60W H4 lightbulb with both filaments in parallel as a current limiter and also have an 80A fuse on the battery lead. Lightbulb did not light up or blow, the fuse is also still okay.

Aaahhh, please somebody tell me it's not broken. Now I'm not sure if I should try again? Is there something I can check?

Edit: Forgot something. VESC is from Benjamin with firmware 1.2, did not upgrade firmware yet. Caps used on the ESC are 3x470uF + 1x1000uF 35V low-ESR. Battery used was 6s lipo, motor was Castle 1717 1650kv 4-pole 12-slot inrunner 50x85mm.

 

[chuttney1]

Caps used on the ESC are 3x470uF + 1x1000uF 35V low-ESR..

Had me lost here when you mentioned 35V capacitors until I figured out you were going to use it for your RC car/truck. I'm assuming either car or truck. I had problems with motor detection. I played with the Min ERPM setting and found having too high of a value like 10,000 for detection causing some weird sound to happen. Did not know where it came from. Don't try 10,000. I doubt your VESC is still connected to the computer by the time this is read which would help identify any errors. In the BLDC program, click on the tab that says terminal. Typing " help " (without commas). Gives a list of option. The main ones are the " fault " and " faults " option. These can help identify any errors.

 

[lizard]

Thanks for your help.

Just found one post by kwoolf1:

I had the faint clicking problem with no detection. 777arc helped me and here's what worked in this order:
1. Disconnect everything from the VESC - motor wires, power cables, usb, everything.
2. Hook it all back together.
3. Launch BLDC_Tool.
4. Select "Connect" in the upper right corner.
5. Open the 'App Configuration' tab
a. Select "No app" but it should already default to this.
b. Select "Read Configuration" in the lower left corner.
c. Select "Write Configuration" in the lower left corner.
d. Select "Reboot" in the lower left corner.
6. Re-connect the VESC, select "Connect" in the upper right corner.
7. Open the 'Motor Configuration' tab.
8. Select "Read Configuration" (I'm not sure if this is necessary but it shouldn't make anything explode hopefully).
9. Select "Start Detection"
10. Have a beer if it works!

And found that after clicking on read config on the app configuration tab, there was UART selected. Changed that to No App, clicked write config and reboot.
Then re-tried the detection, this time no click or pop noise, just the read led blinking 3x repeatedly.

Checking for faults in the terminal gives this:

The following faults were registered since start:

Fault : FAULT_CODE_DRV8302
Current : 1.9
Current filtered : 0.2
Voltage : 23.09
Duty : 0.01
RPM : 0.1
Tacho : 5
TIM PWM CNT : 3872
TIM Samp CNT : 3878
Comm step : 2
Temperature : 27.31

Fault : FAULT_CODE_DRV8302
Current : 0.2
Current filtered : 0.6
Voltage : 23.04
Duty : 0.01
RPM : 0.1
Tacho : 6
TIM PWM CNT : 3070
TIM Samp CNT : 3076
Comm step : 3
Temperature : 27.41

I guess my ESC is toast?

 

[vedder]

Thanks for your help.

Just found one post by kwoolf1:

I had the faint clicking problem with no detection. 777arc helped me and here's what worked in this order:
1. Disconnect everything from the VESC - motor wires, power cables, usb, everything.
2. Hook it all back together.
3. Launch BLDC_Tool.
4. Select "Connect" in the upper right corner.
5. Open the 'App Configuration' tab
a. Select "No app" but it should already default to this.
b. Select "Read Configuration" in the lower left corner.
c. Select "Write Configuration" in the lower left corner.
d. Select "Reboot" in the lower left corner.
6. Re-connect the VESC, select "Connect" in the upper right corner.
7. Open the 'Motor Configuration' tab.
8. Select "Read Configuration" (I'm not sure if this is necessary but it shouldn't make anything explode hopefully).
9. Select "Start Detection"
10. Have a beer if it works!

And found that after clicking on read config on the app configuration tab, there was UART selected. Changed that to No App, clicked write config and reboot.
Then re-tried the detection, this time no click or pop noise, just the read led blinking 3x repeatedly.

Checking for faults in the terminal gives this:

The following faults were registered since start:

Fault : FAULT_CODE_DRV8302
Current : 1.9
Current filtered : 0.2
Voltage : 23.09
Duty : 0.01
RPM : 0.1
Tacho : 5
TIM PWM CNT : 3872
TIM Samp CNT : 3878
Comm step : 2
Temperature : 27.31

Fault : FAULT_CODE_DRV8302
Current : 0.2
Current filtered : 0.6
Voltage : 23.04
Duty : 0.01
RPM : 0.1
Tacho : 6
TIM PWM CNT : 3070
TIM Samp CNT : 3076
Comm step : 3
Temperature : 27.41

I guess my ESC is toast?

Can you make a few photos of your soldering? Maybe you soldered the motor cables together with the mosfet gates. That would cause something like this.

 

[chuttney1]

I guess my ESC is toast?

Well if you got the red blinking led while trying to run the motor or motor dectection, I am afraid that is the case. Did you hand make yours or go it from Vedder or Onloop? I ask to make sure what I am saying is in the right perspective with a possible solution.

Vedder posted this a few days ago,

Check the 5V rail and the 3.3V rail. Do you have the drv fault code permanently or just when you try to run the motor? If it is permanent, you can try replacing the drv8302. The drv8302 is quite sensitive and the chip that I had to replace the most by far. Silviasol had a VESC where the drv8302 fault code was present from the beginning, and fixed it by replacing the drv8302.

I believe this is what he meant though I should ask him for clarification or anyone can clarify the 5V and 3.3V rails as indicated by the circle. First check the voltages on these rails to see if they are at the correct levels. This will ensure other components are not affected and the voltage regulators on the pcb are still good, as far as I encountered. If you get the correct voltages, then the DRV8302 is toast and needs to be replace.

 

[chuttney1]

Can you make a few photos of your soldering? Maybe you soldered the motor cables together with the mosfet gates. That would cause something like this.

Now this is something I did not know as a possible and will wait for an answer to learn more.

 

[lizard]

Tried to make photos but the flash always gave reflections and focus problems with my smartphone, will try again tomorrow in bright daylight. But I checked for continuity between the leftmost pin of the FETs and the other pins before switching it on for the first time, because on one FET it looked quite close (my soldering skills )

Edit: Checked the voltages now on the program/debug and i2c/uart/adc ports, 3.3V and 5V are okay.
Edit2: Forgot to answer another thing VESC is from Benjamin.

 

[vedder]

Tried to make photos but the flash always gave reflections and focus problems with my smartphone, will try again tomorrow in bright daylight. But I checked for continuity between the leftmost pin of the FETs and the other pins before switching it on for the first time, because on one FET it looked quite close (my soldering skills )

Edit: Checked the voltages now on the program/debug and i2c/uart/adc ports, 3.3V and 5V are okay.
Edit2: Forgot to answer another thing VESC is from Benjamin.

If you have no short on the gate, that probably isn't the problem. How long are the wires to the electrolytic capacitors?

It could also be that your motor has extremely low inductance and caused that, but I don't think so since you just heard a click. If you'd like you can send me your VESC and motor so that I can give it a try and send it back when I'm done. I haven't tested a motor like that after all. I can replace the drv8302 if it is broken (I don't have too many left though).

 

[silviasol]

Just upgraded from firmware 1.2 to 1.3. Worked perfectly!

Great! Can you tell me which .bin firmware you used ? I tried VESC_Default.bin. Maybe I had a timing issue because my PC is slow (1.6GHz Pentium M).
Anyway, now I understand that the bootloaded is not included in the .bin;
Can I download somewhere a .bin file of the bootloader alone (or maybe along with the 1.3 firmware) ?
I don't really feel like installing the STM tool chain to compile the bootloader.
Maybe I can extract a complete .bin file from the second VESC I have (still on firmware 1.2) ?

Default.bin is the one for boards with the new resistors that handle 12 series voltage, the other one is for the older 10 series resistors, for people who are still using the older version vesc's. The bootloader has to be loaded with a programmer first, so there really is no way to use the usb firmware upload unless you have already used a programmer to load the bootloader and newest firmware. IE there is no way for a brand new board to get the firmware uploaded thru the usb only, you must use a programmer. Of course after you can update the firmware quickly thru the bldc tool at any time. Do you have a machine with ubuntu? After loading all the bldc tool stuff and firmware like explained in vedders site to make the bootloader work you download the zip and then extract it in the bldc folder, then in a terminal go to that location (type cd BLDC/bldc-bootloader) then type "make upload" with the programmer connected. Same with the firmware, type cd BLDC/bldc-firmware then make upload. It is really easy actually, just kind of confusing using a terminal. Hadn't used this type of stuff since the DOS days back in the 90's installing games like doom.

 

[lizard]

If you have no short on the gate, that probably isn't the problem. How long are the wires to the electrolytic capacitors?

It could also be that your motor has extremely low inductance and caused that, but I don't think so since you just heard a click. If you'd like you can send me your VESC and motor so that I can give it a try and send it back when I'm done. I haven't tested a motor like that after all. I can replace the drv8302 if it is broken (I don't have too many left though).

Caps are are close as possible. Have now made some pics of the ESC and also some screenshots of the BLDC tool settings.

That would be very nice if you could have a look at it. I can also put another motor (Turnigy 56x82mm 4-pole 900kv inrunner) in the package that you can keep for testing purposes or whatever if you want. If you want to run the 1717 in your buggy, I'll include a set of belted onroad tires so that you don't shred your tires with it

Here are the pictures as promised. The black stuff is plasti-dip (can be peeled of as you can seen on the DRV).

 

[vedder]

It is difficult to tell from one of the photos, but it looks like the short pin on one of the FETs (the one between all source pins) is shorted shorted with one of the source pins. The short pin is drain, and if you short it with source the FET will become shorted. If that is the case, it is what caused the failure that you saw. I should make that clear in the description, it is not obvious that the short pin is drain.

If you send me the ESC, can you remove the plasti-dip first? Otherwise there will most likely be lots of smoke when I use the hot air station to desolder the drv. That turnigy motor sounds nice

Do you have my address? It should be on the parcel I sent you as the sender address.

Regarding the bootloader and firmware:

All VESCs that I send have the bootloader installed. Uploading the firmware is done like the following:

1. The new firmware is stored in empty flash after the funning firmware together with a checksum. This is done from the current firmware and what is seen when the graph in BLDC toll goes to 100 %.

2. The running firmware jumps to the bootloader at the end of flash. If there is no bootloader the mcu will just freeze and rebooting it will start the old firmware again.

3. The bootloader computes a checksum on the new firmware and compares it with the stored one.

4. If the checksums match, the booloader will erase the old firmware and replace it with the new one. Up to four attempts are made in case flash returns some error code.

5. A reboot is made and the new firmware is started.

The critical step is 4. Erasing the old firmware and replacing it with the new one takes a couple of seconds and it is critical that the power is stable and not lost during that period. Otherwise, the firmware will become messed up and a stlinkv2 is required to fix that. So one way to mess things up is to wait until the firmware upload says 100% and unplug power within a couple of seconds after that. If the firmware upload bar stops somewhere is no problem because the old firmware is still there and won't be replaces since the checksum won't match - the critical part is right after the upload is done.

 

[Dr_T]

Hi all, I'm new here; heard of the awesome VESC through Lizard's posts on RC car forums. I got one of Benjamin's VESCs and plan to use it in ~5kg RC cars, for starters with ~1000-1500 kv 4-pole inrunners, on 6S or 7S (stuff I already have). Haven't soldered it up yet; been browsing here for some info on getting started and maybe to get some inspiration on how to mount some heat-sinks for additional cooling. If anyone has ideas on that, or has added heat-sinks already, I'd be very interested in some info and pics.

Lizard: cool to see the VESC mounted in Godzilla Salsh already (and new black spoke GRP slicks! ), sorry to hear it's not running yet... Question: looks like you added extra solder on the source pins of the bottom (shunt) side FETs, correct? If so, why / is that recommended?

 

[lizard]

Vedder: No, the short center pin has no contact to the other ones. I have put everything in a package now. Don't have your address anymore, maybe let's do the rest via PM.

Dr.T: Cool to see you here. Put the solder on there because I have seen it on other VESCs here and I have the feeling it helps against the pins un-soldering themselves

 

[Shep_pard]

@vedder
So I finally got around to fixing the VESC and soldered a new DRV onto it.
Now the ESC turns on and seemed to work just fine. The USB connected, but when trying to spin up a motor, nothing happend. The motor makes no noise and the ESC pulled no more mA than just being at rest.
The gui, which is attached, just shows it jumping around. I also tried to make a photo of the newly soldered DRV https://drive.google.com/file/d/0B8jRYhzfJlRpYzIxbXlmNnRzbTQ/view?usp=sharing (for high resolution I uploaded it somewhere else).
As far as I can see the Fets seem to work. What I could tell with my oscilloscope is, that there was no signal arriving at the Gates of the FETs. The STM still sends out a signal as expected, but I can't see anything coming out of the DRV.
I am quite sure the GND pad on the bottom is soldered but is there a way to check that?
Is it a broken DRV or something else that could cause the problem?

Update: Because I was suspecting a few leads might not be connected I added extra solder to all of them. Makes no difference.
Update 2: I noticed something quite interesting. I had removed the protection diode D5 because it was burned until I could get a new one.
What I found out was, that the 5V at that point are not actually 5V. On the oscilloscope it jumps between -2/3/8V.(I can measure the same wave on the inductance of the Buck) But all the other 5V connections looks perfectly.

Which is kind of weird in my opinion. From the schematic there is no more extra filtering going on in the 5V line. So either all 5V ouptputs should look like that, or all should look good. So my best guess ist, another broken DRV with an almost working buck?

 

[pf26]

@vedder: from your bootloader scheme description, my VESC should be stuck at point 1 (98% shown) and then normal operation should resume upon next startup - which is not the case (blue LED on, USB port not recognized, board power consumption around 20mA @12V once capacitor charged)
I suspect the 98% displayed did not refresh properly when the system in fact already reached point 4, and crashed there for some reason.
Is it enough to find an STlinkV2 programmer, and just program the Default.bin ? Thks, Pierre

 

[vedder]

@vedder: from your bootloader scheme description, my VESC should be stuck at point 1 (98% shown) and then normal operation should resume upon next startup - which is not the case (blue LED on, USB port not recognized, board power consumption around 20mA @12V once capacitor charged)
I suspect the 98% displayed did not refresh properly when the system in fact already reached point 4, and crashed there for some reason.
Is it enough to find an STlinkV2 programmer, and just program the Default.bin ? Thks, Pierre

The progress bar will not update the percentage for the last chunk of the firmware upload, so for me it stops at 99%. That it stopped at 98% for you probably means that you uploaded a smaller file because each chunk is a larger proportion of that file if it stops at 98% instead of 99.

What I think happened is that either the firmware file you uploaded was incomplete or that your build of bldc tool only loaded a portion of the firmware file for some reason. The checksum for the firmware is computed in BLDC Tool, so if the resulting bytearray from the loaded file is too small (or comes from a different file) the check in the bootloader will pass anyway since a correct checksum is generated for the wrong file after BLDC Tool loads it.

One way to solve this would be to compute the checksum outside of BLDC Tool and embed it into the firmware file. I will see if there is some convenient way I can do that.

 

[pf26]

@vedder: You are correct. The VESC_Default.bin file I tried to download was only 27kbyte as compared to 166kb for the correct one. I can't see what I did wrong to extract this file incorrectly, but I did. It may be good to have bldc-tools make some checks on the .bin file (you could require the file to contain some fixed values at some addresses for instance) to make sure it does not download a wrong file.
But I think you better leave it this way and try to find a means to write protect your bootloader section (maybe STM32 has some configuration options to allow for this, or possibly you also can change the bootloader to prevent overwritting some address ranges (the ones of the bootloader code). Obviously this would make it impossible to update the bootloader itself, but I think is better though. A watdchdog then returns to the bootloader when the downloaded code is bad.

 

[silviasol]

Update 2: I noticed something quite interesting. I had removed the protection diode D5 because it was burned until I could get a new one.

Are you certain that the positive and negative connections were not crossed when you plugged it in? I had one board I did that by accident and when I plugged in the programmer it was flashing lights strangely so I knew something was wrong. I found even though the wiring looked fine the power leads were crossed. I think the wiring was just barely touching the d4 contact next to the positive connection. I fixed the wiring then next time I plugged it in the d5 and u2 chips would get hot and start smoking. I always double check the positive connection with a multimeter now, the last board I did also had a crossed connection which I luckily caught before plugging it in.

 

[martinhoang]

Thanks for your help.

Just found one post by kwoolf1:

I had the faint clicking problem with no detection. 777arc helped me and here's what worked in this order:
1. Disconnect everything from the VESC - motor wires, power cables, usb, everything.
2. Hook it all back together.
3. Launch BLDC_Tool.
4. Select "Connect" in the upper right corner.
5. Open the 'App Configuration' tab
a. Select "No app" but it should already default to this.
b. Select "Read Configuration" in the lower left corner.
c. Select "Write Configuration" in the lower left corner.
d. Select "Reboot" in the lower left corner.
6. Re-connect the VESC, select "Connect" in the upper right corner.
7. Open the 'Motor Configuration' tab.
8. Select "Read Configuration" (I'm not sure if this is necessary but it shouldn't make anything explode hopefully).
9. Select "Start Detection"
10. Have a beer if it works!

And found that after clicking on read config on the app configuration tab, there was UART selected. Changed that to No App, clicked write config and reboot.
Then re-tried the detection, this time no click or pop noise, just the read led blinking 3x repeatedly.

Checking for faults in the terminal gives this:

The following faults were registered since start:

Fault : FAULT_CODE_DRV8302
Current : 1.9
Current filtered : 0.2
Voltage : 23.09
Duty : 0.01
RPM : 0.1
Tacho : 5
TIM PWM CNT : 3872
TIM Samp CNT : 3878
Comm step : 2
Temperature : 27.31

Fault : FAULT_CODE_DRV8302
Current : 0.2
Current filtered : 0.6
Voltage : 23.04
Duty : 0.01
RPM : 0.1
Tacho : 6
TIM PWM CNT : 3070
TIM Samp CNT : 3076
Comm step : 3
Temperature : 27.41

I guess my ESC is toast?

Can you make a few photos of your soldering? Maybe you soldered the motor cables together with the mosfet gates. That would cause something like this.

Hi Vedder,
I'm also having the same fault with my board (PCB from hackvana and components as in BOM). Also, I noticed when first run the motor detection, my motor ( a Prop Drive 270kV) accelerated really fast for very short time (0.5sec) and stop immediately with the fault code start appearing in real-time monitor tab and terminal. In the past, I did some projects with some texas instrument motor control boards (using DRV8301 and C2000 picolo microcontroller) and I sometimes ran across these fault signals with the same behavior from the motors. However, the GUI provided by TI had "Fault reset" feature, which as I read in DRV8302 and DRV8301 datasheets is easily done via EN_GATE pin, and I can just restart the detection with lower parameters (voltage/current limits) without any further faults. For my boards, I replace the DRV8302 twice and still had the same fault code after first detection run, so I think and hope you could implement the feature in the GUI in the future so we could give the board another try before replacing the chip or re-building a new board. I'll try hard reset the faults by connecting EN_GATE to 3.3V (I may fail since I know so little about MCU haha). As far as I know, the DRV8301 (not DRV8302) is quite tolerable with sudden motor spins during motor detection and one reset would fix the latched faults. Hope this will help end the torment of infamous DRV8302 fault.
Martin