How do I get started programming the Pitaya Go?

[LeakyEarth2000]

How do I get started programming the Pitaya Go and to write Chris' code onto it?

[nitz]

If you've got a debugging probe/flash tool that is supported by pyOCD (Most CMSIS-DAP probes should work, I use the Pitaya-Link), you should be good to go.

You'll want to ensure you've got your pins connected to the Pitaya go on at least the first 5 pins of the right header (the side opposite the battery connector.) That would be the 3.3V pin (power supply), GND, /RESET, SWCLK and SWDIO. I've attached the pitaya go pinout to the end of this post for your reference!

You want to start flash the NRF's MBR first (a tiny binary blob provided by Nordic that supports the bootloader, etc.) You only need to flash it once, which you can do with make flash_mbr, or by using the command from the Makefile directly: here.

Then, it should be as simple as running make flash_all. That would build the bootloader, and main application firmware and flash it to the board!

A few references:

• The tasks.json that VSCode references for commands I use regularly when developing, mostly just shortcuts to different make targets.
• The main targets in Makefile referenced from the tasks.json, but to give you an idea of what to run if you wanted to run pyocd and the sort to flash manually without using make.

A side note:
If you wanted to use the 'end user' method of updating the application, you could do make flash_bootloader, which will just build and flash the bootloader portion, which would enable you to use the UF2 bootloader to update the application on the Pitaya Go via USB. If you choose to go this route of manually flashing the application separate from the bootloader, you'll need to poke a 1 value into a specific spot in the flash to tell the bootloader that the application is valid and it should try to run it. That is handled in the Makefile automatically here, but you can manually do so via: pyocd cmd -t nrf52840 --command write32 0xFF000 0x00000001 --command reset. Without this value set, the bootloader won't ever pass execution to the application.

Let me know if you run into any issues!

Pitaya Go pinout:

[LeakyEarth2000]

A hardware question too. Is it best to solder these female headers to the bridge or should I directly solder the LCD to it? It's currently being blocked by the SD card to be flat, so what do you propose? Should I just raise it half way then solder the pins? Like here:

[nitz]

Oh goodness, apologies I missed your earlier reply!

So I have installed the nRF5 command line tools and the ARM GNU Toolchain. But, I'm unsure what to do after. I am aware of a CMD prompt opening from ARM GNU Toolchain and my best guess is having to use this somehow.

Now you just need to edit the BuildSettings.mk file to have the correct directories to where your toolchain is installed.

Then, either from the command line while in the Odiin directory, you can run make flash_all. Or, if you've got the workspace open in VS Code, you can press CTRL+SHIFT+B to run the command that way.

Exactly, what would the output directory be and is the merged hex the same mbr.hex file?

Eventually it spits the resulting files out in a directory named _build. The final merged hex file will be named something like odiin-[git hash].hex (and odiin-[git hash].uf2 for flashing via the UF2 bootloader.)

How would the code in the command line be then for these lines? Do I have to do every line individually on the cmd or all together?

When you run make flash_all, it will run all of those in sequence. (After it finishes the merge target.)

Are these to be in the commanded in a standard CMD admin or to open up in ARM GNU Toolchain file location?

You shouldn't need to run as admin. As long as your GNU_INSTALL_ROOT and GNU_VERSION is set properly in BuildSettings.mk, it will invoke calls to the toolchain directly. The things you'll need on your path are make and pyocd. Perhaps some others I'm forgetting, but I know at least those two.

I don't want to accidentally screw anything up, and just would like to be sure.

Good news is that you basically can't screw anything up. Software can always be rebuilt and if the wrong thing gets flashed to the board, wiping it and flashing again is no problem.

A hardware question too. Is it best to solder these female headers to the bridge or should I directly solder the LCD to it? It's currently being blocked by the SD card to be flat, so what do you propose? Should I just raise it half way then solder the pins? Like here:

Headers are absolutely your call. I soldered the LCD directly to the bridge because I was trying to minimize height to fit in a printed case. As long as the SD Card slot isn't touching the solder joints below it, you're fine.

[LeakyEarth2000]

