(02-08-2020, 10:03 AM)jwhooper Wrote: Will the bootloader.hex need to be updated again, or can all the updates from this point install over BLE?
That is the plan, yes.
The goal is to have an updater image that can be downloaded instead of micropython.zip that will run a few consistency checks (checksums and battery levels) and then update the bootloader and softdevice. I haven't written the updater yet but I'm confident this approach will be possible.
However... that is only useful for replacing the wasp bootloader with a newer version of itself. If you want to run PineTime programs that either do not use a bootloader or rely on a different bootloader then you might have to use an SWD programmer to switch between them.
(02-08-2020, 10:03 AM)jwhooper Wrote: I have a borrowed ST-Link. I was planning on buying my own programmer, but all of this is looking a lot more difficult than I thought. I have done some ESP8266 or ESP32 programming using Arduino IDE, but I've spent days just trying to get the tool chain to work, so I think the microcontroller OS level is not for me.
Don't be too discouraged. It is painful working on a dev kit intended for a "developer with extensive embedded OS experience and an interest in Smart Watch development" but there are also great learning opportunities! To be honest I found loading bootloader.hex to the PineTime to be the most difficult and frustrating part of the project so far (although getting the MicroPython REPL configured right came a close second).
PineTime is pretty new and currently the documentation and blog posts on compiler choice and SWD programming is either not beginner friendly (needs skill and experience to understand) or is heavily simplified (meaning it needs skill and experience to expand from the specific example provided to general principles). Information is starting to accumulate (at https://wiki.pine64.org/index.php/Reprog...e_PineTime ) but it still needs careful organising both to describe tasks not technology (unlock chip, program elf file, program hex file, debug with gdb) and to de-duplicate (openocd instructions are usually common regardless of the debug adapter used so distinguishing between RPi/ST-Link/CMSIS-DAP so it would better to have a single openocd chapter with sub-sections for the different adapters).
So I hope you keep going. If you do be aware that you cannot use ST-Link to remove the flash protection (I used black magic probe for this since I had one around but I think many others used the RPi). Once you have removed flash protection I'm pretty sure the instructions here worked for me: https://dev.to/aaronc81/flashing-your-pi...enocd-54dd . As I said I didn't keep good notes but that last program command should be able to cope equally well with raw binaries, elf files and hex files.
Update: Sorry... I got a bit muddled between forum and github threads. Reading back you've already got the STLink working I think? Does that mean you're currently in the "now what?" stage when you are presented with the pinecone (or time if you have updated to a later version) and aren't sure what you should do next?