STM32F103T8 tiny development board

Since I’m just getting started with the STM32 MCUs, I thought I would start with designing a smaller(than the maple mini) development board. I’ve got the schematic 99% done. I just need to design the footprints to see where I should add the VIN, VCC and GND pads on the headers and triple check everything.

TODO:

-Design footprints. Need to decide on a micro USB port and design a few other footprints.
-Finish schematic.
-Hack bootloader(pin mapping, etc.)
-Design the PCB

Any thoughts or suggestions are welcome. Here’s the schematic so far. Note that D9(On board LED pin) will most likely change among other things.

STM32Noob wrote:
<…>
Any thoughts or suggestions are welcome. Here’s the schematic so far. Note that D9(On board LED pin) will most likely change among other things.

Thanks! I’ll check out some similar boards. I’m hoping to make it about the size of an Arduino pro mini or so. Going to design the footprints in just a little bit.

You can take out R9, R8 and Q1, and connect R5 to VCC directly.
That way you remove a few components and dont need to reserve a pin for DISC. We found a way to cause usb enumeration by just toggling PA12, and the stm32duino bootloader and the core include the code. Just select a “generic” board rather than a maple one when compiling.

Hi, the transistor I’m using is pre-biased, so the resistors were only for show. Can you elaborate on toggling PA12? I’m hoping to start the PCB layout tonight. I would love to ditch that transistor and free up another pin. Thanks!

EDIT:I’m going to read up on the generic bootloader.

EDIT2: Found it. I think I can add the transistor to be sure, though. It’s tiny. Unless you think it’s a waste of time.

On “generic” boards, the USB reset (to force re-enumeration by the host), is triggered by reconfiguring USB line D+ (PA12) into GPIO mode, and driving PA12 low for a short period, before setting the pin back to its USB operational mode. This system to reset the USB was written by @Victor_pv. Note. It is not guaranteed to work on all “generic” STM32 boards, and relies on PA12 having a pull-up resistor of around 1.5k – however most “generic” boards seem to have this. Its unclear if this method to reset the USB bus conforms precisely to the USB standard, but it seems to work fine on all PC’s and Mac’s (and Linux boxes) on which its been tested – and seems usable for hobby / non commericial / non-critical systems.

STM32Noob wrote:
EDIT2: Found it. I think I can add the transistor to be sure, though. It’s tiny. Unless you think it’s a waste of time.

On “generic” boards, the USB reset (to force re-enumeration by the host), is triggered by reconfiguring USB line D+ (PA12) into GPIO mode, and driving PA12 low for a short period, before setting the pin back to its USB operational mode. This system to reset the USB was written by @Victor_pv. Note. It is not guaranteed to work on all “generic” STM32 boards, and relies on PA12 having a pull-up resistor of around 1.5k – however most “generic” boards seem to have this. Its unclear if this method to reset the USB bus conforms precisely to the USB standard, but it seems to work fine on all PC’s and Mac’s (and Linux boxes) on which its been tested – and seems usable for hobby / non commericial / non-critical systems.

Hi,

I had recently started a topic about a Teensy alternative STM32 board using STM32F103C8.
Now I see you have progressed on designing similar board much more ahead than me (I am more focused on my SmartWatch project). It would be great to see such board.

I recommend you to examine STM32F103C8 development boards and schematics (named here as blue pill and red pill) They are my favorite boards since they are very neat, simple designed, commonly used, has small footprint and also compatible with stm32duino with many supported libraries.

Edit: I also found another type of STM32F103T8 board: http://www.artekit.eu/products/devboard … m32-dip36/

Waiting to see some pics
Furkan

Thanks for the tips! I ditched the transistor for USBDP.

I’m new to electronics in general and don’t have very much time to work on anything, unfortunately. I don’t think I could come up with something professional enough for everyone to use with my current skills. When I first started routing the board I didn’t think I could fit the crystal I had on there, so I switched it to the resonator that I used before. I do have the room for it on the board though, after all, so I’m switching it back. Still needs work and silkscreen.

You’re right those boards are tidy. This is mainly just practice for me. I got the board down to 18x35mm.

STM32Noob wrote:<…>
I do have the room for it on the board though, after all, so I’m switching it back.

STM32Noob wrote:. I got the board down to 18x35mm.

That’s AWESOME! I’m not sure what I could design, though…

