So, if you still have the boot0 [PA14] pin broken out, you can tell the stm32g031 to go into bootloader mode AKA look at PA2/PA3 or PA9/PA10 for uart input. Then, you can connect STM32Programmer over USART and it is basically equivalent to using the SWD pins.
The reason I am reiterating this is because you have the option to use PA2/PA3 or PA9/PA10, as they are available via alternate pin mapping (see picture). Additionally, the original board had I2C2 pins (PA9/PA10) labeled on the schematic, but not broken out to a connector. It seems this board is just itching to have full USART support!
(Also this is sort of a vicarious effort on my part, since I don’t know much about PCB design lol)
PA14 is the presently-unavailable SWCLK, so I’ll have to get it accessible. Maybe if I get CSS on the encoder header, its former pin can be repurposed for this, and I can have my easy FTDI interface. But then I’m only one pin short of proper SWD access…
Do you know if it will have to be manually reset after every upload of a new program, or if it will auto-execute like Atmel-based Arduinos? I stuck that reset solder pad on there just incase, but it would be nice to know for sure whether it’s needed.
So that’s what the PA9/PA10 in brackets meant Those are already accessible as MOSI and MISO, so maybe either that or PA2/PA3 will work regardless of the initial state of the boot selector bit.
So unless you want to have problems you should definitely provide a way to access the SWD pins. They will not only allow debugging, SWD will allow programming in any situation, while UART or other options depend on you getting into the boot loader…
You should also expose nRST for a seamless experience.
To use SWD you need a STLink programmer, the STLink Mini v3 is cheap and ideally suited, but if it’s not available, an STLink v2 (there are also clones) is enough…
To use it you need the following connections:
gnd
swclk
swdio
nRST
vdd (output to STLink, not input)
Ok, here is the next candidate, 25x25mm. The only casualty this time was my HV-to-VCC jumper, so now you must have a separate supply wire for the mid voltage rail even if the main voltage is low enough to use.
The idea behind this one is to have compact solder connections to the power and communication pins in final use, and a 1.25mm pitch connector for all the pins that will be used during programming. The encoder will use a 1.25mm connector even in final use. I could potentially fit 6 holes over there if I stagger them or use 2x3, but connectors are kind of nice anyway. The ones I chose are LCSC parts C519006 and C519009. They look compatible with JST female, but let me know if there is a better choice. JST-SH seemed to be all SMD, which has a larger footprint.
I also managed to fit the second 10uF, despite the loss of some board area to the connectors. It was a hard fought battle routing around everything, but I managed.
I currently have I2C2 on the programming connector and I2C1 as the two communication pins. I may change it so UART2 goes to both of those, since SimpleFOC commander uses UART. But because I’m planning to have 4 boards stacked on top of eachother, if I can get each one to respond as a different I2C slave address then I can communicate to the whole stack from a single pair of wires running axially through the holes. That’s how I plan to do the power wires too.
One of the connectors seems to be floating in the 3D model. Presumably it will not float in real life
Not sure if it is JST SH compatible, it looks a bit different… you’ll have to try. The reason I like JST is that there are plenty of cheap, pre-made cables you can order on AliExpress…
But I understand the footprint is larger in SMD…
We also have an I2CCommander in our drivers repository…running 4 on the same I2C bus should be quite possible.
If you don’t provide a way to set the I2C address in hardware (jumpers, switches) then you will have to do it in software, which means flashing a different firmware image to each board, or connecting to them individually via a different protocol first to configure them.
Right, these are not SH compatible. Upon paying better attention, SH is 1mm pitch. But these do look compatible with cheaply available 1.25mm pitch pre-made cables, which is what I had in mind. I’ll be ordering the connectors separately from the PCBs to avoid the manual soldering fee, so I’ll get a couple different brands to try since they’re so cheap.
Great to hear the work is already done on I2C communication
I made a few more minor modifications, and placed the order for the boards. The most significant thing is that I moved the 2mm pitch communication pins over with the power pins on the right, and changed it so both those and the programming connector use I2C1 so you can issue commands via the programming connector as well without having to change the code. You can still use an I2C LCD or other devices on the same bus, so there wasn’t much advantage in having I2C2 available, plus this simplifies the routing.
Unfortunately at some point I forgot to pay attention to which SPI pins are also ADC, and ended up with only one ADC pin on the encoder connector so I won’t be able to use linear hall sensors on it. I’ve since corrected it, and I will be able to connect linear halls via the programming connector so no big deal. It’s a great relief to have the MOSFETs confirmed before they’re out of stock. Now even if I did make any serious mistakes, the worst case is I have to transplant them to new boards.
Thank you to everyone for your input! And sorry for taking over your thread, Valentine I’ll start a new thread when my boards arrive in a few weeks. For now it’s back to machining aluminum while I wait.
I’m sorry but I don’t have a Lepton board myself… I’m afraid I can’t help you there, but I know @Valentine made a guide for one of his boards… did you check it out?
After you do that, try hardware Serial2 again, but read the other points below first.
Lower your baud rate to 9600 to make sure you exclude/filter any noise in the lines.
Make sure your FTDI converter is set to work with 3.3V, not 5V logic.
Make sure your Lepton RX goes into the FTDI TX, and the TX into the RX (they must be crossed).
If the hardware serial still fails, here is sample code for you to try software serial, this works on any two pins. I edited the code to match the Lepton Serial pins. This will override the hardware serial and should be able to get the Serial working.
#include "SoftwareSerial.h"
#define SS_USB_RX PA15
#define SS_USB_TX PA2
// ANY OTHER SOFT SERIAL BAUD RATE WILL CHOKE
// BAUD RATE MUST BE BETWEEN 9600..38400
// ANY OTHER BAUD RATE WILL CHOKE
SoftwareSerial SoftSerialUSB(SS_USB_RX, SS_USB_TX);
void setup()
{
//set pins for Software Serial communication
SoftSerialUSB.begin(9600);
pinMode(SS_USB_RX, INPUT);
pinMode(SS_USB_TX, OUTPUT);
delay(1000);
}
void loop()
{
SoftSerialUSB.println("TEST SSERIAL_USB");
delay(100);
}
You need to include this software serial sample code in your SimpleFOC code.
I’m still working on the openerv, and pretty much bent on using the lepton at this point, will review the stuff above. I think I need an integral angle sensor though. It costs more and takes more room and stuff to have a separate board, the boards are quite expensive, I would think the chip costs a lot less.
Lepton Performance MCU internal clock maximum setup.
This below will set your Lepton Arduino project to maximum clock performance at 64MHz since this Lepton PCB has an MCU that is using an internal clock and not using an external clock to save on space and cost.
I credit @runger for the write-up on how to do it and copy here his steps:
use STM32CubeIDE to create a new project for your exact MCU type
use the clock configuration screen like in Valentine’s screenshot to set up a valid configuration. The tool will help you and warn you about mistakes.
save the MCU configuration in CubeIDE, and choose “Yes” when it asks you about generating code.
it will generate a file in the Core/src/ directory of the project called “main.c”, and this will contain a function called “SystemClock_Config”
copy this function into your Arduino project, either into your .ino file or in its own .cpp file.
you don’t need to call the function, Arduino framework for STM32 will call it automatically
if using platformIO, make sure you have the option lib_archive = false in your platformio.ini
That should get you running with a working clock, but really there should be a board variant file for the Lepton which describes its setup details