STM32F103VET6 board

I recently ordered, and just received this board:
http://www.aliexpress.com/item/FREE-SHI … 13337.html

It seems well made, and besides the VET6 MCU, it has a 256Bytes 24c02 eeprom, and a 2MBytes 25Q16 flash memory.
I have not done anything with it but plugging it and checking it turns on.
It has already a program on it that blinks 2 led at a different speed.

So far seems like a very good value for the money. Cost with shipping to US is $13, and arrived in about 2 weeks.

I still need to find the schematic for it.

Looks good value.

I bought this one

http://www.ebay.com.au/itm/301433302819

but I’m still waiting for it to arrive.

If you haven’t started preparing files for the Vxx chips, I’ll start with boards.cpp and the pinmap, and send you a pull request for that folder.
If you have some files ready for that chip let me know and I’ll skip those and work on others.

I think the sd card slot is better than the flash I got in mine, you can edit the files on a computer.

Btw, mine have 2 transistors that I’m trying to figure out what they are for.

Roger,
I started by copying your folder for the Z, and noticed a pin was wrongly defined in board.h:
#define BOARD_USART2_TX_PIN PA2
#define BOARD_USART2_RX_PIN PA3

You had RX as PA1, and should be PA3.

Victor

Ok.

I will double check.

I thought I had tested it, but I didn’t test Rx. My bad.

I will fix, as it applies to multiple boards

Actually, I was thinking of moving these definitions to hardware serial.h as they are the same for all boards.

victor_pv wrote:If you haven’t started preparing files for the Vxx chips, I’ll start with boards.cpp and the pinmap, and send you a pull request for that folder.
If you have some files ready for that chip let me know and I’ll skip those and work on others.

I think the sd card slot is better than the flash I got in mine, you can edit the files on a computer.

Btw, mine have 2 transistors that I’m trying to figure out what they are for.

I started tracing them but had to leave. I saw that they are both connected, one feeding the other, but didn’t not find where the control was coming from. Did not seem to come from any port pin, so it fits with what you are saying about the serial.

I have the leds blinking, and can use the serial to USB port fine, but was not able to get the USB serial to work at first try. Did you get that working?

@victor_pv

USB is not enabled by default in for any of the generic boards, because it only works on the PC if you disconnect and reconnect the cable after each reboot.

This is a limitation of WIndows, but there is a work around

Please can you let me know how you are uploading, e.g. STLink or USB to Serial adaptor etc and also if you are using 32 or 64 bit windows and I can send you instructions on how to enable USB serial

Actually, if you want to have a play. Just look in the Maple mini boards config where it says -DSERIAL_USB and do the same thing in your VET board definition (cpu_flags)

What this does is enabled the USB code to be compiled in. However the USB device won’t appear after upload because windows has no way to know the USB device has been changed

The Maple mini has additional hardware which signals to the PC that the USB device has been changed so the PC then rescans and notices the new USB device.

The work around is a program called devcon.exe which can force a rescan of the PC USB bus, but it needs to be run as admin and there are 2 different versions, 32 and 64 bit. Tell me which you are running and I’ll PM you the file – I don’t think I can attach it to this post for copyright reasons

victor_pv wrote:I started tracing them but had to leave. I saw that they are both connected, one feeding the other, but didn’t not find where the control was coming from. Did not seem to come from any port pin, so it fits with what you are saying about the serial.

I have the leds blinking, and can use the serial to USB port fine, but was not able to get the USB serial to work at first try. Did you get that working?

Luc_Exe wrote:victor_pv wrote:I started tracing them but had to leave. I saw that they are both connected, one feeding the other, but didn’t not find where the control was coming from. Did not seem to come from any port pin, so it fits with what you are saying about the serial.

I have the leds blinking, and can use the serial to USB port fine, but was not able to get the USB serial to work at first try. Did you get that working?

USART 1 is working thru the serial to USB converter, but the STM USB port is apparently not. I haven’t done much testing with it, but I believe the USB port should work even without a bootloader.

victor_pv wrote:USART 1 is working thru the serial to USB converter, but the STM USB port is apparently not. I haven’t done much testing with it, but I believe the USB port should work even without a bootloader.

@Ray, I believe you are correct, the -DSERIAL_USB flag does the trick. I’ve been using it on my generic STM32F103C8XX board, but I don’t know if it works on the VET6

Ray and ahull

A while ago I slightly changed the code so that it uses a different define in order to separate out that the “device has a bootloader” from “device has serial USB”

Because they are actually independent

So the serial USB is now compiled in when SERIAL_USB is defined

