Porting to new LiFePO4wered/LoRa board

Hello everyone,

A while back I created an nRF52832 + E22 SX1262 board with on-board solar charging called the LiFePO4wered/LoRa:

The battery and charging system all works, that’s my special sauce and I’m more of a hardware guy. But when I tried to get any LoRaWAN software to run on it, I hit a brick wall. Many brick walls called Zephyr, Arduino, SX127x, RFM95, enough that I gave up on it. I can’t produce hardware without some known software support. And seriously, since I didn’t succeed in getting a single LoRa packet out of it, I can’t be certain it works at all.

I didn’t know about Meshtastic at the time, so I was happy to find this. Existing support for both nRF52 and the E22 SX1262 module!

Alas, no cigar. Just another brick wall. Using the RAK815 as a base and following the guides I found, I ported the software to this hardware. But just as with every other attempt to make any LoRa software run on this hardware, it does absolutely nothing.

You would think at this point the hardware is faulty, but that’s not the case. There is a single way I can get software to run on this and that is with Sandeep Mistry’s Arduino core: GitHub - sandeepmistry/arduino-nRF5: Arduino Core for Nordic Semiconductor nRF5 based boards
If I use that to first flash a soft device from the Arduino menu, I can then run a simple blinky that also prints stuff to a serial port. I haven’t tried more since the point was just to prove that the hardware is not faulty and it can run code. Literally anything else I’ve tried to flash to this board does nothing at all. No indication that any code runs at all.

What is really bizarre is that say I have some code running using Sandeep Mistry’s Arduino. Then I go to either Adafruit’s Arduino or Meshtastic (I guess they are the same under the hood, but for one I use the Arduino IDE and for the other PIO), compile some code and flash it. My J-Link will flash the code, verify it (and it’s correct), but when the board resets, it is still running the Sandeep Mistry Arduino code! How is that even possible?

I’m at my wits end. I do have plenty of embedded software experience as well (though I much prefer hardware), but I’m ready to throw the towel. It seems I made a big mistake when I designed this around the nRF52832. What is a person to do if the chip doesn’t even run the code programmed? Can anyone help me with this or have any idea what might be going on? Many thanks in advance.



A bit of progress. I found a post somewhere that said the Adafruit nRF52 bootloader needed to be loaded for Meshtastic to work on this target. After cloning the bootloader repo and fighting with porting that for a while I now have a bootloader that is flashed and I can use it to upload sketches from Arduino with the DFU mode. And they run! LED is flashing and serial port receives data.

Still, Meshtastic doesn’t run.
I’ve changed the board setup to upload with nrfutil instead of jlink (assuming that’s what’s used in Arduino), and it programs the board when I do pio run -t upload, but no signs of life on serial or BLE.

1 Like

Hmm - I think it is possible that some bitrot has crept into the RAK815 support - I didn’t bring one with my on my current (long) trip and it was mostly an early proof of concept for nrf52 CPUs (because it has very limited RAM for this application - the nrf52833/nrf52840 are very nice though). I saw the bug you put in on github to revive that build (thanks). Alas, I don’t think I’ll have time to look at it for a couple more weeks (want to get 1.2 out first)

Since this is still under development, do you think it may make sense to redesign it with the nrf52833? I don’t want to design something that relies on a part that risks being abandoned.

Do you think nrf52833 or nrf52840 is the best way to go?

Still looking at why I can now run Adafruit Arduino code, but Meshtastic still doesn’t run. The code does print to the serial console, correct? And your code is based on Adafruit’s Arduino core for nRF52, correct? Just to make sure I’m not barking up the wrong tree.

yep - does print to the serial console, but the baud rate we use is 921600, so you might want to check that.

For any new board I think nrf52840 is an amazing way to go. LOTS of headroom for the future. the nrf52833 has “enough” room for at least two years of progress I think. But given the small price difference the 840 is the way to go IMO.

Meshtastic barely is able to run and do useful stuff with the amount of ram in the nrf52832.

1 Like

Oh, that is a nice looking board. I hope you are able to get it working and I’d love to build one.

@xorbit, your workmanship and attention to detail is second to none! I’m pretty sure you will find great support for your project in here. Please don’t give up!

1 Like

e73 is just a nRF52832 / nRF52840 (based on model) with 32MHz crystal (you still need to add 32.768kHz watch crystal if you need BLE/ANT+/Zigbee/…), caps and simple antenna circuit in a nice shielded package (you can buy some without the shielding can or you can just remove like on nRFMicro), nothing else. And it is crazy cheap…

Are you going to share its schematic with gerber files or are you going to sell it somewhere?


@randybb since this is my business and income, I usually produce and sell products in places like Tindie, Crowd Supply, Mouser. I make the schematics available so customers know exactly what is in the circuit but don’t share the board files so it’s not too easy for copycats to reproduce and undercut me in the market without having to spend any development effort.

I don’t like to just throw hardware out there though, I prefer to have some good software base for customers to use and try to contribute to open source software projects such as this to make this happen. This is the step that ended up harder than expected in this case… :confused:

But maybe that’s a good thing. Basing this on the nRF52832 may be too limiting. Still I want get these prototypes to work even if I never produce them as they are, because I’m sure I’d face the same battles with the nRF52840. If I can use these to learn as much as possible I can hopefully get a rev 2 based on the nRF52840 done correct right away. :wink:

@geeksville Thank you for the recommendation, I will redo rev 2 with the nRF52840 so there’s more headroom to make it useful. I still want to get it running on these prototypes so I can throw them outside and learn what I can from them though.

I noticed you have custom forks of various repos this project depends on. I cloned and ported the Adafruit rRF52 bootloader for the pinout of my board and I can flash code with it. Is this the right way to go or is there a customized bootloader repo I should use?

