SimpleFOC Starter Board Dev Kit R&D

[runger]

@nanoparticle

1. Could you explain a bit more about how the standby mode would work with the BOOT0 pin?

You’re right, I did not check the datasheet of the CAN Transceiver - the RXD pull-up would indeed be an issue. That’s a bummer, I think then you would need an additional component like a buffer with active low EN function so that you could switch off the connection between transceiver and MCU completely. The CAN-STB signal would then switch both the transceiver and the buffer to disable CAN and the connection at the same time.

@nanoparticle

2. My case for RS485 is that when I look at existing integrated brushless servo options in the hobbyist price range (i.e. LKMTech, Steadywin, etc.), the two predominant communication protocols are CAN bus and RS485.

Fair enough… there has even been a SimpleFOC dynamixel implementation which you can find in the forum…
Personally I’m just not a big fan of RS485 compared to CAN or ethernet/WiFi/BT. But that’s just my bias, probably.

@nanoparticle

The reason for using the LPUART is that RS485 requires the DE pin, and after a huge amount of pin shuffling this was the only UART peripheral with that pin conveniently free.

Ok, makes sense, and the LPUARTs are in the PinMaps, so they should work. It makes me a bit nervous because some of the other LP-peripherals aren’t supported in Arduino.

@nanoparticle

What else might people be using SWD for?

Personally, I much prefer SWD for programming the STM32s. STLink V3s are faster at programming than other options, in my experience, and it always works without having to reboot while holding BOOT0.
The STLink VCP serial connection remains active even when the MCU reboots, so the serial console is much more useable and you don’t always miss the boot messages due to serial reconnects. Debugging is directly supported on the same connection.
Its just the most convenient way to work with these chips, I find. But of course you do have to invest in a ST-Link. But compared to all the other vendors, ST-Micro is super-fair with their programmers pricing. I think they’re even selling them below cost.

@nanoparticle

5. I2C - perfect, only got one question, is it better to expose 3.3V or 5V on the V+ line?

That’s a good question. After many iterations I now do it like this: I connect 3.3V via a solder (or header) jumper, normally closed. This way you can directly use it to connect I2C target devices like sensors or IMUs, and they’ll be powered with 3.3V.
If on the other hand you want to use the I2C port in target device mode, to control the driver from your RPi for example, then you cut the the 3.3V connection so as not to back-power the RPi.
Personally I never use 5V really, and there are plenty of 3.3V devices available. But should people need 5V there are StemmaQT compatible level shifters they can just plug in-between.

@nanoparticle

7. Wiring the user button and LED this way is intended to allow the LED to be controlled in open drain with internal pullup mode.

Ok, I get it now. It’s what I meant by saying you could not use them at the same time, but multiplexing them in this way should work fine. It will be a bit involved in terms of the code compared to having an extra pin free though

@nanoparticle

3. I really want it to work, but if it’s not looking feasible then I’ll just delete the PD circuitry and move forward using USB to power only the logic as you suggest.

I think it will be possible, but the result for the user will depend a lot not just on the driver board and its firmware, but also where it gets plugged into. MacBooks won’t recognize it as an approved device, and won’t give it more than 7.5W and 5V. Plugging it to a notebook PSU will give it enough juice, but then it won’t be possible to use the DFU. Probably users with a powerful USB-PD Hub will have the best experience.

[nanoparticle]

Well, I spent a while thinking about this project, and came up with a couple of realizations:
Generally this design should prioritize user friendliness over the other aspects, as the target audience is new users. With that in mind, the path forward became clear, and here is the next big revision of the schematic.

Changes are as follows:

