## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
• 05:58

esden on master

Updated LOCM3. Improved the clean target. Ignore if st-link/dfu-util is n… and 9 more (compare)

• Aug 05 2020 21:27

0xdec on v2.0a

More WIP (compare)

• Jul 31 2020 21:36

0xdec on v2.0a

WIP migration + v2.0a (compare)

• 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

• Mar 31 2018 06:35

esden on master

Paul Fernquist
@PaulF8080
I haven't been here in awhile so I may be answering a very old post. Another way to look at a PLL is that it multiplies the slow frequency by dividing the VCO frequency with a counter. So I say multiply first and then divide with a counter and compare second. The problem is that the duty cycle isn't 50% so the counter /compare generates twice the wanted frequency and divides by two with a flip-flop to get 50%.
Anthony DiGirolamo
@AnthonyDiGirolamo
@PeterMortensen only other thing we should probably change is the available amount of RAM and Flash that forth sees. https://github.com/jeelabs/mecrisp-stellaris/blob/master/mecrisp-stellaris-source/stm32f411/mecrisp-stellaris-stm32f411.s#L49 I'm not sure where in the source this needs changing but I'll give it a shot later this week.
Peter Mortensen
@PeterMortensen
@AnthonyDiGirolamo Yes, and perhaps have an entry for STM32F415 created. I am not sure what the primary point of contact is. It may or may not be http://jeelabs.net/projects/cafe/boards/ (from From https://groups.google.com/forum/#!topic/comp.lang.forth/QIuNkMkCRvE, 2017-03-27: "Nowadays Mecrisp users meet at the Jeelabs forum: http://jeelabs.net/projects/cafe/boards/"). Possible ghost towns are https://groups.yahoo.com/neo/groups/MecrispForth/info and https://groups.io/g/mecrispforth.
Anthony DiGirolamo
@AnthonyDiGirolamo
@PeterMortensen I'm writing an email to the author Matthias Koch m-atthias@users.sf.net asking the best way to do it.
Peter Mortensen
@PeterMortensen
@AnthonyDiGirolamo I think it should be configured for external crystal 25 MHz and 168 MHz clock speed (as nominally in the 1Bitsy) and 115,200 baud rate - so it works out of the box on 1Bitsy with the generated hex file. In that case the UART divisor should be 1458 if configured similarly to STM32F407 (it is 70 for the STM32F407 with external 8 MHz crystal), but I could be wrong assuming the divisor is from the full system clock speed (it may instead be from the crystal frequency? - then it would be 217).
Peter Mortensen
@PeterMortensen
Peter Mortensen
@PeterMortensen
@AnthonyDiGirolamo With regard to peripherals / ports in https://github.com/AnthonyDiGirolamo/svd2forth-1bitsy/blob/master/template.xml I vote for "CAN1" and "CAN2" (and their dependencies, if any) to be included as that is where I am heading with all this (doing CAN bus stuff, including CANopen).
Anthony DiGirolamo
@AnthonyDiGirolamo
@PeterMortensen Everything in template.txt is already enabled and saved to https://github.com/AnthonyDiGirolamo/svd2forth-1bitsy/blob/master/m so you should be able to use CAN1 and CAN2 now
Peter Mortensen
@PeterMortensen
@AnthonyDiGirolamo Thanks. That will definitely speed things up.
Will
@wmarone
has anyone else encountered a lot of noise on the blackmagic probe uart when only the JTAG cable is plugged in?
Will
@wmarone
n/m, resolved it
Will
@wmarone
ahaha, oh serves me right for not updating my fork of 1bitsy-examples
figure out how to use tim2 to generate interrupts and blink the led, and there was exactly the same thing comitted back on nov. 30
John Whitmore
@johnfwhitmore
That sounds familiar, if so I'm stocked it was useful.
Alexander Mathis
I am newbie to 1bitsy and µC programming. I am playing around with the timer in encoder mode. How is it possible to check the DIR bit in the TIM2_CR1 register? I am using the standard 1bitsy toolchain with libopencm3. Thanks Alex
Chuck McManis
@ChuckM
@xsi106_twitter you mean like int dir = ((TIM2_CR1 & (1 << 0x4)) != 0); ?
Alexander Mathis
yes something like that
should this work
@ChuckM I tried something similar but had no luck. Thank you for your help.
Chuck McManis
@ChuckM
Generally the libopencm3 library is all about just accessing the registers directly.
Nicolas Schodet
@schodet
xsi106_twitter: do not forget to enable the module clock or else nothing will work (see rcc_periph_clock_enable)
Alexander Mathis
The problem is that i am more on the "arduino" level so i have to learn to use the registers.
encoder is already working only thing i could not figure out was requesting single bits from the register. The counter was easy to get because of the timer_get_counter function.
Will
@wmarone
@johnfwhitmore It was your demo I saw, but I saw it too late. I had everything ready to go for a PR when I saw yours 😅 Kinda shows it's a common curiosity.
John Whitmore
@johnfwhitmore
Great minds and all that. Must get back to 1BitSy, been distracted by work.
Alexander Mathis
DIR seems to be always 0.. I have to sleep one night over it :-) thanks again for helping
Alexander Mathis
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.