My vote for the next version is the new STM32 with a radio. https://blog.st.com/best-goes-wireless-stm32wb/
I will try to put together an libopencm3 example for i2c. Also never forget pullup resistors, lot's of peripheral boards do not have the pullups on the board as they expect the host to have them. And the pins on 1bitsy are meant to be multipurpose so they do not presume that you use i2c on them and thus there are no pullups mounted. :D
On another note. An awesome project driven by 1Bitsy: https://github.com/dpiegdon/wurstradar
Sausage radar. Simple doppler radar that fits into a sausage can. Named after "Wurstblinker" from the german movie "Werner".
doh
If you're running Linux, have you plugged in the USB directly and run the "dmesg" command to see how or if the OS recognizes it? On Arch Linux the 'Product' field is 'STM32 BOOTLOADER', if you see something similar then your board isn't bricked and the problem is somewhere else. If you have a ST-Link programmer (or a Nucleo 64 or Nucleo 144 board that has one built in) you can try programming the 1bitsy using the SWD protocol (it uses different pins, the reference manual at st.com will tell you which pins to use)
Unless the board is physically damaged, I'm not sure if it's possible to brick the system loader installed on the factory by ST. The worst you can do (that I know of) is put it in lock level 3, which blocks SWD and JTAG access but leaves the board otherwise running. Most likely the board is booting to the program in flash memory instead of the system boot loader
Hi @bobbatcomcastdotnet a couple of things. First you should be using swdp_scan rather than jtag_scan to find the 1Bitsy, It is pretty hard to actually brick the device (it takes a weird hard to get into code protect mode that ST Micro has) but it is fairly easy to load a program that reconfigures the JTAG/SWD pins for I/O and that doesn't let the debugger in. You get around that by asserting reset while you attach. Something like mon attach_srst. That holds the chip in reset while the debugger attaches and then you can load new code rather than have the existing code run and disable the SWD pins.
Chuck, I set win10 to always use COM1 for the BMP and GDB recognizes the BMP okay (monitor version) returns the Black Magic version info. Since the 1Bitsy board has the JTAG connector wired directly to the STM32F415 JTAG pins I am somewhat confused about those pins being assigned to alternate functions?
It occurred to me that if this problem is due to the JTAG pins being preempted by the program in flash that I might be able to overcome it by placing a jumper on the DFU pads. This should force the boot loader into DFU mode and the flash program should never execute. This should allow the flash to be erased and then JTAG should work again. Any thoughts on this approach?
@bobbatcomcastdotnet What are the results of your tests? Did you try to put the 1bitsy into DFU mode? Did you try to use
mon srst enable setting? Usually you can not access the board due to code that is making it inaccessible. For example if you set your clock PLL settings so that the device is being heavily overclocked the device seems to be "bricked" but actually all you need to do is to power it on with reset held to prevent the pll from being configured.
another possibility is WFI commands of your code that put the device to a mode where the debug interface is ignored. You need to set special Debug bits to tell the STM32 to keep responding to debug commands even during WFI.
And of course, if you were playing around with the flash protection bits it is possible to lock the whole device into an unrecoverable mode. But doing it completely accidentally while you are not setting the magic registers to unlock the settings is rather rare.
And if you have negative 3.3v possible somewhere in the setup you have you could have fried the GPIO but that is pretty rare.
@bobbatcomcastdotnet let me know if that helps.
yeah I was wrong the command is actually
monitor connect_srst enable which is mon connect enable in short.
You don't technically "need" to solder the DFU pads, you just need to short the connection for a moment right as you plug in the USB cable. You can jab some copper onto the pads, it's imprecise and hacked but it worked for me after a few tries. I can't say for sure what Windows will recognize the board as, but the Linux Kernel will recognize the MCU even in non DFU mode.
@esden You were absolutely correct :) Once I issued the 'mon connect enable' and 'mon jtag_scan' requests the board responded with the normal scan results including detection of the STM32F4xx device PID :+1: This resolves my immediate problem, Thank you very much guys...
I am using MSYS to (try) building libopencm3 for the 1Bitsy board. I get the following error:
c:/arm/gcc/bin/make --directory=lib/stm32/f4 SRCLIBDIR="c:/libopencm3/lib"
make[1]: Entering directory 'c:/libopencm3/lib/stm32/f4'
make[1]: No rule to make target '/usr/lib/gcc/arm-none-eabi/7.2.1/include/stdint.h', needed by 'adc.o'. Stop.
make[1]: Leaving directory 'c:/libopencm3/lib/stm32/f4'
make: [makefile:64: lib/stm32/f4] Error 2
Can anyone help in resolving this error?
Thanks
in this case I guess you have some .d files which refers to linux path, a git clean should solve this
So I just broke out the BlackMagic Probe (I was a patreon supporter) and am running into an odd issue. I can use it fine from Windows or Linux, but when I fire up
arm-none-eabi-gdb and enter target extended-remote /dev/tty.usbmodem7AB878B1 GDB simply hangs and never comes back. Any suggestions?
mac os x has "issues" with tty due to kernel cashing/non cashing
Thank you for your support. :D
also, hello
w
anyone tried nuttx on a 1bitsy? I built an image using the STMF4 discovery board description but after flashing it I can't attach the board via JTAG anymore..
(or SWDP)