I've just pushed some commits which add build targets for all 12 supported MCUs:
F302CB, F302CC, F302RB, F302RC, F302VB, F302VC,
F303CB, F303CC, F303RB, F303RC, F303VB, F303VC
For the discovery you'd use BOARD=F303VC
Those are general-purpose PIN_MAPs, where the pins are simply referred to by their names:
digitalWrite(PA1, HIGH);
toggleLED(PB13);
mk13
Member
My changes for stm32discovery beside the UART stuff I have uploaded to
https://dl.dropboxusercontent.com/u/58814222/stm32f3discovery_libmaple_changes.zip
Pin numbering follows roughly the pins at the left and right header of the board. It is recommended to use the Pxy notation as mentoned by ventosus already. A list of the already used pins of the board is included in board.h. No warranty for correct assignment of secondary pin functions - there might be still errors.
I'm building the lib+application with
>make BOARD=stm32f3discovery MEMORY_TARGET=jtag
=======================================================================
Build info:
BOARD: stm32f3discovery
MCU: STM32F303VC
MEMORY_TARGET: jtag
...
Is there a chance to get this running with the Maple-IDE/maple bootloader? I'm trying to prepare this stuff for usage in the robotic club at school and the kids are familiar with the Arduino-IDE already. So having the Maple-IDE as starting point would be nice. I know for more complex projects we have to go for other options since managing multi-file projects with Arduino is possible (at least with the actual versions > 1.0) but no fun.
gbulmer.
'feurig - "... until the orone_mini_f3 is more hammered out?"'
The "hammered out" has more to do with the fact that we haven't been able to make our f3 based orone boards work. Since other people have succeeded then it must be our fault.
Stay calm and carry on....
gbulmer
Moderator
feurig - "Too much solderpaste :("
Is their some thing I could do to improve the board layout?
Have you any photographs you would post to show where it happened?
As we all know, there are no problems, only opportunities :)
My chum Chris once joked, "in software, their are no bugs, only Known Recoding Opportunities (KROs)" :-)
So I guess, for PCBs, there are Known Routing Opportunities?-)
Currently having some include errors when compiling on windows, but I think that is because windows is being a moron. I'll have more cracks at it tomorrow. So far I've had to copy the STM32f1 USB files to the STM32F3 USB folder as the symbolic links didn't quite work as they should.
Oh and:
C:\Users\Crenn\Documents\GitHub\libmaple [F3 +0 ~4 -0]> cs-make BOARD=
F303CC
================================================================================Build info:
BOARD: F303CC
MCU: STM32F303CC
MEMORY_TARGET: flashSee 'make help' for all possible targets
================================================================================
[CC] ./libmaple/adc.c
[CC] ./libmaple/dac.c
[CC] ./libmaple/dma.c
[CC] ./libmaple/exti.c
[CC] ./libmaple/flash.c
[CC] ./libmaple/gpio.c
[CC] ./libmaple/iwdg.c
[CC] ./libmaple/nvic.c
[CC] ./libmaple/pwr.c
[CC] ./libmaple/rcc.c
[CC] ./libmaple/spi.c
[CC] ./libmaple/systick.c
[CC] ./libmaple/syscfg.c
[CC] ./libmaple/timer.c
[CC] ./libmaple/usart.c
[CC] ./libmaple/usart_private.c
[CC] ./libmaple/util.c
[CC] ./libmaple/i2c.c
[CC] ./libmaple/bkp.c
[AS] ./libmaple/exc.S
[CC] ./libmaple/usb/stm32f3/usb.c
[CC] ./libmaple/usb/stm32f3/usb_reg_map.c
[CC] ./libmaple/usb/stm32f3/usb_cdcacm.c
libmaple/usb/stm32f3/usb_cdcacm.c:64:2: warning: #warning USB CDC ACM relies on LeafLabs board-specific configuration. You may have problems on non-LeafLabs boards. [-Wcpp]
[CC] ./libmaple/usb/usb_lib/usb_core.c
[CC] ./libmaple/usb/usb_lib/usb_init.c
[CC] ./libmaple/usb/usb_lib/usb_mem.c
[CC] ./libmaple/usb/usb_lib/usb_regs.c
[AS] ./libmaple/stm32f3/30x/isrs.S
[AS] ./libmaple/stm32f3/30x/vector_table.S
[CC] ./libmaple/stm32f3/adc.c
[CC] ./libmaple/stm32f3/dma.c
[CC] ./libmaple/stm32f3/exti.c
[CC] ./libmaple/stm32f3/gpio.c
[CC] ./libmaple/stm32f3/i2c.c
[CC] ./libmaple/stm32f3/rcc.c
[CC] ./libmaple/stm32f3/spi.c
[CC] ./libmaple/stm32f3/timer.c
[CC] ./libmaple/stm32f3/usart.c
[CC] ./libmaple/stm32f3/syscfg.c
[CC] ./libmaple/stm32f3/fpu.c
[CC] ./libmaple/stm32f3/comp.c
[CC] ./libmaple/stm32f3/opamp.c
[CC] ./libmaple/stm32f3/bkp.c
[AS] ./wirish/start.S
[CC] ./wirish/start_c.c
[CC] ./wirish/syscalls.c
[CC] ./wirish/stm32f3/util_hooks.c
[CXX] ./wirish/boards.cpp
In file included from wirish/boards.cpp:48:0:
./wirish/include/wirish/boards.h:39:25: fatal error: board/board.h: No such file or directory
compilation terminated.
cs-make: *** [build/./wirish/boards.o] Error 1
Ah, I was not aware that symlinks in git would be troublesome on windows. I use them all the time.
I'll try to tweak the build system, so I can get rid of them without a need to duplicate all the forlders.
For the time being, there are more symlinks you'll have to take care of:
git ls-files -s | gawk '/120000/{print $4}
libmaple/usb/stm32f3/usb.c
libmaple/usb/stm32f3/usb_lib_globals.h
libmaple/usb/stm32f3/usb_reg_map.c
libmaple/usb/stm32f3/usb_reg_map.h
wirish/boards/F103CB
wirish/boards/F302CB
wirish/boards/F302CC
wirish/boards/F302RB
wirish/boards/F302RC
wirish/boards/F302VB
wirish/boards/F302VC
wirish/boards/F303CB
wirish/boards/F303CC
wirish/boards/F303RB
wirish/boards/F303RC
wirish/boards/F303VB
wirish/boards/F303VC
There are only two real board file directories: wirish/boards/F302xx and F303xx, all the subvariants (F303CB, F303CC, ...) are just symbolic links to the latter two.
So you'll also need to copy F303xx to F303CC (that's what the last error is about)
Have you written a F3 bootloader? If not, it makes little sense to build for MEMORY_TARGET=flash, you may want to use MEMORY_TARGET=jtag instead if you'll flash via the embedded DfuSe loader.
That's how I upload a built sketch to an orone mini F3:
Pull up USB_DP with 1.5k. If you happen to have a newer orone mini design, you can pull down DISC with a jumper near the transistor. I use an early orone mini version and just connect 1.5k from USB_DP to VCC. In the manual it says that you should also pull low or high USART1 and USART2 (to not start the serial bootloaders accidentally), but this is unnessary IMHO, as USB is exclusively checked for first.
To get into DfuSe bootloader mode, BUT button (boot0) needs to be pressed at boot.
If USB cable is already connect and/or board is powered otherwise:
- press BUT button
- press RESET button
- release RESET button
- release BUT button
If USB cable not yet connected
- press BUT button
- connect USB cable
- release BUT button
Now you should be in DfuSe bootloader mode (USB device should show up in your OS).
lsusb
Bus 003 Device 020: ID 0483:df11 STMicroelectronics STM Device in DFU ModeBus 003 Device 020: ID 0483:df11 STMicroelectronics STM Device in DFU Mode
If your on Linux, you may want to add a udev rule to have access rights as user of the right group (uucp in my case).
/etc/udev/rules.d/46-DfuSe.rules
----------------------------------------
ATTRS{idProduct}=="df11", ATTRS{idVendor}=="0483", MODE="664", GROUP="uucp", SYMLINK+="DfuSe"
I got this to work in windows 7, too, using http://zadig.akeo.ie/ to handle USB driver installation.
Upload your previously built binary with a recent version of dfu-util (e.g. 0.7). Only recent versions support DfuSe, which is an extension to the Dfu protocol by ST.
dfu-util -a 0 -d 0483:df11 -s 0x08000000:leave -D build/F303CC.bin
dfu-util needs an explicit target memory address your sketch is destined for to run in DfuSe mode.
The :leave hook triggers a jump to user code after flashing, without the :leave, the device will remain in bootoader mode.
I hope it helps
Definitely helped, just uploaded the example main.cpp sketch to both boards, although had to comment out the PWM stuff as that caused ASSERT to be called. I used a small (220 ohms) resistor on my Orone board's DISC pin, there is pictures of that mod here: http://forums.leaflabs.com/topic.php?id=10410&page=13#post-28861
Had to use the zadig driver tool to install different drivers, the default that windows install doesn't allow dfu-util to work. Also didn't have any more arguments than just:
dfu-util.exe -a 0 -D orone_mini_F3.bin
But telling it where to write is something I should have done.
Got to experiment a bit more before I can be certain everything is working as it should, I have noted that after leaving DFU mode, it seems the USB device doesn't re-enumerate. Plugging it in and out again will cause the Serial port to show up.
I'll write up a blog post hopefully today about the experience.
You must log in to post.
