Bootloader failure on VET board

Dear all, I installed the “generic_boot20_pc13.bin” bootloader on a VEt6 board like this:

http://www.ebay.it/itm/141929437789?_tr … EBIDX%3AIT

The bootloader installation appears successful (written and verified 7104 bytes at start address 0x8000000) but, once connected via USB, the device is not recognized; the Windows device manager provides message:

Windows has stopped this device because it has reported problems. (Code 43)

A request for the USB device descriptor failed.

Some more notes:
– the D+ pull-up resistor is 1.5K (resistor code 18B)
– of course I set jumpers BOOT0 = BOOT1 = 0
– I also have a maple-mini clone which instead works correctly

Any suggestion?

Thank you very much in advance and best regards!

Do you have any data on this board.

Initially I thought it was the same VET board that I have

http://www.vcc-gnd.com/read.php?tid=377&fid=6

http://wiki.stm32duino.com/index.php?ti … 3VET6_Mini

But your board looks a bit different.

My board has a 4.7k usb pullup, which normally works, but is not really correct as it should be 1.5k.

Perhaps it is this board. https://translate.google.com.au/transla … rev=search

Can you see any markings that indicate who made it ?

Edit. The diagram on the page I linked to looks like you board, but the schematic doesnt match, as the board silkscreen has pc13 next to the LED but the schematic has PD9

but perhaps they posted the wrong schematic

You could try the generic PB9 bootloader and see if the LED flashes

Alternatively, try uploading a Blink sketch via serial and confirm which pin the LED is on

Thank you Roger!
I performed some further test via serial and I observed a strange behaviour:
– first of all, I’m using the stm32loader.py with Python 2.7 and a CH340 based usb2serial adapter
– I created a blink sketch to test PC13 and uploaded it via serial: upload claimed success (got acks for both write and verify) but no blink…
– then I double checked the upload launching a separated verify: I got errors with pattern “0xADDR: 0xVAL vs 0xff” for each byte (sample error: “0x1b59: 0x0 vs 0xff”) so it looks like the uploads are not really successful…
– I then tried launching also “ReadoutUnprotect” and “WriteUnprotect” but they fail: I get the first ack but not the second (nether a nack, no response at all)..

Any idea on what could be the problem?

Thanks again in advance and best!

Are you using Linux or WIndows? (or OSX)?

If you are using Windows, you can use STM’s own uploader, as you can reset the read only locks etc that way.

Also.
Try using Serial.print

As Serial maps to the USART 1 i.e you USB to serial converter

I’d recommend just writing something like …

(Totally untested code, but you see what I mean)
void setup()
{
Serial.begin(115200);
}

void loop()
{
Serial.println(c++);
delay(250);
}

What a dumb!
Verification is OK, I forgot to remove the “erase” option from the verification command line that I created as a c&p of the write one..
Then I’ll perform some further investigation and I case I come back.

Thanks again and best, E.

Hi Roger, I’m using windows 8.1.
I tried blinking on PC13, PB9 and PD9 but no luck.
I also tried following code as you suggested:
void setup() {
// put your setup code here, to run once:
Serial.begin(115200);
}

void loop() {
// put your main code here, to run repeatedly:
Serial.println("Test");
Serial.println();
}

It looks like you are running Windows, and its compiling and uploading

Its probably worth downloading STM’s “Flash Loader demonstrator”

STM now seem to require you to register to download it, but it seems to be available elsewhere if you don’t want to register

So google for it and you will find places to download it directly https://www.google.com.au/search?q=flas … r+download

You can do a full device erase using that program, (but I’m not sure if that’s really going to help)

I’ve attached binary file that runs fine on my STM32F103VET board, and if your LED is on PB9 it should flash and it will output on serial counting up.
Even if the LED is not on PB9 it should output on Serial.

#define LED PB9

void setup() {
// put your setup code here, to run once:
Serial.begin(115200);
pinMode(LED,OUTPUT);
}
int c=0;
void loop() {
// put your main code here, to run repeatedly:
Serial.println(c++);
digitalWrite(LED,!digitalRead(LED));
delay(500);
}

