Open karwosts opened 2 years ago
It's also the term used by nRF Connect for examples. I'm open to suggestions.
In this case, maybe the term "firmware samples" is best? (i.e., How to Build Firmware Samples, How to Flash Firmware Samples -- these seem like where I'd go if I wanted to know how to get the firmware compiled, and then put it onto the device)
Good idea. I had named them "firmware samples" in the main README. I will update the wiki too. Tks.
@1technophile Does this mean that the repo can be set up to have binary blob releases that are generated automatically? If so, maybe we should ask @rbaron to set that up to track updates to the main branch?
Yes the repo could be setup like this with binaries attached to releases
@drspangle appreciate the writeup! I've obtained a few bluepills since reading this and just wanted to add a note: I've so far bought 3 bluepills and all of them are unable to be flashed with the BMP firmware. I'm highly suspect that they might be clone chips read more here. Trying to confirm if this is actually the case and if I just have 3 bricked bluepills on hand.
Pretty close to just buying the BMP from Adafruit at this point! Either way, just wanted to make a note of that for any future tinkerers who come up against a similar issue.
Some notes on using BMP:
Back when I looked, official BMP hardware was unobtainium, but boards are available for purchase now. I just ordered one, and encourage everyone who can afford it to do the same.
For alternative BMP hardware, I strongly recommend the "Black Pill" board instead of Blue Pill. It's almost as cheap, but way more capable. I doesn't require another SWD programmer (like STLink), but can be flashed directly using the built-in bootloader via USB. https://github.com/blackmagic-debug/blackmagic/tree/main/src/platforms/blackpillv2
Now that firmware is ported to NRF Connect, use west flash -r blackmagicprobe --gdb-serial /dev/ttyBmpGdb
to flash it.
And finally, one cool feature of BMP is the RTT support, see this. If your blackmagic probe is built with ENABLE_RTT=1
, Zephyr logs are accessible if you do the following GDB sequence:
arm-none-eabi-gdb --batch \
-ex "target extended-remote /dev/ttyBmpGdb" \
-ex "monitor swdp_scan" \
-ex "attach 1" \
-ex "set confirm off" \
-ex "set mem inaccessible-by-default off" \
-ex "file build/zephyr/zephyr.hex" \
-ex "load" \
-ex "monitor rtt" \
-ex "run"
and in a second terminal, tio /dev/ttyBmpTarg
(or screen/minicom/yourserialtoolofchoice)
I am using OpenOCD and it works fine for flashing. However, I am not sure how can I do debugging ? Should I dedicate Serial/UART on the chip(solder some cables to it) and log the messages out there, or there is a way to do remote debugging. over OpenOCD. I am using OpenOCD on Raspberry PI.
Hey all, Looking for some help. I need to calibrate my boards to account for the coating as discussed in issue #79 , but I am running into the same issue as shown in #71 .
I have a bluepill flashed to BMP firmware compiled using drspangle's Dec 6th instructions. I successfully used it to flash the BLE firmware on the 4 boards. I used VS code to build samples then WSL and arm gdb to flash the boards.
Linux Battlestation 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
I pass through the bluepill from Windows 10 to WSL v2
Bus 001 Device 004: ID 1d50:6018 OpenMoko, Inc. Black Magic Debug Probe (Application)
Now that they are all flashed I cannot get arm gdb to recognize the boards. I have connected them the same way I did when I flashed them by using the battery then connecting clk, io and gnd from the bluepill to the pogo clip.
```
judson@Battlestation:/mnt/c/Users/Judson$ arm-none-eabi-gdb
GNU gdb (GNU Arm Embedded Toolchain 10.3-2021.10) 10.2.90.20210621-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
I have also tried letting the bluepill and a stand alone bench power supply power up the boards and I get the same error in gdb. I can also still see the boards reporting info to home assistant so they are powered on and functioning.
I have tried to use nrfjprog in Windows 10, but it does not recognize the bluepill as a programmer.
``` nrfjprog --family NRF52 --recover ERROR: No debuggers were discovered. NOTE: For additional output, try running again with logging enabled (--log). NOTE: Any generated log error messages will be displayed. ```
Is there a connect under reset or something similar for reflashing the nrf52840? I really have no idea what I am doing haha I just follow the guides of smart people on here and google (which has failed me for this issue).
Looking into this as well i have an STM32F411E-DISCO which i believe should be compatible with BMP so that likely could be used (untested). But further to that the board also includes a built in ST-LINK/V2 with SWD headers.
Looks like the ST-LINK can be flashed with J-Link OB.
https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/
Hoping to give it a go when i can get the firmware side of things sorted out.
I don't know if I'm too late to the party, but I've successfully flashed my parasites using a raspberry pi 4, pretty much exactly following this tutorial. I needed to make some changes to make it work with the pi4, and I'd be up for writing a wikipage if that makes sense for @rbaron as I can imagine that many people have a raspberry pi laying around, possibly also since HomeAssistant is one use case for the parasite.
To also chime in on the programming debate: I have gotten it to work with a cheap buspirate (hw v3.6, fw 6.11) and OpenOCD (0.12 with buspirate support). I could brew up a little written instruction if anybody is interested.
I just came across the nrfmicro wiki. It's a pretty great summary of using different methods of flashing, including using J-Link, ST-Link, Raspberry Pi or an STM32 board. I added a link to it to our wiki.
Hi, just wanted to say I love the idea behind this project, and hope to someday obtain some of these for myself.
I wanted to know if you've ever explored any alternatives to jlink debuggers for programming? Given that these devices aren't really available for sale anywhere (cheaply), if we're expecting everyone to fabricate their own devices, obtaining the debugger is a pretty high hurdle to clear.
The suggested devices seem to be essentially sold out everywhere, what ones available on ebay look to be $50, and they also come with the annoying EDU restriction that sounds like it makes it essentially illegal to turn around and sell any products you make from it.
Given that most end users don't really need "debugging" since we aren't developing the firmware, we just need a way to bit-bang in the boot code. Are there other devices or techniques that could achieve this? I see some cheap ARM debuggers on Ali for ~$8 shipped, any idea if something like those work? Is there any way to just bit-bang the interface with a RPI or ESP32 gpio?
Just wondering if you've ever thought about this, to drive more adoption of this project. For a typical user who might like a handful of these devices (~5?), once you have to acquire your own expensive debugger, it probably becomes cheaper to just buy some MiFlora or something rather than spending the expense to make your own.
Thanks!