Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Nov 06 2018 16:29
    esden commented #16
  • Nov 06 2018 16:28

    esden on master

    Fix formatting, typos, grammar … (compare)

  • Nov 06 2018 16:28
    esden closed #16
  • Nov 06 2018 03:42
    0xdec opened #16
  • Oct 21 2018 20:53
    Poofjunior opened #15
  • Oct 12 2018 05:48
    frankalicious closed #10
  • Aug 24 2018 22:49
    irandms opened #5
  • Aug 22 2018 11:38
    elektor-labs edited #14
  • Aug 22 2018 11:36
    elektor-labs opened #14
  • May 24 2018 12:17

    kbob on master

    Improve audio clock calculation. Experiment with different color… Added bit definitions for the g… and 1 more (compare)

  • Apr 23 2018 12:45
    RandoSY edited #13
  • Apr 23 2018 12:44
    RandoSY edited #13
  • Apr 23 2018 12:33
    RandoSY opened #13
  • Apr 01 2018 06:53

    esden on master

    Removed digital volume up/down … (compare)

  • Apr 01 2018 06:50

    esden on master

    Updated PKL. Added MEMS microphone input. (compare)

  • Apr 01 2018 00:16

    esden on master

    Added FPGA. (iCEBreaker circuit… (compare)

  • Mar 31 2018 06:35

    esden on master

    Added STM32 symbol library. Added 1Bytsy schematic to the 1… (compare)

  • Mar 31 2018 04:26

    esden on master

    Connected the audio sense signa… (compare)

  • Mar 29 2018 07:23
    esden closed #9
  • Mar 29 2018 07:23
    esden commented #9
Alexander Mathis
@xsi106_twitter
DIR seems to be always 0.. I have to sleep one night over it :-) thanks again for helping
Alexander Mathis
@xsi106_twitter
Found the my failure was looking at TIM2 Dir bit while using TIM4 for the encoder... lol
Paul Fernquist
@PaulF8080
My vote for the next version is the new STM32 with a radio. https://blog.st.com/best-goes-wireless-stm32wb/
DustinLehmann
@DustinLehmann
Hi, does anyone have a working example for I2C on the 1bitsy with the help of the StdPeripheral Library?
Piotr Esden-Tempski
@esden
I do not use the ST libraries much so I can't tell you. I did not test I2C in a while because I tend to avoid it. Would need to look into it.
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".
David R. Piegdon
@dpiegdon
\o/ yay
Piotr Esden-Tempski
@esden
Thanks for sharing! @dpiegdon :D
tulanthoar
@tulanthoar
Can anyone link to the datasheet for the 3V3 regulator; or the range of allowed input voltages works too. I'm mostly interested in the dropout voltage (assuming it's a linear regulator)
Mike Walters
@miek
/wg/wg 30
doh
bobbatcomcastdotnet
@bobbatcomcastdotnet
I seem to have bricked my 1bitsy board :( GDB reports no 'useable targets detected' when a scan the jag using a BMP. Any suggestions on how to recover?
tulanthoar
@tulanthoar
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
Chuck McManis
@ChuckM
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.
bobbatcomcastdotnet
@bobbatcomcastdotnet
Thanks for the replies :) Check, I agree that this probably a case of the JTAG/SWD I/O is somehow disabled. Using swdp_scan fails (jtag_scan use to work). I am running GDB under Win 10 not Linux.
Chuck McManis
@ChuckM
It doesn't matter what OS you use (although under windows it sometimes swaps the com ports so try the 'other' com port that appears just in case)
bobbatcomcastdotnet
@bobbatcomcastdotnet
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?
bobbatcomcastdotnet
@bobbatcomcastdotnet
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?
Piotr Esden-Tempski
@esden
@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.
bobbatcomcastdotnet
@bobbatcomcastdotnet
@esden I haven't been able to try DFU mode yet (requires soldering) :smile: I did try the 'mon srst enable' GDB command and GDB responded with "target does not support this command". I will be able to try the DFU by tomorrow and I'll report my findings here.
Piotr Esden-Tempski
@esden
@bobbatcomcastdotnet I might recall the command wrong: use monitor help to check
yeah I was wrong the command is actually monitor connect_srst enable which is mon connect enable in short.
tulanthoar
@tulanthoar
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.
bobbatcomcastdotnet
@bobbatcomcastdotnet
@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...
bobbatcomcastdotnet
@bobbatcomcastdotnet
bobbatcomcastdotnet
@bobbatcomcastdotnet

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

Nicolas Schodet
@schodet
did you use this directory from linux before?
in this case I guess you have some .d files which refers to linux path, a git clean should solve this
bobbatcomcastdotnet
@bobbatcomcastdotnet
@schodet Thanks for the suggestion. I deleted the .d files and the make worked without errors :smile:
Shaun
@aprgl
Any interest in starting a 1bitsy-wall-of-shame room for capturing magic smoke escape events? I've got a newly formed vent hole in my stm32...
bobbatcomcastdotnet
@bobbatcomcastdotnet
Has anyone adapted the FatFS SD disk firmware to run on the 1Bitsy?
Jock Murphy
@jockm
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?
Piotr Esden-Tempski
@esden
you have to use cu.usbmodemXXXX not tty.usbmodem
mac os x has "issues" with tty due to kernel cashing/non cashing
Jock Murphy
@jockm
DOH! Thank you very much
Piotr Esden-Tempski
@esden
No preblem! :)
Thank you for your support. :D
Daniel O'Connor
@DanielO
@esden BTW I think tty vs cu is that tty will wait for DTR or something - pretty sure it's a BSDism
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)
Daniel O'Connor
@DanielO
just realised I can recover via DFU mode.. would be nice to know if it should work tho :)