Which via, could you mark it?
Revision C01. Thats the last one. I mean newest revision. Check on the schematics if they fixed it, its posted on stm website.
via isn’t visible cause it’s multi-layer PCB
just click the link here
Checked the gerber. MB1419B is affected, MB1419C not.
i think it is a good idea, dual motors on RC without centrel driveshaft
1 Like
Thanks for your input everyone! The STEVAL board is on the way, sadly it’ll have to wait until i’m out of isolation and feeling better…
I got a cheap Basecam BGC3.0 clone from the local classifieds in the meantime, but i can’t find anything regarding pinouts or usage not regarding gimbal applications with the GUI. Does anyone know if that board is usable at all? Its this one, just called BGC 3.0 control panel: https://m.media-amazon.com/images/I/61hSo7EeBCL._AC_SY355_.jpg
It came with 2x 2208 80kv gimbal motors as well.
Hey, it is useable, but more in open loop than closed loop mode…
The AtMega328 is at the very bottom of the performance scale of MCUs that can run SimpleFOC, so asking it to do 2 motors with I2C sensors (slow!) in closed loop control is a bit much. The problem here is also that I2C is a slow protocol, and reading 2 I2C sensors per loop iteration slows things down a lot.
Open loop on 2 motors should be no problem.
I can’t really remember, I think maybe to program it I had to first download an Arduino Bootloader onto it, and then I could program it as an “Arduino Nano Pro”.
I mapped the pins of the version I have, but be warned that yours could be a bit different:
Mapping pins is fairly easy using a multimeter in “beep mode”.
Start with a very simple sketch, and once you have it working, can download to the board, see Serial output for debugging, etc, then you should be ready to try to move those motors…
But on the whole you may want to wait for the STEVAL… Running SimpleFOC on the STM32 MCU will be much better!
2 Likes
Thanks @runger! I actually got it working fine once i mapped the pins and burned the bootloader. But yes, its mostly usable for open loop.
The STEVAL-GMBL02 just arrived, and i’m eager to get started. I’m just really unsure about how to actually flash code to it. Could you maybe guide me to how i can use the Arduino IDE with it? I’m not sure which bootloader to flash, if any… I figured out that i can burn the bootloader with OpenOCD via Raspberry Pi and SWD, but i would like to use the Arduino IDE.
The Steval GMBL seems like a much harder to learn board than the BGC3, i’m in way over my head. But i hope i’ll get it running once i figure out how to program it.
Hi there! STM32 is well supported in Arduino, so it should not be too hard to get up and running.
First order of business is the way to program it - the simplest is ST-LINK. A ST-LinkV3Mini is all you need and the cable it comes with connects directly to the board. The board should also have come with an adapter to connect it to the ST-Link section of a Nucleo board, but that seemed a bit complicated to me.
You may be able to program it over USB and/or serial as well, but these things can be trickier than st-link from the software side.
On the Software side, install the STM32CubeProgrammer, a free tool from ST-Micro. Using this tool you can communicate with the MCU and flash firmware files, etc… its handy to debug problems.
In Arduino IDE you have to use the board manager to install the STM32 framework. Add the following URL to your board manager URLs in the Arduino settings:
https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.json
Then you can wait for it to finish installing them, restart the IDE, and then you should have lots of additional boards from ST-Micro to choose. The one you want is a “Generic STM32 F3 series”.
After that you can choose different options like the type of connection, etc… which Arduino IDE are you using? The old one or the new 2.0.0 series one? I can send some screenshots…
1 Like
Hi @runger, thank you so much again for taking time to help me!
I’ve got that far, but it seems to me like i have to burn a new bootloader to be able to flash the chip via the onboard usb. My issue is in locating the relevant binary. There are several binaries for STM32s, categorised by LED placement on the board. This not being a standard dev board, i can’t decode which binary would be the correct one.
Also, I’m not sure about the boot pins, where they are and if i have to pull them low/high.
I’m keen on using the USB port, as I don’t have an FTDI etc, so i was planning on burning the bootloader once using my Raspberry GPIO with OpenOCD via SWD. This should work, if i find the fitting binary.
Finally, I’m not quite sure which upload settings would be correct when using the onboard USB port.
So in a nutshell, my problems are:
Do i need a new bootloader to Flash via USB?
If so, what binary?
If i can’t figure it out, I’ll have to resort to flashing via Raspberry GPIO as well, which isn’t the end of the world. I’m honestly just overwhelmed because there is so much jargon and so, so many STM32 versions around. Just writing it out makes me wonder if it wouldn’t just be smarter to only figure out how to flash my compiled binary, and be done with it
That sounds pretty cool, I’ve never done this!
When the USB port is available for flashing, you don’t need any special upload settings. It shows up as a USB storage device in this mode (DFU mode) and is normally recognised without problems. To get it into this mode (rather than Serial port mode), you normally press and hold the “boot” button, press reset, and let boot go again after reset. But this board doesn’t have a boot button, and it looks like the BOOT0 signal isn’t routed out to any header pin… so either you would have to apply 3.3V directly to the BOOT0 pin of the MCU using a fine probe (but with firm contact), or you have to go the ST-Link (SWD) way, I’m afraid…
In terms of firmware, the user LED is on pin PA7 of this board.
It’s true that there are many STM32s, and finding the right settings/firmware files can be a bit confusing! But it sounds like you’re pretty close!
The thing to know is also that the STM32s have this firmware “built-in” as well, so flashing firmware isn’t something you need to do on a regular basis. Normally you can just proceed to flashing your software.
But not having a boot button means you can’t trigger the programming modes in the normal way.
1 Like
Huh, I just checked and they don’t have a pre-built boot loader with PA7 as the LED…
But it doesn’t really matter, you could use the PB9 boot loader and attach your own LED. Or you could get really adventurous and try to compile it yourself, not sure that is worth it though.
What’s worse, ST-Link V3 Minis seem to be sold out. That semiconductor shortage is a real pain!
1 Like
Okay, the board actually registered in the Arduino IDE fine, and with selecting DFU and putting it into this mode by pulling the BOOT0 pin high, i actually managed to flash something to it. Sadly, this seems to have overwritten the bootloader or whatever, as the board doesn’t show up on my PC anymore, and i also can’t enter the DFU mode through pulling BOOT0 high. Too bad, at least it’s blinking. Time to get out the Raspberry and figure out how to flash from there. Am i doing something wrong? I would’ve guessed that flashing the sketch wouldn’t have overwritten the bootloader, but here i am…
Huh, my understanding is that STM32s have a built-in boot loader that you can always fall back to… but I have been where you are several times before, I know the feeling. It is somehow really confusing, even though it is supposed to be simple…
Ok, I looked it up again. According to the docs. a STM32F3 series MCU definitely has a system boot loader, and this boot loader supports USB:
https://www.st.com/resource/en/application_note/cd00167594-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf
(see section 21 for STM32F303RE)
So if BOOT0 is high, and BOOT1 is low on system reset, it should enter this boot loader.
There are some exceptions… like “When readout protection Level2 is activated, STM32 does not boot on system memory”, but we can assume this is not the case for your board. You could check it but you’d need an STLink to connect to SWD.
And I would guess serial uploading to UART1, whichever pins that is, would work after hitting BOOT0, just USB is not working…
Can I ask, if you don’t do BOOT0, does your board still show up as a Serial port? Did the firmware you flashed configure the USB-Serial?
The boot loader should really detect the 8MHz crystal and enable DFU over USB, as far as I can tell.
1 Like
Another thought I had: my Mac gets upset with the USB subsystem at some point, after I connect/disconnect my devices a bunch of times I think it decides the bus is broken, and refuses to accept the device until I restart my Mac…
I don’t even know if you use Mac, but I’m just mentioning this because sometimes when I’m debugging USB problems I find the problem to be on the host side too… something to keep in mind.
1 Like
Thanks for the insights! I ordered a STLink should be here soon, hopefully tomorrow. SWD via Raspberry Pi didn’t really work out, but I’m sure i messed up.
I just flashed a simple blink script to check if flashing even works. The script is working, but since then the STM doesn’t show up at all, doesn’t matter which mode. I’m on Linux, but of course i tried rebooting already. I’ll try the UART connection tomorrow, i think my Arduino is still setup for UART ISP. Hopefully it’ll just work once the STLink is here, my way with Raspis and Arduinos is really unnecessarily complicated.
I’ll keep you updated!
If its not showing up in normal mode, and your options included the USB serial support, then the problem may be with the clock. When using a “Generic” board definition, the clock setup might not be correct for your board…
It would be cool if there were a sample project from which to copy the SystemClock_Config function. I have to hunt around the ST website and see if I can find one. If not, we can probably reconstruct the correct clock configuration…
1 Like
There’s also the very real possibility that I’m just stupid a messing something up 
I’m hoping that the STLink should clear the confusion
So, my STLink v2 arrived, most likely a clone. I’ve wired everything up, but no success.
st-info --probe on Linux says that the stlink is connected fine, but that SWD mode isn’t possible.
Trying via STM32CubeProgrammer GUI, same thing. ST-Link is connected fine, but upon trying to connect it just says no STM32 target found. Checked the wiring multiple times.
Just to be clear, the board needs to be powered independently, right? And if so, i’m just connecting SWDIO, SWCLK and GND to the ST-Link?
I’ve read somewhere that the SWD pins may be overwritten accidentally, so that SWD isn’t possible anymore without reflashing via UART. I honestly have no idea how i’d use UART, since i’ve got not FTDI and the v2 doesn’t do UART.
I’m honestly stumped, no idea how to proceed.
Out of curiosity, was it an original STLink, or one of those Chinese USB knock-offs? I never had any luck with clones.
1 Like
Hi,
Clones can be dodgy sometimes, but all the ones I’ve got here have worked fine (3 different ones). Did you update its firmware? I could update my clone’s firmware using STM32CubeProgrammer with no problems.
One thing can be USB hubs. They work fine via my powered hub, but friends of mine have had no luck via their hubs, and sudden success once they plugged directly to their PC.
My understanding is that the STLink needs GND, SWDCLK and SWDIO to operate, and the VCC connection is there for the target to tell the ST-Link its voltage (target_voltage). But my clones label the VCC pin just VCC, and provide power over it. I can flash successfully powering via the ST-Link or with VCC disconnected and power supplied externally to the MCU. This is different to my official ST-Link V3 - where the pin is labeled “Target Voltage” and no power is provided via it.
If you haven’t done so, check with STM32CubeProgrammer the Options-Bits page. Sometimes the MCUs are “locked” with Read or Write protection, and you have to unlock them first for things to work.
I’ve never come across a case where SWD would not work, and I had to use Serial. I often have problems with DFU (USB) but then I go straight to SWD and it has always worked.
I use a lot of different STM32 MCUs, so details blur a bit. I will dig out my GMBL board again tonight and try it out for you using my clone STLink.
1 Like