Ok, some (not good) news: I also have a ZET6 mini board (this one: http://www.ebay.it/itm/291550089382?_tr … EBIDX%3AIT); I uploaded the mass storage demo on both boards:
– ZET6: OK, the mass storage is correctly identified by windows
– VET6: KO, nothing happens

Should I now assume the VET6 is broken?!

Is there anything else I can check?

Thanks in advance and best regards, E.

umm
sounds like its defective

You could check the crystal osc freq is 8mhz, but most boards are.

things dont work well if they have used a 12mhz crystal, but I would still expect output via serial from the sketch, but it would be garbled.

I think the serial upload uses the rc osc, not the crystal

Ok, the bootloader seems working fine as well as writing to and reading from flash.
This tells me that the core seems fine.
Effectively it could be the external oscillator (btw: it’s 8 MHz, I checked) so I could try with some test program that uses the HSI in order to double check the core.
Could it be you already have some available?

Thanks again and best, E.

Ok, it looks like the problem is in the PLL.
I could successfully run a blink sample (with blinking freq of about 4 hz) with all HSI, HSE and 72 MHz configurations on both boards:
– ZET6: frequency appears correct with all 3 configurations
– VET6: frequency appears correct with both HSI and HSE but is completely wrong (about 10 times slower) with 72 MHz..
Note: I used a SPL blink sample to test the different configurations.

Are you aware of any kind of differences in the PLL configuration between VET6s and ZET6s?

By the way: I can confirm the led is on PC13.

Thanks and best, E.

AFIK, There are no differnces between the clock PLL settings in the whole F103 series.

You can check the master programming manual fo the STM32F1 series,

http://www.st.com/resource/en/reference … 171190.pdf

If the HSE ( High Speed External) crystal osc wont start, the code hangs during the core initialisation, as it waits indefimitely for the flag indicating the osc is running.

I suspect you have a fault crystal osc on that board, and the MCU thinks its a much lower frequency.

You could hack the core and change the PLL multipler and there is also a 2 x pre multipler as well, but I am not sure you will find a combination of PLL settings that will work and the osc is likely to pack up completely at any random time.

Could be a bad capacitor’s value around the xtal which prevent the oscillation startup.

Or dry solder joints

i would attempt to resolder the osc components with an soldering iron, or reflow air tool.

Ok, thank you both for the suggestions, I’m not very good with soldering, moreover with smd microscopical parts anyway maybe I’ll try it.

Thank you again and best! E.

edogaldo wrote:Ok, thank you both for the suggestions, I’m not very good with soldering, moreover with smd microscopical parts anyway maybe I’ll try it.

Thank you again and best! E.

It’s incredible!!!
It looks like I found the problem: checking the pbc it seemed me there was a micro short-circuit between OSC_IN and OSC_OUT, I passed the cutter between them and… magic! Now everything seems working..
Also the mass storage demo!!

Best regards, E.

edogaldo wrote:It’s incredible!!!
It looks like I found the problem: checking the pbc it seemed me there was a micro short-circuit between OSC_IN and OSC_OUT, I passed the cutter between them and… magic! Now everything seems working..
Also the mass storage demo!!

Best regards, E.

Well…

We’ve all learnt something new… Serial upload works even if the external crystal doesn’t

BTW. It looks like the USB mass storage binary that I retrieved from the HY-Tiny STM32F103TB board, is indeed just a mass storage demo..
Because I found the source files for it, in with the downloadable files on the manufacturers website.
But the files are built in Keil, and use the old STM Standard Peripheral Library, so not really that useful.

If anyone is interested in using mass storage, I recall there is some code to use mass storage with libmaple, but I think it would take some time to get it to work

https://github.com/joeferner/maple-usbMassStorage

Hi Roger, yes, the USART boot loader uses the HSI, this is documented in RM0008 (last note of par. 3.4).

edogaldo wrote:oger, yes, the USART boot loader uses the HSI, this is documented in RM0008 (last note of par. 3.4).

So that other people who buy the same board know how to set it up…

Can you take a look on the bottom of the board and see who its made by.

I suspect its made by a Chinese company vcc-gnd.com

http://www.vcc-gnd.com/read.php?tid=377&fid=6

I think I’ve previously posted a link to the board on vcc-gnd.com, but want to be sure its the same board.
i.e the schematic says it has a LED on PC13 like yours does and the diagram seems to have jump links for Boot0 and Boot1, like the picture in the eBay listing

BTW.

I my VET board is this one

http://www.ebay.it/itm/STM32F103VET6-AR … Sw2XFUh7Ay

It seems to be the same price but has a SD Card adaptor on the underside of the board and also has external EEPROM memory – and appears to be the same price

Yes, I can confirm it’s the same board from vcc-gnd.com.
The only difference respect to the schema you posted is the value of R8 (the D+ pull-up) which in my board is 1.5k (also checked with my meter).
I’ve seen also your version on ebay but I preferred this one since it uses an AMS1117 as the 3v3 voltage regulator which, as I could understand, should be able to support higher current drain; by the way, also mine has the external eeprom as you can see in the schema, it’s missing the SD adapter but I think I won’t need it for my purpose.
I also have a ZET6 board which is like yours (with switches instead of jumpers, RT9193 as LDO, SD card and eeprom) and includes also a separate flash, it’s about 3 USD more.

Thanks

I have the same ZET board that you do (I have both VET and ZET, and many others

Cheers

Roger

By the way, one thing worth to note about these boards if not aready done.
The board’s g.p. led is between vcc and the pin instead of between the pin and gnd, this means the behaviour is the opposite respect to standard Arduino and Maple Mini boards (don’t know about Maple standard since I don’t have any): the led is on when the pin is low and off when the pin is high.
This confused me initially because I didn’t properly check the schema..

Thanks for the Info on the LED.

This is quite common, especially on boards made by vcc-gnd, and I try to highlight this in the wiki.

Note the wiki page design for the boards is evolving over time, as I get a better idea of the information that needs to be displayed. So some boards list this sort of information but not all do.
Unfortunately I don’t have time at the moment to go though all the wiki pages and update all the things I would like to