Pinout used by co-processor flashing project


I work with balenaFin to deploy a lorawan gateway. To do that I use RAK2245 like concentrator ( RAK2245 Pi HAT WisLink LPWAN Concentrator Datasheet | RAKwireless Documentation Center ) .

Recently, I want to use the coprocessor to allows to enter in sleeping mode. I use this project to communicate with co-processor GitHub - balena-io/balena-fin-firmata-flash: BalenaFin application to flash the on-board co-processor with the latest version of balenaFin Firmata.

During co-processor flashing operation, I am getting error with my gateway. I think there is a gpio manipulation during flashing and the RAK2245 can’t communicate with CM3 via SPI. On the readme project, we need to enable uart (GPIO 32 and GPIO 33). On balenaFIn schematic, I see there is GPIO41 to select SW or UART of MCU.
In the balena-fin-firmata-flash project, I see in openocd configuration file , there is pin set for jtag protocol. JTAG pins are the same pins used for SPI communication (GPIO 9, 10 and 11)

Once co-processor is flashed, all service work correctly.

Do you know if JTAG pins are used during co-processor flashing process ? How can I do to ensure SPI communication during co-processor flashing stage?


Hi Benjamin,

I have reached out to one of the Fin team to come and take a look at your questions.

In the meantime, it might be some help if I direct you to our post about balenaBlocks: Introducing balenaBlocks: jumpstart your IoT app development
and specifically our finabler block: GitHub - balenablocks/finabler: A block for balenaFin devices, handling coprocessor firmware flashing and operations, and exposing helpful balenaCloud tags

If nothing else, you’ll have something to read while you wait for the Fin team to reply with something more helpful. :wink:


Hello @benat

I have a few questions that might help us narrow down the problem here:

  • When you say you’re using a “RAK2245 like” concentrator, does that mean that it’s that exact one or a similar module? I’m trying to understand if we can assume that the documentation of the RAK2245 fully applies to the module you’re using.
  • What is the error that you’re getting on your gateway?
  • When you send the instruction to the co-processor to enter sleep-mode, do you see the same error on your gateway?

You also need to keep in mind that right after flashing the co-processor, the balenaFin will reboot. That’s required for the serial interface between the co-processor and the compute module to work after flashing.


Hey @ntzovanis

Yes in my case I am using the RAK2245 as lorawan gateway module.
I have a packet forwarder service deployed, this service is in charge of getting lorawan frame from gateway and redirect it to chirpstack server.

When the problem occurs, the gateway don’t exchange lorawan frames with the packet forwarder service. When i try to restart packet forwarder service, It can’t initialize communication with the gateway (via SPI).

The problem occurs only during a co-processor flashing process. I work around the problem in remove JTAG pins in openocd configuration file. ( finabler/balena-fin-v1.1.cfg at master · balenablocks/finabler · GitHub)
As co-processor uses only SWD protocol, flashing process works fine and I don’t loose lorawan frames.


Hey Benjamin - I’ve pinged the Fin team again to get their expert input. :slight_smile:


Hello @benat ,

Thanks for pointing this out. The JTAG pins shouldn’t be related to the co-processor flashing, but what you’re raising is interesting. One of my colleagues has a similar RAK module so we’ll try to reproduce this locally and find what the issue is. We’ll keep you updated.


Hello @benat ,

Just wanted to let you know that we’ve added the fix on the firmata flash repo that removes the JTAG pins from OpenOCD config.