However one at the moment for serial USB to work, the code needs to have the DISC PIN number ( and I think one other maple pin) defined in board.h

I had started to remove this dependency from the code, but every time I tried to do it, I managed to stuff up the change and broke things, so I ended up reverting my codebase back to something that worked.

I will try to go through the codebase today and tidy this stuff up, as I think I can also wrap the whole SerialUSB class in a #ifdef statement, rather than the current situation, where for some bizarre reason there are loads of individual IFDEFs in that file.

In the mean time, if Serial USB is not working for you, look in the maple mini board.h file ( or boards.cpp) and look at the define code for Has serial USB and make sure your board variant has the DISC etc PIN numbers defined it wants, or just change that define thing to return true all the time

Luc_Exe wrote:Luc_Exe wrote:victor_pv wrote:…
Edit 2: Couldn’t find a good online editor, so posting the hand made one. Here is the sketch I made for the reset circuit. Need to find the pull up for the reset button (maybe the MCU has an internal pullup), and not sure if one between R8 or R13 is a fuse (don’t have a magnifier to check and the light is not good right now), otherwise it must be a trace I missed between these two resistors (there is no need to put two resistors in series for custom value if we are not working on analog, right?). From what I’ve found, Q2 is a NPN transistor, and Q3 is a PNP.

I’ll appreciate if you can check it, maybe I have made a mistake.

Roger, regarding the discovery PIN, in the defines for that board I have it set to GPIOB pin 9, even though there is really no circuit for that and nothing connected to PIN B9, but at least that would prevent compilation errors or the function crashing, but I still can’t get USB Serial working.

I am sure it is compiling fine, and I have set some blinks here and there to confirm the code is not crashing, but still the USB port never shows up as a Maple Serial.

The funny thing is, I uploaded the maple bootloader to it, and it works for DFU. Of course it doesn’t load the sketches correctly cause the page size is 2k, and I used the maple mini bootloader that has 1KB page size, and I have been too lazy to change the page size and recompile… But anyway the point with the bootloader was to confirm the USB ports initializes and run fine with the bootloader code. I am scratching my head on why not with the sketch.

See my other posting.

Please send me your files

Roger, just downloaded your Master repo, and uploaded an sketch to the VET board, and USBSerial works fine.
Also if I press the reset button it reenumerates

Seems like we are at least 1 step closer to being able to run the maple bootloader in the generic boards

Victor

See the posting in the other thread, Ive attached devcon.exe’s in case you need them

BTW How are you uploading ?

STLink or USB to Serial ?
Or Maple DFU ?

I was using serial for the uploads, the dfu was not loading the sketches right because the page size is 2Kb rather than one.
I downloaded the code for the RET6 board, which has 2kb pages, and plan on adding all your modifications. So far it compiles fine, but I have not tested any uploaded, just changed like the led pin definitions and so on.

Victor

I’m not sure what you mean about 2k page size, I thought they all had that size including the C series.

Why does this make any difference, is this the code in the bootloader ??

The smaller devices, in particular the mcu in the maple mini, use 1KB page size.
The issue with the DFU not having the right page size, is that before writing each 1K block, it clears the page.
With 2KB page size in the device, the process is like this:
Clears 2KB
Writes 1KB
Clears the same 2KB (so erasing the first KB)
Writes 1KB (now only half the page has data, the other 1KB was lost in the second clear for the same page).

There is a maple RET6 bootloader, which uses the right page size (800). I compiled it and it runs, but is failing to upload correctly for some version.
I have to go back and compile it without modifying anything, and check if it works fine, because I started changing things right away, like the compiler optimization.
I am pretty sure once that is working, that we can set the page size in a define, so it can be different for each compilation target (maple mini, RET6, VET6…).

EDIT: I set optimization back to default, results in 12Kb size bootloader, but loads the sketches. There were several changes done to types in the maple mini for that to works before we forked it, while the RET bootloader has stayed the same 4 years, so I will go over those changes and make them to the RET one, and should work.

Hi victor

Ok

My mistake

I thought through looking in STM s flash loader program that it implied 2k blocks when I tried my C8 board.

But it must just be the way the program displays things rather than the internal organisation of the memory.

I had not noticed the difference in the bootloader because the way Leaflabs used branches for in GitHub for the different versions, rather than using a Makefile and definitions in config,h to setup the differences between the board

I will take a look at how to do this properly

Ps. I took a quick look at the code, but I can’t figure out where on earth it sets port c as an output, to control the DISC pin on the maple mini.
I can see the code that sets the pin value but can’t see where the RCC or control reg for port c is setup