• High Level:
  • Moved from 6PWM to 3PWM+Enable on DRV8316C to free up a couple of pins:
    • User button is now separate from the User LED
    • User facing dedicated SPI port now has a dedicated CS pin
  • Debug header has dedicated USART and optional SWO line (for trace viewer functionality)
    • RS4XX transciever moved to become option on user facing USART port
  • Removed HUSB238 USB C PD trigger IC and associated efuse
    • The HUSB238 will be constructed into a separate addon module that plugs into the XT30 and a header with I2C and USB on it
    • This addon will use the remaining onboard efuse for protection
  • Adjusted onboard USB C connector power path to only power logic
    • Changed analog voltage reference source to STM32 VREFBUF 2.9V output, so that analog readings can still be taken even on just USB power
    • DRV8316C buck regulator output placed behind ideal diode before going to +5V rail
      • Ideal diode allows for minimal voltage drop because buck always initializes in 3.3V mode
    • VBUS placed behind B16WS Schottky diode before going to +5V rail
  • Red LED is now NFAULT
  • Added white LED to indicate system power
  • USB now has a BL1530TQFN 2:1 multiplexer IC to direct the signals between either the main USB connector or the aux USB header
  • USART2 RX and TX now have a BL1530TQFN 2:1 multiplexer IC to direct the signals between either the RS4XX transciever or a connector for UART/ADC directly
  • Added 6 pole DIP switch for configuration
    • 1: MCU USB connected to AUX header when ON, otherwise connected to onboard USB C connector
    • 2: USART2 lines connected to RS4XX transciever when ON, otherwise exposed on GPIO header and transciever unpowered
    • 3: PB3 exposed on ABZ encoder header as index pulse when ON, otherwise disconnected (mutually exclusive with 4)
    • 4: PB3 exposed on debug header as SWO output when ON, otherwise disconnected (mutually exclusive with 3)
    • 5: CAN transciever powered when ON, otherwise unpowered
    • 6: 120 Ohm termination resistor on CAN line enabled when ON, otherwise disabled
• Pin Specific:
  • ADC1_IN2_CSENSE moved from PA1 to ADC1_IN11_CSENSE on PB12
  • PA1 now dedicated to USART2_DE
  • USART2/ADC1 lines (PA2, PA3) will now be connected to the RS4XX transciever through a multiplexer IC to switch between RS4XX, and UART/Analog-in
  • LPUART1 (PB10, PB11) changed to USART3, DE pin removed. This will be the dedicated serial port for SWD
  • PC13, PB0, and PB1 (TIM1_CH1N, TIM1_CH2N, TIM1_CH3N) PWM Low Side outputs to DRV8316C removed
  • PC13 is now USER_BTN, which has been separated from the USER_LED pin
  • PB0 is now the SPI1_CS line for the user SPI port
  • PB1 is now the PWM Enable output to the DRV8316C

This changed several of the features in the original list:

• USB C PD no longer available on this board
• DRV now in 3PWM mode (should be fine for almost all use-cases)
• Dedicated UART now shared with RS4XX transceiver

I tossed all the components onto a 50x50mm square board to get a quote, and it ended up looking like this (note none of the component positions are final, and it will likely utilize the reverse side quite a bit)

[nanoparticle]

Overall I feel quite good about this board, though after adding the connectors and some other bits and bobs, the price for 20x boards with double sided PCBA is now about $25 per board. Surprisingly enough, 100x boards is under $14 per board and I think this will work fine once the functionality is all validated.

The main feedback I would like to ask for at this stage is the following:

• Do the connector pinouts make sense? Especially the CAN bus, RS4XX, and CN9
• Any last concerns before I start layout (for real this time I promise )

[rambros]

Nice design! I am planning to design a similar boards using the same ICs (STM32G431 & DRV8316). This STM32 is new for me; I have used ESP32s and RP2040 before.
I have a few doubts regarding your design:

1. Is it necessary to have a 10k pullup resistor for the NRST pin? The IC has internal pullup of 25k-55k.
   

   

2. If the Vio pin of the CAN transceiver is connected to the MCU with 100K pull-down, Will it solve the boot conflict with the PB8 pin? The RXD will be high impedance state at boot.
   

   
   
   
   
   
   You made a clever choice with Reset IC (UM805RE) since you have used all MCU pins.

[nanoparticle]

Hello, thanks for taking a look!

1. I think the reason for the 10k pullup is this forum post. I am pretty sure it doesn’t hurt anything to have it there and worst case scenario it could be made into a DNP component for later revisions, but allocating a spot for the footprint is worth it in my opinion.
2. I think this is a good solution, but would suggest including a decoupling cap on the VIO line as well, and depending how big the cap is may need to reduce the resistor value a little bit. Should work fine if you have the pin available.

Really appreciate the complements, and good luck with your board!

[rambros]

I will go with your advice NRST pullup just to be safe.

@runger initially suggested disabling the CAN ic to prevent conflict with the BOOT0. I figured VIO also disables the IC without any problems with the RXD.

Thanks for your insights, I will share my schematic also.

[dekutree64]

I can confirm that NRST pullup is safer. I made a chance discovery on my Lepton Deku Mod that if I connect a wire to the reset pin, I can trip it capacitively by touching the wire insulation and the motor at the same time with one hand. No conductive contact, and not touching the wire to the motor. Just holding it in my fingers and touching any other part of my hand to the motor. It’s actually quite convenient As far as I know it’s never tripped by accident.