hi peter, et al,
i managed to find a variant of libopencm3 which has usb support for the stm32f072, i compiled the cdcacm example and it worked. i will write up some notes later but here's a start:
https://github.com/kuldeepdhaka/libopencm3/tree/usb-rewrite https://github.com/kuldeepdhaka/libopencm3-examples/tree/usb-rewrite http://hands.com/~lkcl/usb_req_done.patch
peter i sent phil the ssh key, please do consider joining the mailing list so that things can be coordinated without cc.
the above branch is... well... it's literally one of the first times that libopencm3 has run usb code on an stm32f072 nucleo board. it means that certain things aren't going to be there. with two of us, peter, doing testing and development, the libopencm3 team on irc.freenode.net will have the encouragement they need to move things forward: we are, however, going to have to help them out, they're pretty busy.
the similarity to the stm32f1 series is sufficiently strong that i have confidence in their work, which means we can both press ahead with firmware development whilst the usb code is moved mainline and stabilised with unit testing.
l.
hi peter, et al,
i managed to find a variant of libopencm3 which has usb support for the stm32f072, i compiled the cdcacm example and it worked. i will write up some notes later but here's a start:
https://github.com/kuldeepdhaka/libopencm3/tree/usb-rewrite https://github.com/kuldeepdhaka/libopencm3-examples/tree/usb-rewrite http://hands.com/~lkcl/usb_req_done.patch
peter i sent phil the ssh key, please do consider joining the mailing list so that things can be coordinated without cc.
the above branch is... well... it's literally one of the first times that libopencm3 has run usb code on an stm32f072 nucleo board. it means that certain things aren't going to be there. with two of us, peter, doing testing and development, the libopencm3 team on irc.freenode.net will have the encouragement they need to move things forward: we are, however, going to have to help them out, they're pretty busy.
the similarity to the stm32f1 series is sufficiently strong that i have confidence in their work, which means we can both press ahead with firmware development whilst the usb code is moved mainline and stabilised with unit testing.
l.
hi,
my new nucleo board arrived this week (yeah!) and I will now setup my dev environment and see if I can get the code running. Is there any specific thing I could test?
Best, Peter
On Sat, Oct 10, 2015 at 5:09 PM, Peter Bouda pbouda@cidles.eu wrote:
hi,
my new nucleo board arrived this week (yeah!) and I will now setup my dev environment
you don't need that patch btw. and apparently there's now usb support in the main branch for stm32f072
and see if I can get the code running. Is there any specific thing I could test?
the main thing is to get the miniblink example up and running, first. i use dfu-util with the following in the Makefile:
BINARY = usbhid
dfu: dfu-util -v -S FFFFFFFEFFFF -a 0 --dfuse-address 0x08000000 -R -D ./$(BINARY).bin
keep the little piece of card, you need it! it has the pin-out assignments. so forget powering by the micro-usb, do this:
* flip the jumper from E5V to U5V * cut off a random USB cable and strip down the black, red, white and green * solder 5V (Red) to pin 6 of CN7 * solder GND (black) to pin 8 of CN7 * solder USB+ (green) to pin 12 (PA12) of CN10 * solder USB- (white) to pin 14 (PA11) of CN10
then, plug it into a USB port of the development machine. then, use a screwdriver to short BOOT0 (pin 7 of CN7) to E5V (pin 6 of CN7), and at the same time press and then release the reset button (B2).
if you then do "lsusb" you should see a device come up "DFU mode" in the description. ta-daa, you can now upload a .bin file to it. you do that with any of the libopencm3-examples, you must do "make bin".
you don't need to modify any of kuldeep's examples, he's made a suitable stm32f072-discovery.ld file, so you might prefer initially to use kuldeep's branch.
l.
keep the little piece of card, you need it! it has the pin-out assignments. so forget powering by the micro-usb, do this:
- flip the jumper from E5V to U5V
- cut off a random USB cable and strip down the black, red, white and green
- solder 5V (Red) to pin 6 of CN7
- solder GND (black) to pin 8 of CN7
- solder USB+ (green) to pin 12 (PA12) of CN10
- solder USB- (white) to pin 14 (PA11) of CN10
then, plug it into a USB port of the development machine. then, use a screwdriver to short BOOT0 (pin 7 of CN7) to E5V (pin 6 of CN7), and at the same time press and then release the reset button (B2).
if you then do "lsusb" you should see a device come up "DFU mode" in the description. ta-daa, you can now upload a .bin file to it. you do that with any of the libopencm3-examples, you must do "make bin".
hm, that did not work, unfortunately, I cannot get into the DFU mode somehow. It will just start into the mode that is described in the Quick start section of the manual. I found some forum posts where people suggest to solder resistors to PA11 and PA12... but that should not alter the start mode, right? Any ideas what I could have done wrong?
Best, Peter
On Fri, Oct 16, 2015 at 4:41 PM, Peter Bouda peter@ubrew.it wrote:
keep the little piece of card, you need it! it has the pin-out assignments. so forget powering by the micro-usb, do this:
- flip the jumper from E5V to U5V
- cut off a random USB cable and strip down the black, red, white and
green
- solder 5V (Red) to pin 6 of CN7
- solder GND (black) to pin 8 of CN7
- solder USB+ (green) to pin 12 (PA12) of CN10
- solder USB- (white) to pin 14 (PA11) of CN10
then, plug it into a USB port of the development machine. then, use a screwdriver to short BOOT0 (pin 7 of CN7) to E5V (pin 6 of CN7), and at the same time press and then release the reset button (B2).
if you then do "lsusb" you should see a device come up "DFU mode" in the description. ta-daa, you can now upload a .bin file to it. you do that with any of the libopencm3-examples, you must do "make bin".
hm, that did not work, unfortunately, I cannot get into the DFU mode somehow. It will just start into the mode that is described in the Quick start section of the manual. I found some forum posts where people suggest to solder resistors to PA11 and PA12... but that should not alter the start mode, right?
that's for very older STM32F devices, where they did not have the resistors built-in. occasionally you might need 22R resistors to stop signals bouncing back-and-forth with incorrect impedance, but you shouldn't.
Any ideas what I could have done wrong?
it's not amazingly hard, this, there's not actually a lot to do, so the number of things wrong will be very small.
can you take a picture and make it available online, also compare against the photo here: http://rhombus-tech.net/community_ideas/laptop_15in/news/PCB2_prototype_prog...
btw if you haven't re-flashed the firmware at all, then by default it will come up with LD2 blinking happily. check first that that's what happens by returning the U5V jumper and plugging in a mini-usb cable.
btw you should *NOT* plug in a mini-usb cable at the same time as the USB cable across PA12 and PA11!
also make sure BOOT0 is shorted to E5V *before* pressing reset, then hold reset for at least 0.5 seconds, *then* release reset, then release BOOT0 screwdriver-short.
l.
btw if you haven't re-flashed the firmware at all, then by default it will come up with LD2 blinking happily. check first that that's what happens by returning the U5V jumper and plugging in a mini-usb cable.
Yes, that's what's happening. Maybe I missed sth, do I have to reflash before I do anything else?
Best, Peter
Any ideas what I could have done wrong?
it's not amazingly hard, this, there's not actually a lot to do, so the number of things wrong will be very small.
can you take a picture and make it available online, also compare against the photo here: http://rhombus-tech.net/community_ideas/laptop_15in/news/PCB2_prototype_prog...
btw if you haven't re-flashed the firmware at all, then by default it will come up with LD2 blinking happily. check first that that's what happens by returning the U5V jumper and plugging in a mini-usb cable.
btw you should *NOT* plug in a mini-usb cable at the same time as the USB cable across PA12 and PA11!
also make sure BOOT0 is shorted to E5V *before* pressing reset, then hold reset for at least 0.5 seconds, *then* release reset, then release BOOT0 screwdriver-short.
hey, I got it finally. I think I made something wrong with the screwdriver (noob!), but after some more attempts it worked and I got the miniblink working. I will go on with the usb-rewrite stuff now, and see how it works.
Peter
On Sun, Oct 18, 2015 at 12:13 PM, Peter Bouda peter@ubrew.it wrote:
Any ideas what I could have done wrong?
it's not amazingly hard, this, there's not actually a lot to do, so the number of things wrong will be very small.
can you take a picture and make it available online, also compare against the photo here:
http://rhombus-tech.net/community_ideas/laptop_15in/news/PCB2_prototype_prog...
btw if you haven't re-flashed the firmware at all, then by default it will come up with LD2 blinking happily. check first that that's what happens by returning the U5V jumper and plugging in a mini-usb cable.
btw you should *NOT* plug in a mini-usb cable at the same time as the USB cable across PA12 and PA11!
also make sure BOOT0 is shorted to E5V *before* pressing reset, then hold reset for at least 0.5 seconds, *then* release reset, then release BOOT0 screwdriver-short.
hey, I got it finally. I think I made something wrong with the screwdriver (noob!), but after some more attempts it worked and I got the miniblink working.
yaaaa sounds familiar :)
I will go on with the usb-rewrite stuff now, and see how it works.
you should actually be able to use libopencm3 master, now, because some usb commits for stm32f072 were made last week.
l.
arm-netbook@lists.phcomp.co.uk
-
Luke Kenneth Casson Leighton -
Peter Bouda -
Peter Bouda