I just double checked everything and sent off to OSHpark. Swapped the resonator for the crystal, finally decided on the USB port and added the silkscreen for pins and switches. These will only be for prototyping for my actual project that I’ll be working on. I can’t wait to see how the ADC performs, as it could be much better. We’ll just have to see.

EDIT: I just noticed I added the pins silkscreen on actual bottom of the board, as the top and bottom are actually different than how it’ll be on a breadboard. Going to have to be like that for now. I can snap a pic of the pinout and use that.

Nice work!

Maybe you could leave off the first letter of each pin name for saving some free space on silkscreen.
Instead of writing “PA1”, “PB3” etc just write “A1” , “B3” (without the quotes).
Also, you could use bigger font size than the font size you already use.
Some silkscreens are not printer very clear on PCB. A bigger font size could help in solving that problem.

The board looks very neat, even tinier than the blue/red pills.

One thing I just spotted, which I wasn’t aware of, according to the STM32F103xx performance line VFQFPN36 pinout, there is no separate VBAT pin for the RTC and backup power domain (correct me if I am wrong).

This means that any battery powered projects will have to use software sleep tricks, exclusively to keep power usage to a minimum if you want to preserve the RTC values for long periods. You can’t simply kill the main battery and rely on a separate RTC battery.

This is not a major issue, as for most low power projects I would expect the design to use the sleep modes as much as possible. Furthermore several of the STM32F103 boards I have, have VBAT linked to VDD anyway. I think ST missed a trick here, as they could have replaced one of the three VDD pins with VBAT. No doubt the ST designers had their reasons.

Good call on the silkscreen. Would be much better to get rid of the ‘P’ and use larger characters. I used larger text before with a different font and it even got a bit blobbed together.

I really need to check out sleep mode. I haven’t lookd into it at all with these.

Perhaps set all of the labels vertically, or at an angle something like the three I have changed here.

Ooops…. that top label should read B2 of course.

ahull wrote:Perhaps set all of the labels vertically, or at an angle something like the three I have changed here.

Ooops…. that top label should read B2 of course.

no entry sign for images

zmemw16 wrote:no entry sign for images

direct and attachment visible, currently fighting cat for the keyboard.

proxy i’ve never set one, gmail is bw494540

stephen

zmemw16 wrote:direct and attachment visible, currently fighting cat for the keyboard.

proxy i’ve never set one, gmail is bw494540

stephen

ahull wrote:
One thing I just spotted, which I wasn’t aware of, according to the STM32F103xx performance line VFQFPN36 pinout, there is no separate VBAT pin for the RTC and backup power domain (correct me if I am wrong).

This means that any battery powered projects will have to use software sleep tricks, exclusively to keep power usage to a minimum if you want to preserve the RTC values for long periods. You can’t simply kill the main battery and rely on a separate RTC battery.

This is not a major issue, as for most low power projects I would expect the design to use the sleep modes as much as possible. Furthermore several of the STM32F103 boards I have, have VBAT linked to VDD anyway. I think ST missed a trick here, as they could have replaced one of the three VDD pins with VBAT. No doubt the ST designers had their reasons.

Wow, yeah, I didn’t notice that before. I thought the only difference was 64k flash.

I built 3 boards, but only tested one so far. Only tested the blinky code from the Eclipse Arm plugin. Totally works! The board is the same size as the teensy 3. I took a pic comparison. I’ll post it up.

This was my first time with 0402 components as well as QFN. I used a mylar stencil and had issues with the QFN. 0402 and other components weren’t an issue. I’ll let you guys know how the rest of testing goes. Here’s a video for you. I’ve never been happier to see an LED blink.

https://www.youtube.com/watch?v=h-4Xo6C1Xgc

It lives!!

I believe I read an application note on how to trim the RTC internal RC oscillator to make it more accurate. Of course would not be as good as a Chrystal, and when you adjust at one temperature is not so accurate running at a different one, but still may make it usable enough.
May be an option…

victor_pv wrote:I believe I read an application note on how to trim the RTC internal RC oscillator to make it more accurate. Of course would not be as good as a Chrystal, and when you adjust at one temperature is not so accurate running at a different one, but still may make it usable enough.
May be an option…

I’ll have to check this out. My project won’t be as time sensitive like a clock or anything, but I need UART. I was digging and found that they recommend the same resonator I used before for the STMf103xxx. This crystal is pretty massive.

