The difference between the Maple mini and Maple boards and the generic boards, is that the Maple boards have the additional hardware to reset the USB and force the host system (PC etc), to look again at the USB ID of the board.
The Maple boards need to reset the USB, because the upload protocol used is DFU, and requires the board to identify on USB as a DFU device when it boots.
However the Serial USB that the Maple mini has, is built into the sketch, and requires a different USB device ID code VID/PID. So to force the host system (pc etc) to recognise that the board is a serial device when the sketch runs, the board has to reset the USB bus, which is does by pulling one of the USB lines high (possibly to 5V) using a small circuit consisting of two transistors.
If the USB device, didn’t need to change from DFU for upload, to Serial for the sketch, there would be no need to reset the USB bus, and hence the board would not need the reset hardware.
It looks like LeafLabs started to develop a version of the bootloader that we may be able to make use, because it uploads via serial, and it uses the same USB VID/PID as the sketch
See https://github.com/jonatanolofsson/mapl … erial-boot
There is an extensive description, which seems to imply that with modification to the Sketch there would be no need to reset.
So its definitely something worth investigating, so I will probably re-organise the repo so that we have 2 different bootloaders rather just the DFU upload one we currently use.
Some background: my day job includes writing bootloaders for embedded micros 
In the past, these have been connected by simple serial (RS232 or RS485) with a UART peripheral. For our embedded products (no external access) we have developed a quite robust and easy to use bootloader. It does have one potential weakness, but so far it has not caused a problem, as we carefully manage and test software releases.
Recently though, I ported our “standard” bootloader to a new product using a native USB. I encountered the same problems that LeafLabs (and others) ran into with the interaction between the device, USB and Windows. I got it to work ok, but it was not as good as the simple UART version. For us, downloads are an occasional thing, so it didn’t matter if it was a bit clunky.
Our experience with native USB (and other problems, e.g. drivers!) persuaded us to drop that route, and in our next product use an onboard FTDI USB-serial chip to do the USB, feeding it into a UART on the micro. This works a lot better, and I was able to port the bootloader in a couple of weeks.
So anyway, enough about me… What I learned from all that was to avoid bootloader and application sharing the USB. There are some systems that implement USB bootloader in quite a seamless way (without extra helper chips, like mbed), for example Smoothieboard and R2C2 printer controllers (I had a hand in the latter). Those were made easier by some features of the LPC1768, which has a built in “drag and drop” bootloader (nice feature).
Getting a truly seamless bootloader that works well in all case probably requires an external helper chip, and a specific hardware/software design. The Teensy 3.1 works really well in that respect. If we are not working with our own hardware or software design, it will need some compromises.
Perhaps we could define some use cases, and develop a bootloader that covers most of them. I realise most of this post is generalities, I will have a mull over and come back with some specifics.
OK. Thats a shame
I thought that perhaps because the Serial Bootloader, only enumerated as a Serial device, that perhaps we could avoid the problems with them multiple devices on Windows.
Actually, I think there is some issue with the Serial USB that gets built into the sketch.
I changed the repo last week, so that Serial USB is compiled in, on a separate flag to the bootloader flag, in fact i removed the -DBOOTLOADER_maple as it did too many unrelated things
and added -DSERIAL_USB instead
I changed one of the board definitions (the F103ZET) to have have an option where the bootloader was compiled in, and low and behold a generic STM32F103ZET board, gets USB Serial like the Maple
However…..
I was testing uploading via STLink last night, and I have realised that this doesn’t really work properly
If I upload, then physically disconnect and then reconnect the USB connector, the board appears as a Maple serial device (using the windows serial driver)
and I can use Serial.println() etc
However if I upload via STLink, which runs the code again, – although Windows still reports the Serial device, the text doesnt appear in the terminal 
I presume that what must be happening is that the virtual serial driver on windows is getting out of sync with whats happening in the serial USB code in the sketch
So I’m going to remove this as an option until we can come up with a fix.
Or perhaps there is no software fix for this?
Do you know if there is anything that the serial code in libmaple could additionally do, to let the driver in windows know its been rebooted ?
Or perhaps STLink needs to reset the whole board, rather than just running code at 0x800000 (though I dount that would make any difference )
Thanks
Roger
Please forgive my ignorance here, but is the generic implementation releasing the port and is there something in the sketch that is waiting for windows to re-enumerate serial devices.
I don’t have STM32 hardware yet, but the ATMega32u4 based boards have issues with serial as well since the 32u4 is handling USB for upload AND serial communications.
http://www.arduino.cc/en/Serial/IfSerial
It took me a good while to get serial to work right on the Micro 32u4 even though it;s simple code in the sketch.
You probably have been through this, so please disregard if you have,. It just sounds like the same thing the Leonardo/Micro does after uploading a sketch.
Leaflabs have an excellent description of how the Maple bootloader works.
See http://leaflabs.com/docs/bootloader.html
Basically, they initially tried to have the DFU and Serial USB device firmware in the bootloader, and for the bootloader code to continue to execute after the sketch was running ( as the bootloader code would handle serial USB for the sketch)
But basically that would not work on windows.
So the USB serial code was moved to the sketch.
Hence its possible to build a sketch for any generic board that has USB serial.
I have tried this on my stm32f103ZET and F103RCT boards and they do appear as serial devices on my PC and I can use Serial.print etc
However the problem is that every time you upload the sketch to a generic board, you then have to unplug and reconnect the USB otherwise windows doesn’t now the board has been reset and the serial driver seems to get out if sync with the board.
And the same applies to the Maple bootloader. After the upload (using the DFU protocol), the bootloader shuts down all its USB code, and jumps to the start of the sketch in Flash memory.
However if the USB bus is not reset, the PC doesnt notice that the DFU device has been removed and that the board is now a Serial device.
To get around this problem, Leaflabs added a small circuit, that pulls one of the USB lines high, which the host PC notices, and the PC checks what device is now connected .
If you look at the Serial branch of the Maple bootloader, I linked to earlier in this thread, This version of the bootloader always stays as a serial device, so technically, there is no need to reset the USB bus to signal a change of device to the PC , when the code in the sketch runs.
But… My experience with trying serial USB on generic boards has highlighted things are unlikely to be plain sailing, and as BobC has said, its very very hard to produce good bootloaders.
I will make a separate folder with the Maple Serial bootloader, from the Serial bootloader branch, so that we have some code for people to work with, if they feel like playing with it.
I will also post instructions on how to compile the bootloader under Windows as to use Make you need to install MinGW.
You can of course use CooCox or Em::Blocks to compile the bootloader, but Im not sure I will have time to setup an Em:Blocks project
Not a big surprise to have to cut power and power it back up to get serial to work. Too bad we don’t have a link to the cpChinese manufacturers to request the Maple hardware to pull the line high.
The Maple mini clones have the hardware already, its just the generic boards that don’t
But there are loads more generic board types, and the Maple minis are all F103CB’s
It think only iTead studio sell a Maple board ($13 on special offer), but it uses the F103RB chip not the F103RE, hence it doesn’t have the DAC’s. so you may as well buy a generic F103VE for around the same price, as it will have DACs and more flash and I think more RAM
The idea behind producing a Bootloader for generic boards, was that no additional hardware would be required, so everyone could use any of the dozens of generic boards that are coming out of China
Anyway, I’ll add the Serial Bootloader to the repo and call it Generic bootloader, and leave it for the community to look at possibilities
Maybe I’ll have a go at the generics next… Or a discovery STM32F4 board… So many choices!
Support for the F4 is very limited at the moment. The status of the port is roughly equivalent to the Arduino API from 3 or 4 years ago.
I’d not recommend you get an F4 board, unless you fancy updating the core code 
If you don’t have a Maple mini, see MrBrunettes recommendation on who to by from.
If you already have a Mape mini and want a board with a bit flash and ram, I think the most cost effective solution are the STM32F103VET boards available on AliExpress.
For Generics you’d need a USB to Serial adaptor and you may want to consider getting an STLink (clone) for a few $.
http://stackoverflow.com/questions/5297 … ly-removed
I’d need to figure out exactly what code to write, but basically this is saying that its possible to force Windows to think that the USB device has been disconnected and reconnected.
This is what the extra hardware does on the Maple mini board
@hull already has this working on Linux using this code
/* usb-reset -- send a USB port reset to a USB device
Compile with ...
gcc usb-reset.c -o usb-reset
... then copy the resulting usb-reset binary to /usr/bin or some other suitable place in your PATH
*/
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/ioctl.h>
#include <linux/usbdevice_fs.h>
int main(int argc, char **argv)
{
const char *filename;
int fd;
int rc;
if (argc != 2) {
fprintf(stderr, "Usage: usbreset device-filename\n");
return 1;
}
filename = argv[1];
fd = open(filename, O_WRONLY);
if (fd < 0) {
perror("Error opening output file");
return 1;
}
printf("Resetting USB device %s\n", filename);
rc = ioctl(fd, USBDEVFS_RESET, 0);
if (rc < 0) {
perror("Error in ioctl");
return 1;
}
printf("Reset successful\n");
close(fd);
return 0;
}
Support for the F4 is very limited at the moment. The status of the port is roughly equivalent to the Arduino API from 3 or 4 years ago.
I’d not recommend you get an F4 board, unless you fancy updating the core code
If you don’t have a Maple mini, see MrBrunettes recommendation on who to by from.
If you already have a Mape mini and want a board with a bit flash and ram, I think the most cost effective solution are the STM32F103VET boards available on AliExpress.
For Generics you’d need a USB to Serial adaptor and you may want to consider getting an STLink (clone) for a few $.
I have managed to get hold of a 64 bit version of Microsoft’s devcon.exe and it can indeed force the removal of a windows USB device and also rescan as if a new device had been connected or it can individually install a device
This now allows generic boards to be uploaded via STLink but still to have USB Serial, as the Windows USB Serial driver can be reset after upload, however the timing seems to be fairly critical
i.e the USB device must be reset straight after the upload, (the timing seems fairly critical), otherwise this doesnt work.
Anyway, as this is somewhat off topic, I’m going to post this to general discussion
Just thought I’d post something I found…
There appears to be an STM32 board that runs JavaScript.
https://github.com/espruino/Espruino
The interesting thing, is that its bootloader is an implementation of STM’s own Serial upload protocol, but implemented over the on-board USB.
http://www.espruino.com/Serial+Bootloader
Strangely however their circuit still seems to contain have some USB reset hardware.
Their hardware is a single transistor and 3 resistors and appears to be the same as used on the Nucleo.
I’m really not sure why they’d need the USB reset hardware if the board operates as virual USB and nothing else, perhaps except at start up.
I guess we could post a question to their forum.
Its not possible to load their bootloader on the Maple mini etc, as their bootloader and main program are one and the same and are around 256kb long !
Luckily I have a F103ZET board, which has plenty of space for this, so I’m going to have a go at loading their firmware
I will post when I have more information
If you are talking about the transistor switching the 1.5K PullUp, beware that it can also be used to identify the USB device as FullSpeed.
Quote from http://www.beyondlogic.org/usbnutshell/usb2.shtml :
A USB device must indicate its speed by pulling either the D+ or D- line high to 3.3 volts. A full speed device, pictured below will use a pull up resistor attached to D+ to specify itself as a full speed device. These pull up resistors at the device end will also be used by the host or hub to detect the presence of a device connected to its port. Without a pull up resistor, USB assumes there is nothing connected to the bus. Some devices have this resistor built into its silicon, which can be turned on and off under firmware control, others require an external resistor.
Thanks for the USB information
The USB hardware seem different on the various boards I have looked at, so its good to know why there are either pull ups, or transistors biased to their on state or resistor dividers attached to the various USB lines
Most of the generic boards I have, can be made to work with the USB serial code (built into the sketch) but one stm32f103c8 board, doesn’t work. Which suggests that perhaps it doesn’t have any form of pull-up – but it could just be a hardware fault.
I’m not sure how much interest there is for a generic bootloader, because of course people would need to flash the bootloader in the first place.
Perhaps we’d be better off creating the equivalent of the Arduino as ICP. This would just be some sort of pass through system, and would be a bit slow, as it would need to use software serial on the UNO , but it would jump start people who want to move from the UNO to the stm32
The USB hardware seem different on the various boards I have looked at, so its good to know why there are either pull ups, or transistors biased to their on state or resistor dividers attached to the various USB lines
Most of the generic boards I have, can be made to work with the USB serial code (built into the sketch) but one stm32f103c8 board, doesn’t work. Which suggests that perhaps it doesn’t have any form of pull-up – but it could just be a hardware fault.
Not sure what you mean about a board with 2 uarts ?
re 2 different types of sketch, e.g. One with built in bootloader.
I think you mean, build a sketch with built in uploader capability.
I suspect that is possible. It’s kind of like a bootloader with blink sketch attached to start with
Umm
Possibly I guess…
Sorry, don’t know where I did read about the 2 UART on the nano v3 (mega328p), but checked again and there is only 1 , so as you said, virtual serial port must be implemented and hence low speed rates.
Yeah, like that.
Put first the sketch with the bootloader, this sketch should only have the ability to “jump” to the first address after the offset. So that basic sketch is now “part of the bootloader”. The next sketches you compile and upload will be writen after the offset, so the “extended bootloader” (bootloader + initial sketch) is able to execute it and just think its part of the original sketch (te one you loaded with the bootloader in first time).
Could you clarify some doubts I have?
¿Is not possible to upload the bootloader without other code in the sketch?
¿Where is defined or who tells the initial addres to start writing the flash? is the MCU config of the selected board in the ide? (if so, how difficult is to edit the starting address?)
¿how difficult is actually edit little parts of the bootloader? ¿is it low level?
PS: fixed the link in the previous answer.
I think the same, that can help people to start using the stm32 boards.
I agree.
If people buy a generic board, it won’t have anything installed on it at all, so they are going to need extra hardware e.g. USB to Serial or STLink
Buying a Maple mini is everyone’s best entry point, but some people still seem to go for a generic F103C8 boards, perhaps they are fractionally cheaper in some countries, but on the whole the Maple mini seems
I don’t personally understand why they’d want to buy those generic boards..
Unless they are an experienced developer, like Rick and @ahull are. In both cases I think they are using STLink and Rick is using Eclipse
I can understand people buying F103VET and F103ZET boards if you have a specific application which needs more Flash and RAM and possibly more pins, but again, in these instances, anyone using them is likely to be an experienced developer
I guess the only think that may be of benefit to support those sorts of dev’s is the stuff that @ahull and also I have been doing to use STLink as upload / debug, and use the on board usb connector for USB Serial.
But I’ve basically got that working – it just needs a bit of finessing to work around it needing admin rights to reset the USB device.
There seems to be another thread going on about a custom uploader viewtopic.php?f=37&t=81
This is probably more beneficial than a custom bootloader
I agree, relationship between cost and benefits (in this case the usage vs the effort to make it) cannot be taken out from the evaluation (unless someone really have some time waste). Especially when there is more than one accessible alternative, and there are other priorities.
@Rick
The part you have quoted missed the detail one needs just a cable and the other needs external hardware. But that’s only for little more portability, I still agree that is not a real problem at the moment as the embedded serial bootloader is functional enough.
@Roger
I disagree with some points. Let me explain my point of view, as I’m one of the many examples of people in the process of joining the stm32 developing.
At the moment of purchase (end of march), there wasn’t many places to find info. And if I search now, the snecario is the same. Places with info are not novice friendly, imknow now, but without many time reading is hard to know that getting started needs almost yes or yes a mapple or mini board. I know this is one of this forum goals, but is still too young and need time to grow enough to be suitable for 4 levels (people not decided yet wich plattform to use, hobbyst, novice devs and experienced devs).
Arduino is great because of 2 main things: easy to use and cheap to get started, we are missing the first part. Right now the panorama is “to get experience you need experience”. The words you said “Buying a Maple mini is everyone’s best entry point” should be in a place where every visitor can see it, if were up to me, I could put it with big red font in the banner 
About the MCU/Board picking. When you purchase a development board for many projects, you may want to have as many resources (ram, flash, IO, peripherals…) as possible if they are in the budget. From the idea to the end of developing many things can change, as those are prototyping boards and they are not made to directly fit in the final product, but to help you in the developing process. You can go for a smaller device when you are almost to finish and know the requirements. Bigger MCU is more flexible for developing than an smaller one.
PS: if there is not an easy get started I don’t dislike the “for the adventurer or experienced” tag anyway. I only fear to exploding capacitors 
Luciano,
What platform are you using ?
I have an experimental way of using the onboard USB as a Maple Serial.
I think this may be the best option for STLink uploads
I think that STlink upload is likely to be the method of choice soon, (if we can get in circuit debugging working !)
viewtopic.php?f=28&t=37#p221
I suggested the bootloader but it is not very important since I have serial adapter and STlink. I need more time to experiment
Edit: next board can be a Nucleo NUCLEO-F411RE 512Kb of Flash and 128Kb of RAM, 10.12$ from ST store (don’t know about shipping cost) but is an F4
Edit2: I can’t find Maple Mini on ebay under 9.5$. There are sellers that sell under 9.5$ but don’t ship to Italy
If I upload, then physically disconnect and then reconnect the USB connector, the board appears as a Maple serial device (using the windows serial driver)
and I can use Serial.println() etc
However if I upload via STLink, which runs the code again, – although Windows still reports the Serial device, the text doesnt appear in the terminal
I presume that what must be happening is that the virtual serial driver on windows is getting out of sync with whats happening in the serial USB code in the sketch
EDIT:
I was wrong, it was causing the board to reset.
JTAG/SWD is faster and better and avoid all the messy problems, it also allows proper debugging. My view then, is that for developing, we should be using a JTAG adapter, and that is what I use. For newbies, it is really not that much more difficult to use a USB-JTAG than USB-serial.
<…>
Thanks for another great description of how the Maple bootloader works.
Having messed around with it a bit. I think adding the USB reset hardware to a generic board, is probably going to be the simplest and most reliable way.
Like Ray says, the Maple mini is generally very easy to upload to. The only time when things go wrong is when the sketch crashes and the USB serial stops working, so that it can’t respond to the reset command bytes from the IDE
But using the perpetual bootloader mode fixes this, or what also seems to work, is just holding down reset until the compile has finished and DFU util is looking for the board.
I.e I don’t think the extra button is absolutely necessary to use the Maple bootloader, but the disconnect hardware appears to be needed.
Actually @victor and a few other people have conjectured that perhaps the D- pin ( sorry don’t have the reference to hand), could be switched to GPIO rather than its USB function and driven high, as this would have the same effect as the reset hardware.
But there must be some technical reason that this simple system was not used. Perhaps too much current would be drawn from the GPIO. But perhaps an ultra fast pulse of High would be ok without frying the GPIO.
Ray
The Cypress PSoC cheats really. We could probably do the same cheat.
When you build a PSoC project, you must include the bootloader module in your code.
If you don’t include it, you can’t upload next time, because there is no uploader in the PSoC
However I’m not sure how the code in the PSoC manages to run while overwriting its self.
Well, I guess it doesn’t. It’s probably in a different linker section in a defined block of memory pages, and the bootloader code knows not to overwrite its self possibly
Still.. I thought if you forget to include a bootloader module in your PSoC project, don’t you basically brick your PSoC unless you have an external programmer .
Re debugging
I wonder what the IDE team intended to do with the Zero. They would need the same functionality as we do. And I’d be surprised if their solution didn’t use GDB at the lower levels (or an equivalent )
I have a JTag clone, and an STLink clone, and I am really warming to STLink.
The clones are very cheap, and work well, and even if the supply of the cheap STLink clones dry up, there would be the option to flash Black Magic Probe to a $4 generic F103C8 and use that as the debug tool.
Actually the STlink binary has escaped onto some Russian websites, so the genie is out of the bottle for STM, and I think they should just make the STLink and also the Nucleo co processor firmware free to download, as they will make more money selling more chips than they make from selling Nucleo boards.
Upload using STlink and using the on board USB for serial does work, but requires extra code on the host side to restart the USB driver.
This is more difficult on Windows than Linux, but I do have it working on windows and @ahull has it working on Linux
I seem to remember that V-USB does (can do) this trick…
http://www.workinprogress.ca/v-usb-tuto … mega-tiny/
Before you enable global interrupts with sei(), you should do the following:
Ensure that the I/O pins used for USB are all inputs and the internal pull-up resistors for these pins are disabled. This is the default state after a reset.
Call usbDeviceDisconnect(), wait several 100 milliseconds and then call usbDeviceConnect(). This enforces (re-)enumeration of the device. In theory, you don’t need this, but it prevents inconsistencies between host and device after hardware or watchdog resets.
Call usbInit() to initialize the driver.
Very interesting. I wonder why leaflabs chose to use an external circuit for this… Shame we can’t ask them, but they are busy doing new stuff ;-(
Very interesting. I wonder why leaflabs chose to use an external circuit for this… Shame we can’t ask them, but they are busy doing new stuff ;-(
That’s interesting.
I think Rick noticed that the GenericSTM32F103C8 boards have a 1.5k resistor between one of the USB lines and 3.3v ( I think it was the D- line but I can’t be sure)
So on those boards, it sounds like the host system must presume its a USB 3.0 device, because on cold boot the GPIO pin to which D- is attached will be floating, so the resistor will pull D- high.
Then when the USB setup code runs in the uP it will override the 1.5k resistor.
So it could be that these boards can re enumerate simply by putting the D- pin on the uP back into input mode.
Or have I got it wrong and 1.5k to 3.3 is for USB 1.1 ???
That’s interesting.
I think Rick noticed that the GenericSTM32F103C8 boards have a 1.5k resistor between one of the USB lines and 3.3v ( I think it was the D- line but I can’t be sure)
So on those boards, it sounds like the host system must presume its a USB 3.0 device, because on cold boot the GPIO pin to which D- is attached will be floating, so the resistor will pull D- high.
Then when the USB setup code runs in the uP it will override the 1.5k resistor.
So it could be that these boards can re enumerate simply by putting the D- pin on the uP back into input mode.
Or have I got it wrong and 1.5k to 3.3 is for USB 1.1 ???
pinMode (PA12, OUTPUT);
digitalWrite (PA12, LOW);
delay (100);
Serial.println ("Setting PA12 Floating");
pinMode (PA12, INPUT_FLOATING);Can you zip up your VET variant files and boards.txt and post it to the forum, or email it to me
I have a ZET board which is a superset of the VET so I can give your files a go on my board.
I suspect serial USB is not being compiled into the sketch, but without seeing your setup its hard to know what is wrong
https://github.com/victorpv/STM32F1_Modified/
Thanks for checking it.
You will notice I tried to make pin_map to flash conditional, but that is not working as I wanted, so I think it is going to ram as it is right now in those files even if I select the option in the board menu. Not sure what I did wrong, but don’t worry much about that.
Rick thanks for testing, I am glad to know in another board. Hopefully it will be consistent.
If it seems to work properly I think we could try to include it either in the normal sketch init() routine, or in the bootloader right before calling the sketch.
EDIT: Rick I see you set the port low, but don’t see you change the PA12 after that, is it brought back floating by the USD dev setup?
I had a quick go with my F103ZET and also F103C8 boards but couldn’t get USB Serial to work on either
I’m sure it was working the other day, so I don’t know what I changed
I’ll stay on my main branch and add your VET files
BTW. My VET board arrived in the post this morning, and it looks really good.
Is smaller than the one you have, and is approx 2/3 the size of a Uno. I really like the size, its a good compromise as the ZET chip is massive (unnecessarily large for most jobs I suspect)
It has a ATMEL 24C08 (I2C EEPROM 8K) on the back as well as micro SD card slot
Actually my ZET board has Micro SD as well, but I’ve been too busy to try it.
I’ll add you V series stuff into the repo if I get time this evening
Thanks
Roger
Edit
I just noticed I was on a branch of code where the whole archive flag had been removed, perhaps this breaks Serial USB as well
I’ve updated the files (mainly boards.txt) and have included them in the repo for the F103V
I’ve done some basic testing but I’ve not had chance to test on my V series boards, because I need to solder the headers on and I’ve not had time to do that yet, because its taken a while to update your new section in boards.txt to match with changes to platform.txt
The other thing I’ve tried to do, and is to incorporate your USB reset into the Serial USB init code
See f103z/wirish/boards_setup.cpp
__weak void board_setup_usb(void) {
#ifdef SERIAL_USB
//Attempt to reset the USB interface - developed by Victor PV
gpio_set_mode(PIN_MAP[PA12].gpio_device, PIN_MAP[PA12].gpio_bit, GPIO_OUTPUT_PP);
gpio_write_bit(PIN_MAP[PA12].gpio_device, PIN_MAP[PA12].gpio_bit,0);
for(volatile unsigned int i=0;i<5000000;i++)
{
asm("nop");
}
gpio_set_mode(PIN_MAP[PA12].gpio_device, PIN_MAP[PA12].gpio_bit, GPIO_INPUT_FLOATING);
Serial.begin();// Roger Clark. Changed SerialUSB to Serial for Arduino sketch compatibility
#endif
}
I suspect that it working or not may depend on several factors, I am trying to narrow down what else needs to happen. In my board it was working while the USBSerial itself was not, it may depend on the USB peripheral being shutdown or something like that.
I wrote a couple of functions that shutdown and re-enable the port, so I can throw them in and see what happens.
I am more interested in just getting the SerialUSB working first, and then after that see if I can force the re-enumeration.
I presume you are using windows ?
I’m not sure if you posted if you were using 32 or 64 bit.
Let me know as I need to pm you some exe files
Edit
While I remember…
I took a look at the Maple bootloader code the other day to see when it uses the Disconnect line, and it seems to be in the code that is called prior to jumping to the start of the sketch code
Anyway, one thing I noticed, is that it is hard coded to use PC12, in hardware.c, ie unlike the LED and “button” pins, there isn’t a #define for it, in config.h
This may partially explain why I could not seem to use PC13 on my generic board as the LED even though I changed all the necessary registers in config.h
I will need to look through the bootloader code again, because at the moment I can’t see where it’s setting up the RCC for Port C nor where it sets up that PC12 is an output.
I suspect wherever its setting PC12 as an output, its possibly setting PC13 as an input, unless its doing a masked OR of the update
Btw here is the reset code.
I.e it can’t be holding in reset that long, because the GPIO init still will be clearing the DISC pin in I suspect less than a millisecond after starting execution of the sketch init code
void jumpToUser(u32 usrAddr) {
typedef void (*funcPtr)(void);
u32 jumpAddr = *(vu32 *)(usrAddr + 0x04); /* reset ptr in vector table */
funcPtr usrMain = (funcPtr) jumpAddr;
/* tear down all the dfu related setup */
// disable usb interrupts, clear them, turn off usb, set the disc pin
// todo pick exactly what we want to do here, now its just a conservative
flashLock();
usbDsbISR();
nvicDisableInterrupts();
setPin(GPIOC, 12); // disconnect usb from host. todo, macroize pin
systemReset(); // resets clocks and periphs, not core regs
__MSR_MSP(*(vu32 *) usrAddr); /* set the users stack ptr */
usrMain(); /* go! */
}
I’ve attached the Windows usb reset exe’s
There is a 32 bit and a 64 bit version, i.e one with x64 at the end is the 64 bit one
See my other posting, but basically, if you modify your upload script so that you run devcon.exe after its complete, you and tell Windows to restart a USB device.
I’m cheating a bit and just saying restart all leadlab’s ID’s in the code below, because it was easier and I couldn’t quite work out the syntax for resetting an individual device
e.g.
devconX64.exe restart *1eaf*
Once I get the bootloader to work properly in the RET board, I’ll let you know if it re-enumerates when jumping to the sketch.
Regarding the RET bootloader, I think is mostly the same as the Maple Native bootloader, so if I get it work for one, should work for the other.
The main differences are all in the define lines (flash size, page size, LED pin number and port, etc) so I feel we should be able to have them all in a single repo, and just have all the options in the config.h file like you were doing with the maple and maple mini.
I have set the wait time in the bootloader a bit longer to give more time to Windows and the DFU tool to detect it.
I started with leaflabs RET6 bootloader, then applied all the updates and optimizations that had been applied up to the code Roger added to have uploads with ID2.
I am pretty sure we can uncomment upload to RAM if needed. In these type of boards that may actually be useful, but before touching more, I am uploading it to a new repo in my github.
Once tested and confirmed all good, I think we should merge with Roger’s mini bootloader, because the differences are really small:
-pin numbers for the led
-a bit of code to cause the re-enumeration with PA12
-does not check for a button cause there is no button on this board
-and page size of 2KB which is already set with a DEFINE line, so easy to make it conditional
If anyone wants to use it and have trouble let me know.
Firstr I want to say thank you for all the hard work on the STM32F devices… I have been using your Arduino IDE shortly with STM32F103ZET6 clone but don’t like this IDE. So I am using either Eclipse or CoIDE now for development.
I own this clone from G&C supermarket: http://www.ebay.com/itm/1pcs-STM32F103Z … 1305557264) for which /i would like to build the generic bootloader (LED on PG15)
I am using CoIDE (with arm-none-eabi-gcc-4.9.3) at the moment and getting a link error which I cannot solve, I hope you can give me some pointers on how to solve this link error:
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\stm32_lib/c_only_startup.s:108: multiple definition of `Default_Handler’I commented out all the non applicable configurations in the Makefile and did a #define generic-pg15 in config.h
Here is the complete output of CoIDE (link error is @ the end):
GCC HOME: C:\Localdata\Eclipse_C++\GCC_arm_eabi\bin
compile:
[mkdir] Skipping C:\Users\dlankvel\CoIDE\workspace\STM32duino\stm32duino\Debug\bin because it already exists.
[mkdir] Skipping C:\Users\dlankvel\CoIDE\workspace\STM32duino\stm32duino\Debug\obj because it already exists.
[cc] 14 total files to be compiled.
[cc] arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -g2 -Wall -O0 -c -DSTM32F103ZET6 -IC:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master -IC:\Users\dlankvel\CoIDE\workspace -IC:\Users\dlankvel\CoIDE\workspace\STM32duino -IC:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1 -IC:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\stm32_lib -IC:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_core.c C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_int.c C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.c C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\dfu.c C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\stm32_lib\c_only_startup_user.s C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_init.c C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\main.c C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb.c C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\hardware.c C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_callbacks.c C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_descriptor.c C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\stm32_lib\c_only_startup.s C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\stm32_lib\cortexm3_macro.s C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_mem.c
[cc] In file included from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_lib.h:22:0,
[cc] from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_core.c:17:
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_core.c: In function ‘SetDeviceAddress’:
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.h:380:26: warning: suggest parentheses around arithmetic in operand of ‘|’ [-Wparentheses]
[cc] _GetENDPOINT(bEpNum) & EPREG_MASK | bAddr)
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.h:204:10: note: in definition of macro ‘_SetENDPOINT’
[cc] (u16)wRegValue)
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_core.c:997:5: note: in expansion of macro ‘_SetEPAddress’
[cc] _SetEPAddress((u8)i, (u8)i);
[cc] ^
[cc] In file included from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_lib.h:22:0,
[cc] from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.c:17:
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.c: In function ‘ToggleDTOG_RX’:
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.h:356:70: warning: suggest parentheses around arithmetic in operand of ‘|’ [-Wparentheses]
[cc] EP_DTOG_RX | _GetENDPOINT(bEpNum) & EPREG_MASK))
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.h:204:10: note: in definition of macro ‘_SetENDPOINT’
[cc] (u16)wRegValue)
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.c:401:3: note: in expansion of macro ‘_ToggleDTOG_RX’
[cc] _ToggleDTOG_RX(bEpNum);
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.c: In function ‘ToggleDTOG_TX’:
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.h:358:70: warning: suggest parentheses around arithmetic in operand of ‘|’ [-Wparentheses]
[cc] EP_DTOG_TX | _GetENDPOINT(bEpNum) & EPREG_MASK))
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.h:204:10: note: in definition of macro ‘_SetENDPOINT’
[cc] (u16)wRegValue)
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.c:412:3: note: in expansion of macro ‘_ToggleDTOG_TX’
[cc] _ToggleDTOG_TX(bEpNum);
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.c: In function ‘ClearDTOG_RX’:
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.h:356:70: warning: suggest parentheses around arithmetic in operand of ‘|’ [-Wparentheses]
[cc] EP_DTOG_RX | _GetENDPOINT(bEpNum) & EPREG_MASK))
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.h:204:10: note: in definition of macro ‘_SetENDPOINT’
[cc] (u16)wRegValue)
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.h:368:5: note: in expansion of macro ‘_ToggleDTOG_RX’
[cc] _ToggleDTOG_RX(bEpNum)
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.c:423:3: note: in expansion of macro ‘_ClearDTOG_RX’
[cc] _ClearDTOG_RX(bEpNum);
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.c: In function ‘ClearDTOG_TX’:
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.h:358:70: warning: suggest parentheses around arithmetic in operand of ‘|’ [-Wparentheses]
[cc] EP_DTOG_TX | _GetENDPOINT(bEpNum) & EPREG_MASK))
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.h:204:10: note: in definition of macro ‘_SetENDPOINT’
[cc] (u16)wRegValue)
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.h:370:5: note: in expansion of macro ‘_ToggleDTOG_TX’
[cc] _ToggleDTOG_TX(bEpNum)
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.c:434:3: note: in expansion of macro ‘_ClearDTOG_TX’
[cc] _ClearDTOG_TX(bEpNum);
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.c: In function ‘SetEPAddress’:
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.h:380:26: warning: suggest parentheses around arithmetic in operand of ‘|’ [-Wparentheses]
[cc] _GetENDPOINT(bEpNum) & EPREG_MASK | bAddr)
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.h:204:10: note: in definition of macro ‘_SetENDPOINT’
[cc] (u16)wRegValue)
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.c:446:3: note: in expansion of macro ‘_SetEPAddress’
[cc] _SetEPAddress(bEpNum, bAddr);
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.c: In function ‘FreeUserBuffer’:
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.h:358:70: warning: suggest parentheses around arithmetic in operand of ‘|’ [-Wparentheses]
[cc] ^
[cc] EP_DTOG_TX | _GetENDPOINT(bEpNum) & EPREG_MASK))
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.h:204:10: note: in definition of macro ‘_SetENDPOINT’
[cc] (u16)wRegValue)
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.c:711:5: note: in expansion of macro ‘_ToggleDTOG_TX’
[cc] _ToggleDTOG_TX(bEpNum);
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.h:356:70: warning: suggest parentheses around arithmetic in operand of ‘|’ [-Wparentheses]
[cc] EP_DTOG_RX | _GetENDPOINT(bEpNum) & EPREG_MASK))
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.h:204:10: note: in definition of macro ‘_SetENDPOINT’
[cc] (u16)wRegValue)
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib\usb_regs.c:715:5: note: in expansion of macro ‘_ToggleDTOG_RX’
[cc] _ToggleDTOG_RX(bEpNum);
[cc] ^
[cc] In file included from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\common.h:36:0,
[cc] from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\hardware.h:30,
[cc] from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\dfu.c:33:
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\config.h:86:16: warning: missing whitespace after the macro name
[cc] #define generic-pg15
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\dfu.c: In function ‘dfuCopyState’:
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\dfu.c:374:9: warning: return discards ‘volatile’ qualifier from pointer target type
[cc] return (&(dfuAppStatus.bState));
[cc] ^
[cc] In file included from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\common.h:36:0,
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\config.h:86:16: warning: missing whitespace after the macro name
[cc] from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\main.c:34:
[cc] #define generic-pg15
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\main.c: In function ‘main’:
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\main.c:51:2: warning: implicit declaration of function ‘readButtonState’ [-Wimplicit-function-declaration]
[cc] bool no_user_jump = (!checkUserCode(USER_CODE_FLASH0X8005000) && !checkUserCode(USER_CODE_FLASH0X8002000)) || readButtonState() ;
[cc] ^
[cc] In file included from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\common.h:36:0,
[cc] from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb.h:27,
[cc] from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb.c:33:
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\config.h:86:16: warning: missing whitespace after the macro name
[cc] #define generic-pg15
[cc] ^
[cc] In file included from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\common.h:36:0,
[cc] from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\hardware.h:30,
[cc] from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\hardware.c:33:
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\config.h:86:16: warning: missing whitespace after the macro name
[cc] #define generic-pg15
[cc] ^
[cc] In file included from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\common.h:36:0,
[cc] from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_descriptor.h:28,
[cc] from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_descriptor.c:35:
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\config.h:86:16: warning: missing whitespace after the macro name
[cc] #define generic-pg15
[cc] ^
[cc] In file included from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib/usb_lib.h:21:0,
[cc] from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb.h:28,
[cc] from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\common.h:40,
[cc] from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_descriptor.h:28,
[cc] from C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_descriptor.c:35:
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_lib/usb_type.h:23:14: warning: initialization makes integer from pointer without a cast
[cc] #define NULL ((void *)0)
[cc] ^
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\usb_descriptor.c:201:28: note: in expansion of macro ‘NULL’
[cc] u8 u8_usbStringInterface = NULL;
[cc] ^
[cc] 0 total files to be compiled.
[cc] Starting link
[cc] arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -g2 -Wl,-Map=STM32duino.map -O0 -Wl,–gc-sections -LC:\Users\dlankvel\AppData\Roaming\CooCox\CoIDE\configuration\ProgramData\STM32duino -Wl,-TC:\Users\dlankvel\AppData\Roaming\CooCox\CoIDE\configuration\ProgramData\STM32duino/arm-gcc-link.ld -g -o STM32duino.elf ..\obj\usb.o ..\obj\usb_regs.o ..\obj\cortexm3_macro.o ..\obj\c_only_startup_user.o ..\obj\usb_mem.o ..\obj\usb_init.o ..\obj\usb_int.o ..\obj\usb_descriptor.o ..\obj\usb_core.o ..\obj\usb_callbacks.o ..\obj\c_only_startup.o ..\obj\dfu.o ..\obj\hardware.o ..\obj\main.o
[cc] ..\obj\c_only_startup.o:(.isr_vector+0x0): multiple definition of `g_pfnVectors’
[cc] ..\obj\c_only_startup_user.o:(.isr_vector+0x0): first defined here
[cc] ..\obj\c_only_startup.o: In function `USBWakeUp_IRQHandler’:
[cc] C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\stm32_lib/c_only_startup.s:108: multiple definition of `Default_Handler’
[cc] ..\obj\c_only_startup_user.o:C:\Users\dlankvel\CoIDE\workspace\STM32duino-bootloader-master\STM32F1\stm32_lib/c_only_startup_user.s:109: first defined here
[cc] ..\obj\c_only_startup_user.o:(.isr_vector+0x0): undefined reference to `_estack’
[cc] ..\obj\c_only_startup_user.o:(.isr_vector+0x8): undefined reference to `_magicRate’
[cc] ..\obj\c_only_startup.o:(.isr_vector+0x0): undefined reference to `_estack’
[cc] collect2.exe: error: ld returned 1 exit status
BUILD FAILED
Total time: 3 seconds
Regards and thanks in advance.
The Repo contains contains loads of stuff, not just the core for the Stm32f103 but also for the F3 and F4 as well as the bootloader and also sources for all the tools that are used to upload
If you are just trying to build the bootloader, the make file works fine, ( at least on windows).
If you are not trying to build the bootloader, do not add bootloader files to your project.
I think various other people have used Eclipse to build the core and sketches e,g, Rick Kimball, you could try PMing him
However I’m afraid I can’t support the Eclipse as an IDE as the whole repo is only designed to work with the Arduino IDE
I am just trying to build the bootloader. I downloaded the zipfile from github with the sourcecode of the bootloader, created a new project in CoIDE and added all the files and directories from the zip manually. Then started the build and got the error…
I will give it a go in the STM32 Arduino IDE then, see if that works out for me…
Regards,
I am just trying to build the bootloader. I downloaded the zipfile from github with the sourcecode of the bootloader, created a new project in CoIDE and added all the files and directories from the zip manually. Then started the build and got the error…
I will give it a go in the STM32 Arduino IDE then, see if that works out for me…
Regards,
just use the files in separate stm32duino-bootloder repo, not the sub folder in the arduino_stm32 repo
The bootloader is built from a makefile, there are multiple build targets and multiple configurations
so if you want to build it using Eclipse, you will need to work out how to replicate what the make file does.
I dont use eclipse that often, so i suggest you post to an Eclipse related forum and ask them how to build a project that uses a makefile with multiple build targets
Check!! I could indeed build the bootloader with CLI without any problems
Thanks foor the help !
Regards,
So my main problem was the that CoIDE does not have the ability to the the build command manually like Eclipse..
Problem solved..
Thanks..
the default Makefile target may either do nothing, or build the Maple mini.
if you want to build another target, e.g. a board that doesnt have the Maple USB hardware, you may need to change something in your Eclipse project which has the same effect as specifying a build target when you run make from the command line
PC14 – PC15 are connected to RTC OSC, and I want to use RTC.
I tried to make generic-pc13 with changed button BANK to PORTB, and Button PIN to 9 (like Maple mini), but it doesn’t work. ( It looks like working, LED is Blinking, but PC cant to recognise USB device)
I have tried to make generic-pc13 with default settings (Button on PC14) and compare the result with bin file from /binares and my resulting .bin file was 20 Byte smaller… It Blinking the led, but DFU doesn’t work…
Could anybody make the bootloader for PC13_BUTTON_PB9?
#elif defined TARGET_GENERIC_F103_PC13_BUTTON_PB9
#define LED_BANK GPIOC
#define LED_PIN 13
#define LED_ON_STATE 0
// Button (if you have one)
#define BUTTON_BANK GPIOB
#define BUTTON_PIN 9
#define BUTTON_PRESSED_STATE 1
I’m happy, it’s working perfect!!!
Im not sure what you mean about binutils but as long as you have fixed the problem, i guess its fine.
Im not sure what you mean about binutils but as long as you have fixed the problem, i guess its fine.
binutils 2.25-5 i386 GNU assembler, linker and binary utilities
binutils-avr 2.24+Atmel3.4.4-1 i386 Binary utilities supporting Atmel's AVR targets
binutils-multiarch 2.25-5 i386 Binary utilities that support multi-arch targets
I’ve only ever built the bootloader on Windows, and have not had any issues.
I just put the Arduino GCC Arm compiler in my PATH and everything seemed to work OK.
i think it was windows and eclipse/gdb/openocd tutorial related.
srp
Im not sure what you mean about binutils but as long as you have fixed the problem, i guess its fine.
affect a stm32f1 target?
i’m an idiot, elf to bin convert?
stephen
I just was looking for the depends, and first I tried “sudo apt-get install binutils”.
So it helped.
Maybe this one:
binutils-arm-none-eabi
GNU assembler, linker and binary utilities for ARM Cortex-A/R/M processors
stephen
Recompiling the blue pill PC13 one results in an image that when flashed looks OK to the point where it does the fast-flash sequence on reset but never correctly enumerates on USB. (The board has of course had its resistor value modified already)
I’m using the standard Xenial arm-none-eabi crosscompile toolchain.
The never versions e.g. 5.x have much harsher code optimisation as standard and the code does not run.
See the readme in github
Edit: Blackpill works:
#elif defined TARGET_GENERIC_F103_PB12
// Blackpill
#define LED_BANK GPIOB
#define LED_PIN 12
#define LED_ON_STATE 0
Keeping multiple hand-rolled toolchains around is a pain to maintain, and 4.8 is already unmaintained upstream.
I just don’t have time to do this at the moment, especially as there is no pressing need to do this, unless its impossible to download gcc 4.8.3 (which I think will be available for a few years yet)
-O2 with 4.9.3 doesnt work
It does initially enumerate as a LibUSB device, but it wont upload.
If I reset it just as the IDE is about to upload, then it does upload, but doesn’r seem to jump to the sketch code
Also, the code size using -O2 is 500 bytes more. This would be OK if it works, as we have almost 1k free, but since it doesnt work, there is no point in using this option, and the code really needs to be debugged to find the issue (probably vars or registers need to be as volatile
Would it be possible to compile the “usb_lib” sources into a LIB with 4.8.3 and then use this pre-compiled lib with the other sources to generate a new bootloader code with 4.9.x (or newer)?
This way one could determine whether the new compiler caused bug is in the LIB or other code parts.
P.S. Now that I was lately involved in the usb core related issue, I can see a couple of places where one could optimize/improve the code.
Really, the solution is just to fix the bug.
BTW.
As 4.9.3 breaks the bootloader, I suspect it cold break a lot if other code, e.g. sketches and possibly parts of the Core etc
I tried upgrading my main Arduino compiler to 5.x ( as part of some nRF51 stuff I was doing) but I recall the core would not even compile.
I suspect Arduino.cc would possibly have similar problems with their Arduino ARM boards, so they may not want to update the compiler either
The LibUSB that the bootloader uses, is dated 2008.
I know there are more recent versions of this, which may have bug fixes, but I’ve not found a complete set of libusb files for the STM32F103
Perhaps someone knows where there is a copy of the files that I could download and try ?
I don’t know how complete it is.
EDIT
I also found here FS device lib 4.0.0 which is the closest to the bootloader core files. I did a quick compare, beside typedefs there are minor changes, which I don’t know how they can influence the functionality.
And, btw, they still don’t have the little endian stuff in their code, dated January 2013.
However the new code seems to have a delay between upload and jumping to the user code which I wasnt originally aware of, so still needs some slight modificaton
BTW.
Can anyone remember who wrote a modified version of the bootloader which used NVRAM to determine whether the bootloader was being started in response to an upload command from the IDE or booted from cold ?
I think it would be good to implement this change into the bootloader, but I can’t remember who wrote it (I’ll check the forks in case someone forked and modified it)
https://github.com/j1rie/maple-bootload … 416dd0e0d6
