I’m on vacation and cannot test. However, it appears the serial command code is not included. That’s all I could help without running it myself.
Unless I am missing something obvious would you just need to compile the necessary Commander files into your project?
│ ├── communication
│ │ ├── SimpleFOCDebug.cpp
│ │ ├── SimpleFOCDebug.h
│ │ ├── Commander.cpp <—
│ │ ├── Commander.h <—
│ │ └── commands.h <—
The Commander is not necessary for the library to function, so you may want to find a different (and more memory conservative) way to interact with SimpleFOC since you have such limited flash.
I added the 3 Commander files in the communication folder as suggested by @BrrrIce
I added the following serial command code (thanks to @Valentine )
// commander interface
Commander commander = Commander(Serial1);
and in the loop()
commander.run();
I still get this compilation error:
stm32_bldc_magnetic_spi:68:1: error: 'Commander' does not name a type
68 | Commander commander = Commander(Serial1);
| ^~~~~~~~~
/Users/xxxx/Documents/Arduino/stm32_bldc_magnetic_spi/stm32_bldc_magnetic_spi.ino: In function 'void loop()':
stm32_bldc_magnetic_spi:147:3: error: 'commander' was not declared in this scope
147 | commander.run();
| ^~~~~~~~~
exit status 1
'Commander' does not name a type
The examples from Arduino-FOC/minimal_project_examples at minimal · simplefoc/Arduino-FOC · GitHub, does not include the Serial command code, but maybe these examples are outdated.
Maybe I should use a different way to interact with SimpleFOC, but I want to get rid of this error. Does anyone have other suggestions to solve this problem?
Earliest I could really help is August. I am very interested in making a small minimalistic cut of SimpleFoc for the Mosquito and your effort is very helpful but I do not have access to anything while on vacation. I’m sure we could solve it if we spend some time. At the end, it’s just code. The hardware is working fine.
It shouldn’t be necessary to make a minimal version. The code already looks well designed so only the parts you actually use will be included in the binary. For example all the commander code should automatically be stripped out by the linker as long as the Arduino program never creates a Commander object.
See if you can get the linker to output a .map file so you can see the size of all the functions and static variables in the binary and see if anything unnecessary got included. If using the Arduino IDE, it sounds like you may be able to find the .elf file on your hard drive and extract a .map from that. For AVR, someone on the Arduino forum said you can do avr-objdump -t project.elf, but I’m not sure what the equivalent would be for STM32.
Ok, I found the compilation problems.
I used the “minimalistic” functions from SimpleFoc (see https://github.com/simplefoc/Arduino-FOC/tree/minimal#arduino-simplefoclibrary-v201---minimal-project-builder) as a base to build minimalistic firmware version, however this branch is still on v2.0.1
I followed the procedure as described and used the files from the main branch v2.2.2 (as described in post 59). I found out that in the minimalistic approach a different “Commander” principle was used. That causes the compilation error. The Commander function was replaced by a simpeler (?) function added to the the FOCmotor.cpp file. So I copied this function to my v2.2.2 FOCmotor.cpp file. Next to that I had to change variables to match the v2.2.2 library (mainly ControlType to MotionControlType).
But that was only the beginning. The way the monitoring was organised in the minimalistic setup, differs from the SimpleFOC monitoring setup, so I had to go through al files to check that and change it (mainly change SIMPLEFOC_DEBUG() to if(monitor_port ) monitor_port->println() and removed the communication libraries #Includes.
The good new is that my minimalistic setup v2.2.2 compiles without any error, however……the Flash memory problem is still there.
With this action I managed to bring the overflow back from 5988 to 2388 bytes (60% reduction), but it is still not enough.
So, question is: do I have to accept that the memory problem is unsolvable or are there other solutions possible. Any ideas?
My aim is to have a Mosquito firmware which I can fully control and monitor via a serial connection.
Here is a video with my version of the board in action,
and a preview of the next version that has greater current capabilities.
STM32G031G8, UP9636 power stage,
and a SC60228 mag sensor (which is not tested yet).
The 1st version is running flawlessly since weeks.
5 Likes
Very impressive and educational, thank you. We need more of those.
Cheers,
Valentine
Hi all!
Where can I find SC60228DC chips to solder on the back of the Mosquito board?
I only found them on aliexpress in batches of 10!
Or, are there alternative, pin compatible chips that would work?
I’m not aware of pin compatible. They have been out of stock on lcsc, too.
If anyone else has any ideas, it would be great.
Whats the problem with aliexpress?
I’d like to have an option to buy exact quantities and not batches of 10 
But, given the shortage, I guess 10 will be fine!
Three and a bit months later I finally had some free time to get back to this project.
My solder job was pretty atrocious, but some paranoid continuity checks didn’t turn up anything too funny.
Flashing (st-link v2) took 3-4 tries before it worked, which is weird and I thought was a very bad sign but once it flashed, it seemed to work fine.
J-Link>LoadFile C:\...\MosquittoTest.ino.GENERIC_G041K8TX.bin 0x08000000
Downloading file [C:\...\MosquittoTest.ino.GENERIC_G041K8TX.bin]...
J-Link: Flash download: Bank 0 @ 0x08000000: 1 range affected (32768 bytes)
J-Link: Flash download: Total: 25.986s (Prepare: 0.002s, Erase: 15.582s, Program & Verify: 10.392s, Restore: 0.008s)
J-Link: Flash download: Program & Verify speed: 3 KB/s
Error while programming flash: Programming failed.
J-Link>LoadFile C:\...\MosquittoTest.ino.GENERIC_G041K8TX.bin 0x08000000
Downloading file [C:\...\MosquittoTest.ino.GENERIC_G041K8TX.bin]...
J-Link: Flash download: Bank 0 @ 0x08000000: 1 range affected (53248 bytes)
J-Link: Flash download: Total: 1.276s (Prepare: 0.088s, Erase: 0.581s, Program & Verify: 0.579s, Restore: 0.026s)
J-Link: Flash download: Program & Verify speed: 89 KB/s
O.K.
J-Link>
I’ll have to check if I can get FoC working with the encoder on the back tomorrow, but I don’t have a test jig set up at the moment. Open loop seems to work fine. (12V, 0.5A with this small motor I had lying around).
The only major issue I ran into is that the 10uF capacitors I had on hand were only 16V not 25V, so I’ll have to keep voltage under 15V or so until I swap in the right ones.
1 Like
@Valentine
Some general feedback on the board:
- Does it really need a step-down converter? It seems like a little 3 pin LDO would be fine given the current draw requirements, which would save money and space (no giant inductor). I see you started with an LDO and went to the step down, but I’m not sure why.
- The mounting is… hard to use in practice. I thought I’d just screw things in on the corners, but there are components too close to each of those. I can use a nylon washer to stop shorts, but it still means I’m clamping down on SMD components. The bottom left corner is the only one that might have room for an M2 screw head, but none of them can fit an M3 AFIK. I think I’m just going to end up 3d printing something that has a snug fit from the back and gluing it in there, but that’s maybe not ideal since it warms up.
And question:
- Did you ever get the spi mode for the encoder working? I tried the driver in the other thread but it wasn’t cooperating (no reading, didn’t dig further yet). I’m waiting on new magnets since my magnetic encoder boards I had on hand came with axial magnets
(rather than radial ones). The new ones arrive today. For now the 1kHz mode seems to work, but that has the limitations that you complained of in the SC60228DC thread.
Yes. The LDO was a bad solution I made only for basic POC testing. LDOs work when you got a few volts difference. That driver is rated to 60V, so dropping 57 volts or so with an LDO would be 
really bad 
and also there are no LDOs that can drop 60V to begin with. That tiny buck converter I made is actually extremely good at what it does and takes almost as much space as a good LDO.
Haha, yeah, I know, you are right, it sucks. I tried to push the envelope as much as possible. Originally the board was supposed to be a surface mounted module, hence the castellated pins. You have to use silicone to glue your board. I can make a second version with a lot better mounting footprint.
Also you will need a heatsink, you are correct.
I saw someone made the SPI work but complained about memory size, that it, the board is so tiny they tried to put the full stack and it didn’t fit, so they did some black magic to shrink the kid. I’m quite sure the SPI works because I’ve ran code that reads/writes.
What’s a 1kHz mode, could you elaborate?
Cheers,
Valentine
The “1khz mode” is me tiredly describing the 1lhz pwm output.
I’ve got a better test jig printed but I think I’m going to have to use the serial port properly. I’ve been trying to use segger RTT and the connection seems a bit wonky. I’d imagine that the swd cooper routing isn’t really designed for when motor is running.
The proper step down makes sense. I am only using the bord at <25V so LDOs are maybe still in range. 60V into an LDO just needs some brave 0804 voltage dividers if the current is low 
I went a little crazy and did a layout rework in 16x16, but it’s probably a bad idea. I’ve got 2 signals left to route, but I should play around with your original board design some more before committing to that. Also, afterwards I found your own 16x16 design (mini hotdog) which seemed interesting.
Next steps for me are to prototype some actual motor assemblies with the boards as they are to get a better idea of what I really need.
You really need to try, I’m not sure. You can find really high quality LDOs with very small drop, however, they are also really expensive, and big, to a point that a buck converter makes more sense.
Sorry that makes even less sense, may be you mean 1kHz PWM?
Never used that one, sorry.
Wow, 16 x 16 is a little extreme. You probably need to do some double sided SMD however I try avoid it due to most people cannot handle double sided PCBs especially at that level of integration. If you succeed please post a picture!
If you have suggestions I’m ready to listen and modify the board, or fork a new variant.
Thank you for working with the board and sharing your experience!
Cheers,
Valentine
For anyone else building this, I’m still in the process of playing around with it, but I got everything working nicely in PlatformIO:
I’m uploading using a knockoff ST-Link V2 (the blue USB stick one), using the 3.3V, gnd, SWD, and SCK pins. Uploading works, and if you connect the jlink app (in swd mode), RTT terminal works over the local telnet port. I haven’t tried debugging but it probably works™.
I’m sharing because creating and overriding the platformio board definitions to get the specific microcontroller to work was a little bit of a headache. The platformio board definition for this MCU was missing
2 Likes
I’ve updated my repo after getting the SPI encoder to work.
I’m running into trouble where the velocity estimation seems… extremely noisy. Granted, I’ve got a pretty bad design for my encoder mounting, but is this level of noise abnormal? I’ll try printing a smarter motor, magnet, and driver mount and get back to the thread.
The graph shows target 2 rad/sec velocity closed loop with the aggressive motor.LPF_velocity.Tf = 0.05 required to allow the motor to function at all properly in closed loop mode. As shown, the velocity is jittering all over the place.
Open loop mode works fine, and spinning the encoder around with my finger looks fine. I’m thinking either my mount is vibrating too much, or I’m getting too much magnetic interference from the rotor (which the magnet is mounted to… which was silly of me).
Edit:
I set the LPF to 100ms, and graphed a few different target speeds and the result seems to indicate some sort of periodicity as well (maybe axial misalignment between the motor and encoder, or just more effects of the rotor magnets messing with me).
Edit 2: Cleaned up some garbage data, moved VoltQ to the right axis, added moving average lines.
There is a patch to calibrate the sensor position: SimpleFoc Sensor Eccentricity Calibration. Maybe try looking into that. I personally couldn’t get it to work but others have reported success.
I would say it looks like a misaligned or faulty magnet. It’s pretty common to get faulty magnets when ordering sensors from aliexpress.
That sensor calibration is super helpful. I tried it out, and… it spat out a table of NaNs, but it did at least do a full CW and CCW slow rotation to generate the NaNs I’ll dig deeper after I try a better jig.
Better jig comparison:
Before (magnet mounted to the rotor directly):
After (magnet mounted to the shaft protruding from the stator):
The magnet is from Digikey, not aliexpress (and not an aliexpress digikey reseller either), so it’s probably OK (it looks like the deadpool logo on a magnetic viewer).
The two graphs show the same time period, with the same settings, just a different mount (and I swapped CW for CCW since that changed).
I think the dramatic reduction in noise is a result of the motor itself not interfering so much with the sensor, but the increase in that clean periodic error appears to be caused by the shaft (2mm, fairly long) wobbling more than I’d like. It could also be that the Mosquito and/or angle sensor are off-center.
The eccentricity calibration is still not working, but I’ll follow up in it’s thread. (Lots of NaN,s and Overflowing floats).
1 Like