Oh goodness, apologies I missed your earlier reply!

Nah, no worries! Take your time to reply! We're in no rush :)

Then, either from the command line while in the Odiin directory, you can run make flash_all. Or, if you've got the workspace open in VS Code, you can press CTRL+SHIFT+B to run the command that way.

Sorry, I'm a little bit confused about make flash_all. Could you please send the whole command to type and execute whilst in the Odiin directory? That would be greatly appreciated. I would just CTRL + SHIFT + B in VSC, but when I do, it just says this and I really can't be bothered going back and forth to fix this.

make : The term 'make' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and 
try again.
At line:1 char:1
+ make release
+ ~~~~
    + CategoryInfo          : ObjectNotFound: (make:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Eventually it spits the resulting files out in a directory named _build. The final merged hex file will be named something like odiin-[git hash].hex (and odiin-[git hash].uf2 for flashing via the UF2 bootloader.)

With the hex file, what should I do with it? And with the uf2 file, what should I do afterwards with it, too? It would be amazing if you could list the commands to execute 1-by-1.

I also massively apologise for being such a burden

[LeakyEarth2000]

I understand you may be busy, but I was hoping you could take a moment to review this message when you have a chance. Thank you, Chris!

[nitz]

Apologies I did get busy with the holidays and my day job 😅

I also massively apologise for being such a burden

Not at all, we all get to learn new things every day!

Sorry, I'm a little bit confused about make flash_all. Could you please send the whole command to type and execute whilst in the Odiin directory? That would be greatly appreciated. I would just CTRL + SHIFT + B in VSC, but when I do, it just says this and I really can't be bothered going back and forth to fix this.

make flash_all is the whole command :) It runs the make utility with the flash_all target, which ends up running the whole slew of commands to get you there.

The error you're getting ('make' is not recognized...) just means you don't have the make` tool installed (or available via your system's PATH environment variable.) Try installing a pre-built copy of it from here: https://gnuwin32.sourceforge.net/downlinks/make.php, and then running the command. (You'll need to re-start your terminal or vscode as applications only see changes to environment variables on launch.)

make flash_all from the terminal (or CTRL+SHIFT+B in vscode should run all the commands you need. If you want to see what commands make would execute, run from the terminal: make --dry-run flash_all and it will show you what make runs for that target, like such:

Y:\workspace\Odiin>make --dry-run flash_all
echo DONE nrf52840_xxaa
echo Merging: _build/odiin-a2fcd1d.hex from application and UF2 bootloader.
mergehex -m _build/uf2_bootloader.hex _build/nrf52840_xxaa.hex -o _build/odiin-a2fcd1d.hex
echo Flashing: _build/odiin-a2fcd1d.hex
pyocd flash -t nrf52840 _build/odiin-a2fcd1d.hex
pyocd cmd -t nrf52840 --command write32 0xFF000 0x00000001 --command reset

Y:\workspace\Odiin>:: notice that --dry-run only shows the commands for the requested target in it's current state, so your output will be considerably longer as it will do all the targets it depends on, too

Let me know how you get on with that, and then we can turn back to the hex/uf2 file stuff.

[LeakyEarth2000]

Hey Chris! It's a been a very long time, but I am finally back to continue this project!

I have no idea what step I am up to, so I think it's best for me to reset my Pitaya Go. Problem is that none of the reset/user buttons actually work no longer. If I hold the user or reset button before plugging the power in, nothing happens! The green LED lights up, but no input. With my pitaya link, if I hold the only button (boot/reset) before plugging the power in directly to it, it will pop up a drive on my PC. with a firmware file. I tried putting it in DFU, but nothing happens. In fact, even if I plug in the pitaya go to my PC, my PC doesn't make that hardware connect sound and device manager doesn't acknowledge the device at all

As I said, I think it is best that I reset my Pitaya Go, but I have no idea how to now. I thought it would have been simple as holding the reset button down and plugging the USB C cable in! If you could guide me on what was the software needed in order to perform the reset, as well as the command to actually reset this thing, that would be greatly appreciated!

Cheers