I’m hoping to rock the stm32duino bootloader tomorrow and test the ADC. Hoping it’s not too noisy. We shall see.

EDIT: Here’s a comparison to the Teensy 3.1

I saw quite a few different binaries in the generic folder on Github. Which one should I use and modify to use with this board do you think? I have the onboard LED on PB7. Been a very long day, but I can read more hopefully tomorrow. Thanks!

The main difference in the generic file is which pin has an LED on it.

The other difference is which pin the user button is connected to (if you have a user button)

If you look in config.h its fairly easy to see which config would suit you, and if none match, its quite easy to build a new version, or just hack one of the existing configs to meet your needs

https://github.com/rogerclarkmelbourne/ … 1/config.h

Thanks, Roger. I edited and made the binary. Flashed via FTDI USB2RS232 adapter and unfortunately I got USB device not recognized. I flashed one of your binaries and it worked the first time. I uploaded the blink sketch using the onboard LED and it worked, but the onboard LED isn’t correct in the bootloader.

I read in another topic that people were saying they compiled with GCC 4.8.3 and it worked, so I guess that’s my next step. I have the LED on PB7 and only buttons I have on the board are RST and BUT(boot0).

Side note, I had to use PA9/PA10 for UART and pulled PB2(boot1)low manually with a wire to flash the bootloader. The other UART pins weren’t working for me, so I need to test all the pins to make sure they’re OK.

EDIT:I might not have a chance to fix the bootloader anytime soon, as I’m going into a very strenuous work week. Anyone want to compile a generic bootloader for me with LED on PB7 and no extra buttons? I noticed this thread should be in the custom boards section as well, so you can move it if you like. The help with the bootloader would be appreciated, but I can do it eventually.

Is your LED on PB7 turned on when PB7 is high ?

Update.

I just added generic-pb7

It should not have a button

Please test and let me know if it works for you

Hi, Sorry I forgot. Yes, when the pin is high the LED is on. It goes MCU PIN -> resistor -> LED -> GND. Thanks!

OK, I tried flashing the one you uploaded and it won’t even flash 100%. It errors out @ 99% and says, “Write address and length must be 4 byte aligned.” I flashed another one just to make sure everything is OK on my end and it flashed 100% OK the first time. Weird, huh?

EDIT:My fault.

very strange

I just tried building again, but I get exactly the same bin file.

can you try downloading it again

I tried to just right click the file on github and download it. I noticed it ended up 29k or something. I downloaded it correctly and it flashed perfectly the first try. Everything is perfect so far. Thanks again.

I tried to just right click the file on github and download it. I noticed it ended up 29k or something.

Github can be a bit confusing, the bin links take you to another page, where you then need to press the RAW button, to get the real file if its a bin

Thanks for the tip. This was my first time soldering a QFN package(I’m good with BGA). I used a stencil from OSHStencil and it kind of blobbed around the board a bit. Ended up causing bridging, but I fixed it during reflow. I know now that if you’re soldering QFN packages that a proper stainless steel stencil would really help. Soldering the MCUs were the only issue I had during the whole process.

I have two that are working so far with the STM32duino bootloader. One that all pins work except for PA0, PA1 and PA2 and another with every pin working. The funny thing is, the soldering around the two working ones doesn’t look quite as good as the one that would only upload with an STlink programmer. I MCU you can see in the pic is the one that’s not working. I reflowed the crystal(ehh, it looked OK), but wanted to try to get some closeup shots of the board to you show you what it looks like.

I have enough to go on now to continue testing with my project, but I’ll let you guys know how the MCU reflows go.

Side note, here’s how I’m testing the pins. I’m using a jumper to go from the pin I’m testing over to the LED pin(PB7 on this board). I whipped up this sketch that is very simple. Totally works.

byte myPins[] = {PA0,PA1,PA2,PA3,PA4,PA5,PA6,PA7,PA8,PA9,PA10,PA11,PA12,PA13,PA14,PA15,PB0,PB1,PB2,PB3,PB4,PB5,PB6};

void setup() {
for (int i = 0;i <= 22; i++)
pinMode(myPins[i], OUTPUT);

}

void loop() {
for (int i = 0;i <= 22; i++){
digitalWrite(myPins[i], HIGH);

}
delay(250);
for (int i = 0;i <= 22; i++){
digitalWrite(myPins[i], LOW);

}
delay(250);
}