I totally understand and with an optimised software it will be even more interesting board.
I have E73 modules nRF52840 and ceramic antennas, you just need to swap it for a different model. And what about 32kHz crystal? It is on the other site?
Anyway, in case you need even more power, then you can switch to the newest dual core nRF5340 :slight_smile:

@randybb From what I gather here on page 1, the nRF52832 E73 has a 32 kHz crystal on the module but for the nRF52840 E73 you need to add it externally. The other side of the board is completely flat so it can be used as an SMT module with castellated edges itself.

The nRF52840 module is significantly smaller though and has USB and more pins, which opens possibilities to add a USB port, LEDs and buttons to make it easier to program (I have to add programming stuff externally at the moment) without making it bigger. So this would likely be a good change.


Fixed a copy/paste mistake in my platformio.ini and I now have some serial output:

??:??:?? 0 Emitting reboot packet for serial shell
��H??:??:?? 0 Filesystem files:
??:??:?? 0 I2C device found at address 0x59
??:??:?? 0 done
??:??:?? 0 Meshtastic swver=1.1.50, hwver=unset
??:??:?? 0 Reset reason: 0x4
??:??:?? 0 FIXME, call randomSeed
??:??:?? 0 Setting default preferences!
??:??:?? 0 Expanding short PSK #1
??:??:?? 0 Wanted region 0, using Unset
??:??:?? 0 Initial packet id 1481765933, numPacketId 4294967295
??:??:?? 0 No saved preferences found
??:??:?? 0 This build does not specify a HW_VERSION
??:??:?? 0 Expanding short PSK #1
??:??:?? 0 Wanted region 0, using Unset
??:??:?? 0 legacy_region=, region=0, NODENUM=0xe31bc5f, dbsize=1
??:??:?? 0 Warning: No GPS found - running without GPS
??:??:?? 0 Starting meshradio init...
??:??:?? 0 (bw=125, sf=12, cr=4/8) packet symLen=32 ms, payloadSize=16, time 2269 ms
??:??:?? 0 Set radio: name=LongSlow, config=3, ch=0, power=0
??:??:?? 0 Radio myRegion->freq: 903.080017
??:??:?? 0 Radio myRegion->spacing: 2.160000
??:??:?? 0 Radio myRegion->numChannels: 13
??:??:?? 0 Radio channel_num: 0
??:??:?? 0 Radio frequency: 903.080017
??:??:?? 0 Short packet time: 2269 msec
??:??:?? 0 Set radio: final power level=22

Does this look “normal”? I don’t really know what to expect here.
I’m not seeing any Bluetooth device to pair with. It looks like the softdevice should be programmed correctly since I can get the bootloader into BLE update mode and then I can see an “AdaDFU” device. What’s the Meshtastic Bluetooth name? Does it only appear after initiation from the UI? I don’t have a screen attached yet, soldering iron is dead and I’m waiting for replacement parts…

I plan to get a T-Beam as a reference device for testing but I don’t have that yet either.

1 Like

You are right, just checking datasheet - I thought these have the same pinouts :frowning: There is loot of differences and it is not only about memory.

Yes, it seems like a very different module. I wonder why they decided to call all of the variants E73, with the only differentiation the long string after that.

Got the screen connected. It’s showing signs of life:

Pressing buttons doesn’t do anything. Still no sign of Bluetooth. Anyone have any idea about that?

1 Like

@geeksville Hmm do I have it right that the nRF52832 also doesn’t have a second serial port? I assume it can’t support GPS then?

1 Like

I found that the code gets stuck in this function when it’s first trying to communicate with the SX1262 over SPI:

byte SPIClass::transfer(uint8_t data)
  _p_spi->TXD = data;


  data = _p_spi->RXD;

  _p_spi->EVENTS_READY = 0x0UL;

  return data;

It gets stuck in the while loop waiting for EVENTS_READY which never gets set. Kind of funny actually that at higher levels the code has timeouts etc. but here it’s just a tight loop. It was never expected that this would fail to get set?

Which makes sense, since it’s a hardware peripheral. You write the TXD register, the hardware does its thing and sets the flag. Right? Apparently not.

This shows the SPI port registers at the time:

A Google search gave me some results. One person had this happen because his slave’s GND was not connected. I’m pretty sure mine is connected fine, so I don’t think that’s it. Also very weird this would have an effect of this flag because you’d expect the SPI peripheral to be dumb enough to not know anything about the attached peripheral and just blast out bits. Another thing I found was that someone had this issue when they have the SoftDevice enabled and not when the SoftDevice was disabled. Possibly something to do with which pins were used and if the SoftDevice was somehow using them? I really didn’t want to become an expert in this. Does anyone know what pins the SoftDevice might be using and how to disable or change that?

I guess the quickest way to find out would be to check what’s happening on the SPI pins. Unfortunately they’re not easy to reach on my current setup so I need to solder some fly wires to them. Unfortunately my soldering iron broke. I had Metcal send me replacements but unfortunately they send the wrong ones so I still don’t have an iron. So many unfortunate things going on.

1 Like

Using the stock adafruit bootloader is fine. I forked it to add some fixes for other boards that haven’t yet been merged back into master.

@geeksville Hmm do I have it right that the nRF52832 also doesn’t have a second serial port? I assume it can’t support GPS then?

Sorry I don’t remember. But if the datasheet says there is only one UART that would be the case. Unless adafruit already has support for software bitbanging low baudrate serial via GPIOs (which could work for 9600 baud NMEA but it would be a PITA)

One of the nice things about the nrf52833/840 is that they have a ‘real’ USB controller. So we don’t need to burn a serial port for that link, instead we run a CDC-ACM device over USB.