Single-Step Debugging the Uno ATMEGA328 (aka Arduino Uno) for the M5Stack LoRa

Today I revisit my old friend, the Microchip Atmel ATMEGA328P (aka Arduino Uno), although this is unlike any Arduino I've had before!

This is a continuation of my previous blog, where I am working on improving the range of LoRa on the ESP32-based M5Stack module. Many thanks to Jimmy Lai that sent me a prototype of the next version of LoRa module!

Note my LoRa board arrived with no headers soldered on. There's not really room for a typical install of the usual jumper headers due to how thin this the module is. I still used the standard header, but given the limited space, I inserted the plastic on the reverse side of the board and snipped off the pins on that side.

I soldered from above. I can't remember the last time I did this - if ever. One thing to keep in mind is to use as little solder as possible, as quickly as possible. The solder will want to wick up the post, making them ever-so-slightly thicker. Also - if there's a glob of solder at the bottom, the jumper wire won't fit all the way, and we're already a little on the short side from installing the header on the other side.

Ready to proceed with the fun stuff...

Upon close inspection of this new LoRa board, there's a tiny ATMEGA328P sitting there! (yes, the same micro-controller in the famous Arduino Uno (see typical Uno schematic).

Unlike a "regular" Arduino, there's no need to cut the trace for "Reset EN". (regular Arduinos programmed with the serial port have DTR connected to reset with a capacitor that otherwise interferes with ISP).

This Mega328 has the 28 pin, MLF form factor:

See the full ATMega328 spec sheet here. This Mega 328 LoRa board is connected like this:

As shown, the Mega328 sits between the ESP32 core and the LoRa RA-02 transceiver. So the plan is interrupt driven LoRa that the Mega328 handles, while I2C will be used to exchange data from the ESP32 core and the Mega328. So before doing anything, this sounds complex enough to need a serious debugger.

Fortunately I already had an Atmel ICE debugger and Atmel Studio 7 installed. As a reminder, here are the instructions:

First: ensure the latest version of Atmel Studio is installed via Help - Check for Updates (I am using Version 7.0.1645). It may also prompt you to update the firmware in the ICE Debugger. (1.27 in my case). See Tools - Device Programming.

The most difficult thing is figuring out the pins to connect. Unfortunately the LoRa module has the ISP connections in a line rather than the standard connection. Adding to the frustration is the fact that the DuPont pins on the octopus cable have taped-on numbers. Although it is handy having the connections labeled, the thickness of the tape makes having 6 of them in a row a very tight fit:

As a feature request, I hope the M5Stack folks consider implementing a standard SPI / ICSP connector:

In the meantime, it would probably be worthwhile to create a custom inline Dupont header using a kit such as this and this crimping tool. (this is incredibly handy to have)

The single most important thing is that: MO = MOSI = TDI (I wasted a bunch of time when I had assumed MO = MisO = TDO; which is not correct!). Also note that nTRST != nSRST.  (yes, I made that mistake, too; my original screen clip did not include the SPI column which makes this more obvious).

These are the correct connections for debugWIRE, aka SPI, aka ISP programming of the M5Stack LoRa ATMEGA328P:

Note that VTG is not suited to power a remote device. This is a power sensor to determine logic voltage levels. Devices being debugged, including this LoRa module most be self powered!

For more information on the ICE Debugger, read the fine manual.

I started with a simple Uno sketch file:

void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);
}

void loop() {
  // put your main code here, to run repeatedly:
 Serial.println("hello");
}

Then in Atmel Studio: File - New - Project:

Select "Create project from Arduino sketch", edit directories as needed, then press ok.  Next select the file location of the Arduino sketch. Be sure to select Arduino/Genuino Uno for Board:

It may take a short while to create a project.

Once the project is created, click Project - {name} Properties (Alt-F7). Select Atmel ICE Debugger and ensure Debug Wire is selected for interface:

Next - click Debug - Step Into. The first time, there will likely be a warning about fuse settings:

Press Yes to set the fuses appropriately. If you get any other errors, check the wiring. Then recheck the wiring.

If successful, there will be a message that debugWIRE is enabled. BE SURE TO READ THE MESSAGE:

Note that you MUST power cycle the Mega328 (in our case the M5Stack & LoRa). Do not power cycle the Atmel ICE debugger.

Press ok, and VOILA!

I recall reading that the ATMega328 *must* have debugging properly disabled upon completion or Really Bad Things might happen (really?). I still do this, although I've never actually tested it to be sure. While paused at a breakpoint, click Disable debugWIRE and Close.

So the next step will be seeing if I can get the RadioHead drivers working on this new LoRa module... but first I'd like to get the LoRa AVR serial port working.


Resources, Inspiration, Credits, and Other Links:

• HTML Version of Atmel ICE Documentation
• AVR Tutorial
• Engbedded Atmel AVR® Fuse Calculator
• Updating firmware on USBASP bought from eBay
• USBasp - USB programmer for Atmel AVR controllers
• Atmel ICE
• Visual Micro Debugging
• Atmel ICE in Arduino IDE
• Atmel ICE User Guide
• AVR Freaks: Atmel-ICE unable to start a debugWire session
• 
  

M5Stack LoRa Range Improvement

Last month I started working on a project to control GPIO pins on a device (relatively) very far away using LoRa technology. Most of the showstopper problems seem to have been resolved. Well, at least getting the RadioHead code working on the M5Stack. This blog entry continues on that topic...

TL;DR

• VisualMicro Arduino projects in Visual Studio, using 32u4 (see also Adafruit 32u4) and M5Stack - both over LoRa.
• M5Stack RSSI is a solid RSSI strength of 10 points worse than the exact same code on 32u4 which has the exact same RA-02 AI-Thinker LoRa device.
• Recall from previous blog, LoRa RST and IRQ are reversed. (RST is actually GPIO36 input only; unusable). Otherwise it would have been: Beep = LoRa reset. 
• M5Stack Speaker (GPIO25) is shared with LoRa Interrupt. (beep = interrupt?)
• The M5Stack display shares the NSS pin with the LoRa module. (poke registers with care!)
• The receiver and transmitter need to be configured EXACTLY the same for best range (more than just the same frequency); but this was not the problem with our poor RSSI
• My LoRa-GPIO project and required RadioHead and M5Stack libraries merged to master on GitHub
• When updating library (include) code, Visual Studio apparently does not look at file dates and may use previous compiled code; clean project after library changes.

The latest working (although not very pretty) Very Remote Lora-GPIO Control and Monitoring Project code has been merged onto my master branch.

I've merged my M5Stack development branch back to my RadioHead master branch. This was a "Squash and Merge". Normally I like to keep the history... but as the RadioHead owners prefer a single patch file, perhaps this will be better. Time will tell. History is still in the branch.

I've submitted a PR to Adafruit at their request, as well as well as sent a patch file to Mike at ReadioHead. Ok, this is weekend and evening working, certainly not some of my best polished work. I need to go back and clean things up.

My M5Stack library fork is, and has been up to date on the master branch. (no branches)

The main LoRa-GPIO solution contains several projects as noted in the GitHub readme. These are all Arduino-style projects using the really awesome VisualMicro add-in for Visual Studio.

As a side note, while working on this - I found what appears to be GitHub branch-to-branch compares not working properly.  (if it *does* work properly and I'm simply not doing it correctly, please let me know)

I've been reading through the ARRL Ham Radio License manual. I don't know if I will actually get a ham license, but wow - what a great book this is to cover the essentials of what you need to know for RF communications (such as the LoRa for this project). Although I had a ton of classes in college covering a wide variety of electronics, electromagnetism, communications, even an entire class on antenna theory... this ARRL book contains a lot of relatively straightforward, every-day language on the practical essentials of radio frequency communication - all in one place. The ARRL web site also has some excellent resources. Ok, there's also pretty much NO math, NO theory: Just useful facts. So this is certainly not a book for how or why or how to apply to new problem. Still, it is a quite good book. Highly recommended & would make a great gift for someone new to the field.

So on to the testing... now that I have the RadioHead drivers working, I actually went back to the M5Stack example code (Sandeep drivers renamed M5LoRa). Recall that I have the RadioHead drivers on a remote 32u4 sending LoRa packets. Here's the sample code for the M5Stack receiver (Arduino: File - Examples - M5Stack - Modules - LoRa - LoRaReceiver) :

#include 
#include 

#define LORA_CS_PIN   5
#define LORA_RST_PIN  26
#define LORA_IRQ_PIN  36

void setup() {
  
  M5.begin();

  // override the default CS, reset, and IRQ pins (optional)
  LoRa.setPins(LORA_CS_PIN, LORA_RST_PIN, LORA_IRQ_PIN); // set CS, reset, IRQ pin
  Serial.println("LoRa Receiver");
  M5.Lcd.println("LoRa Receiver");

  // frequency in Hz (433E6, 866E6, 915E6)
  if (!LoRa.begin(433E6)) {
    Serial.println("Starting LoRa failed!");
    M5.Lcd.println("Starting LoRa failed!");
    while (1);
  }

  // LoRa.setSyncWord(0x69);
  Serial.println("LoRa init succeeded.");
  M5.Lcd.println("LoRa init succeeded.");
}

void loop() {
  // try to parse packet
  int packetSize = LoRa.parsePacket();
  if (packetSize) {
    // received a packet
    Serial.print("Received packet: \"");
    M5.Lcd.print("Received packet: \"");

    // read packet
    while (LoRa.available()) {
      char ch = (char)LoRa.read();
      Serial.print(ch);
      M5.Lcd.print(ch);
    }

    // print RSSI of packet
    Serial.print("\" with RSSI ");
    Serial.println(LoRa.packetRssi());
    M5.Lcd.print("\" with RSSI ");
    M5.Lcd.println(LoRa.packetRssi());
  }
}

This code writes to  both the M5Stack display as well as the serial port. The display is cool as I don't need to remember to disconnect the serial port when reprogramming. HOWEVER: You may recall from my previous blog that the M5Stack display *and* LoRa module share the NSS (slave select) pin. That simply sounds dangerous (and indeed I observed some display oddities), so I put M5Stack LoRa to sleep when writing to the display.

The shocking thing here is that there's up to a difference of TEN in RSSI values as compared to using the RadioHead drivers. (RSSI 36 vs 26). As this is a log scale, that's a 10x difference in power! Now - this is not to say that the Sandeep library has a problem just because it is polling rather than using interrupts. It is a matter of default configuration. I picked apart the RadioHead control register libraries and added a note about the matching importance:

When printing the register values from the Sandeep (M5LoRa) library, (move the readRegister from the private to public section)...

    Serial.print("0x");
    Serial.print(LoRa.readRegister((uint8_t )0x1d),HEX);
    Serial.print(", 0x");
    Serial.print(LoRa.readRegister((uint8_t )0x1e),HEX);
    Serial.print(", 0x");
    Serial.print(LoRa.readRegister((uint8_t )0x26),HEX);

There's a SINGLE BIT different (CRC not enabled!):  0x72, 0x70, 0x4 - alas that didn't seem to make much of a substantial difference in RSSI values. I supposed I had expected different error coding, spreading factor, or some other obvious difference.

I confirmed the running values of RadioHead cinfig registers are also 0x72, 0x70, 0x4 - but the RSSI is typically -25 whereas the Sandeep (M5Lora) drivers report an RSSI of typically -35!

So the next thing is: how to each of them calculate RSSI?


Well, the Sandeep / M5Lora library does this:

int LoRaClass::packetRssi()
{
  return (readRegister(REG_PKT_RSSI_VALUE) - (_frequency < 868E6 ? 164 : 157));
}

float LoRaClass::packetSnr()
{
  return ((int8_t)readRegister(REG_PKT_SNR_VALUE)) * 0.25;
}

But the RadioHead library does this:

// Remember the last signal to noise ratio, LORA mode
// Per page 111, SX1276/77/78/79 datasheet
_lastSNR = (int8_t)spiRead(RH_RF95_REG_19_PKT_SNR_VALUE) / 4;

// Remember the RSSI of this packet, LORA mode
// this is according to the doc, but is it really correct?
// weakest receiveable signals are reported RSSI at about -66
_lastRssi = spiRead(RH_RF95_REG_1A_PKT_RSSI_VALUE);
// Adjust the RSSI, datasheet page 87
if (_lastSNR < 0)
 _lastRssi = _lastRssi + _lastSNR;
else
 _lastRssi = (int)_lastRssi * 16 / 15;
if (_usingHFport)
 _lastRssi -= 157;
else
 _lastRssi -= 164;

Grr... So ok, the difference in RSSI appears to be simply a different calculation.  The real test is: how far away can the units be and still communicate? I'm still happy I have the RadioHead libraries working. In my opinion is is clearly the superior code.

So reference check: after all the code changes, let's try same units: 32u4 to 32u4. Cleaned project, full rebuild. RSSI value is -19 or -20! Rechecking the M5Stack, RSSI is -27.  So even with the same codebase and same calcs, the M5Stack LoRa has a poorer RSSI value. Using an external battery power source and the value improves to RSSI = -24.

So, as mentioned about - I've been reading about real world antennas, so perhaps the M5Stack antenna has an issue. Well, I tried that as well, replacing the internal antenna with one of those external antennas - identical to the one on the 32u4. Still there's a discrepancy in RSSI values between the two devices.

What else? Ok, so there's a speaker in the M5Stack. Poking around with that, defined in:

libraries\M5Stack\src\utility\Config.h

there's a declaration:

// BEEP PIN
#define SPEAKER_PIN 25

Ah yes, GPIO25, our friend. The LoRa interrupt pin.  (sigh)

So perhaps all the extras in the M5Stack are indeed causing a problem. I tried to disable a few things  such as the speaker init, but no luck. I do however, have another Console (without display) app that is specifically targeted for the 32u4, but with the magic of simply changing platforms in the IDE, can be recompiled and sent to the M5Stack!  RSSI about that same at -27 (ranging from -23 to -29).  Replace with the exact same code on the 32u4 and the RSSI is a full 10 points better at -17.  (10x improvement in signal strength!).

I tried another M5Stack unit with a different LoRa module. Same result.

So at this point, I really believe it is a hardware issue. I've been unable to get a copy of the schematic for the M5Stack LoRa module, However the 32u4 has a pin connection diagram here.

As soon as hardware is questioned - the first thing to do is of course add some capacitors! I added a 10uF and a 10pf cap directly to the power input to the RA-02.

In the pic, you can see I fished a new, external antenna along with the new caps. And ya, I got a little close to the side of the M5 Lora module.

Additionally I added a shield (aluminum foil sandwiched between two layers of clear packing tape) to both sides of the LoRa module. After all - there is an ESP32 microprocessor buzzing away just on the other side of the PCB!

The first field test was a relative success! I more than doubled the original range! Ok, so I didn't actually test after each change, so I don't know exactly which was the most effective in extending the range.

Note the Semtech site has a bunch of LoRa resources, including this cool LoRa calculator (I will include in my GitHub repository in the docs container, in case the link to Semtech ever breaks.

Note that I am currently transmitting at 125kHz. Lowering this increases range! Lower this to about 15.6kHz and you get another 10db in "link performance". (in theory).

Overall I am quite happy with the result. Ok, I'm not seeing multi-kilometer ranges. But that's also line-of-sight. My transmitter is on the kitchen table - with the entire garage between it and the M5Stack receiver. Next test will be from line of site.

The super exciting thing is I have a prototype from the kind folks at M5Stack arriving in the mail soon for the next potential version of the LoRa module. I am quite interested in seeing how well it performs.

Stay tuned for my next blog where I work on the prototype V2 LoRa modules with its own embedded ATMEGA328.


Resources, Inspiration, Credits, and Other Links:

• My LoRa-GPIO project
• Is a longer antenna better?
• LoRa32u4 pinout
• RadioHead master source
• RadioHead forum
• Semtech LoRa Modem Designer's Guide (I will add a copy to my project doc directory)
• SX1276/77/78/79 datasheet (copy also in doc directory)
• Semtech LoRa Modulation Crystal Oscillator Guide
• LoRa and FCC Part 15.247 Measurement Guidance
• Semtech SX1276 home page
• Adafruit Feather LoRa 32u4 schematic (RFM69FW)
• Return Loss vs VWSR
• GitHub Mastering Markdown
• Do GitHub Branch Compares work?

LoRa Range Issues

This is a continuation of my previous blog: M5Stack LoRa Range Issues.

TL;DR

• The M5Stack LoRa is using Sandeep drivers (polling) whereas RadioHead drivers use interrupts.
• The M5Stack LoRa board has IRQ/RST reversed! IRQ DIO0 is actually connected to GPIO26. RST is actually connected to GPIO36, but is useless since GPIO36 is input only.
• The M5Stack display shares NSS on GPIO5; LoRa needs to be put to sleep when updating display. (Mutex likely needed in FreeRTOS)
• SemTech SX1276/77/78/79 == HopeRF RFM95/96/97/98 (almost exactly the same pages!)
• Various links on Lora, installing libraries, etc

When considering performance, be sure to check out this excellent YouTube video: #182 ESP32 Lora Boards: What you need to know before you buy (incl. Antenna knowledge) - thanks Mark West @TheFlyingZephy for pointing this out)

There are a variety of LoRa libraries:

• Sandeep Mistry similar to that used in M5Stack fork (specifically here)
• RadioHead: RadioHead Packet Radio library for embedded microprocessors specifically RH_RF95
• Hallard
• Matthijs Kooijman IBM LMIC (LoraMAC-in-C) library, adapted to run under the Arduino environment

Plus this interesting  LoRa.py gist

My LoRa32u4 is using the RadioHead libraries; The M5Stack uses a slightly modified Sandeep library. A pair of LoRa32u4 units work great. A LoRa32u4 sending to M5Stack - not so great. So I'm attempting to use the RadioHead library with the M5Stack.

To install M5Stack library with ability to save in GitHub and submit pull requests. First fork the project to your own GitHub repository. Then clone it to your Arduino library (in my case, gojimmypi user)

cd C:\Users\gojimmypi\Documents\Arduino\libraries\
git clone https://github.com/gojimmypi/M5Stack.git
:: optionally get RadioHead drivers from Adafruit
:: ren RadioHead RadioHead-stock
git clone https://github.com/gojimmypi/RadioHead.git

cd C:\Users\gojimmypi\Documents\Arduino\libraries\
mkdir temp-adafruit
cd temp-adafruit
git clone https://github.com/adafruit/RadioHead.git
cd RadioHead
xcopy *.* ..\..\RadioHead\*.* /s /d
:: reminder to delete temp-adafruit

In my case, after the fork from Adafruit, I deleted everything (except hidden .git directory, of course) and copied back the contents of the RadioHead-stock directory so we could use Visual Studio diff (right-click, Compare with Unmodified). Not unexpected, the RadioHead I had was older. So I fetched the Adafruit into a temp directory, then copied it back:

See https://github.com/gojimmypi/RadioHead/tree/M5Stack (this is the branch with my active edits for M5Stack LoRa)

I've created a branch to submit changes back to the RadioHead master. Note that for contributions, special instructions are needed since they are not using GitHub. I also have a PR back to Adafruit.

Visual Studio users will be happy to know there's a feature to use File Explorer; right click on the directory and select "open in Visual Studio". With the GitHub extension installed, there's a very nice GUI for GitHub.

I have yet to figure out branch-to-branch compares on GitHub and have opened this issue.

To add the RadioHead libraries to an M5 Stack project: vMicro - Add Library - User - RadioHead:

After spending a ton of time trying to get the RadioHead drivers working, first I found that that M5Stack base I was using had completely inoperable GPIO35 and GPIO36 pins. After swapping that out for a new one... and even more time spent trying to get RadioHead drivers working - I discovered another WIRING problem. <sigh> Connections to GPIO26 and GPIO36 are reversed! Not all coding problems are based solely in software.

Here's the corrected M5Stack LoRa pinout diagram:

Note that the RST (reset) input to the RA-02 LoRa device won't actually reset, as GPIO36 is input only!

Many thanks to Jimmy Lai at M5Stack for sending me a prototype of their next version of LoRa. Looking forward to my next gizmo in the mail :)

So now that I actually have the RadioHead drivers working with the M5Stack... now on to actual performance testing in my next blog.


Resources, Inspiration, Credits, and Other Links:

• #112 LoRa / LoRaWAN De-Mystified / Tutorial
• ESP32 - LoRa - OLED Module | Hackaday.io
• TTGO V2 LoRa
• Low Cost LoRa gateway
• WeMos Lora RFM9x Gateway Shield (see LoRa Gateway with ESP8266 and a RFM95)
• #169 LoRa one-to-one Connection for a Mailbox Notifier with an Arduino and a Wemos Shield
• Time Library https://github.com/PaulStoffregen/Time
• Siglent SSA3021X Spectrum Analyzer 9 kHz to 2.1 GHz
• Application Note: LoRa® Modulation Crystal Oscillator Guidance
• return loss vs. VSWR
• Adafruit Feather 32u4 with LoRa Radio Module
• Understanding RSSI
• SX1272

M5Stack LoRa Range Issues

Investigating 32u4 to M5Stack LoRa poor range issues; Background information & initial tool setup.

Well, after my last post regarding the fascinating world of FPGA programming, I really thought this next post would continue on that topic. I really want to try out Luke's tiny FPGA board. Alas I've encountered another issue on a project that warrants sharing and someplace for me to keep my notes.

TL;DR

• Misc details and notes on LoRa
• VisualMicro ESP32 USB Debugging caused by new driver version
• NESDR issue with SDR software and driver install
• LoRa Range issue still unresolved, stay tuned for part 2

Late last year, I finally decided to buy a couple of "DIYmall LoRa32u4 LORA RA-02 Module Development Board Long Range Communication 1KM LiPo Atmega328 SX1278 with IPEX Antenna for Arduino" devices when Amazon had one of their "Lightening Deal of the Day" sales. Not to be confused with LoRaWAN - these are simple serial-type broadcast devices but with very long range. Getting them to talk to each other was ridiculously easy mainly thanks to the great Adafruit Feather 32u4 with LoRa Radio Module tutorial and sample code.

Perhaps there's some software to do LoRaWAN with these (if anyone knows, let me know ) - however I don't have any service providers nearby and the gateways are expensive.

edit 2/18/18: here's a video on creating a LoRa gateway:

By the time my LoRa modules arrived, I had forgotten the title explicitly called out the "RA-02 Module". In hindsight, I'm surprised the Adafruit code worked at all, given their description naming their LoRa device as a Adafruit Feather 32u4 LoRa (RFM9x).  Apparently the RA-02 and RF95 libraries are "close enough" - as my 32u4 appears to have the exact same RA-02 module as used on the M5Stack LoRa module. (I wonder what, exactly is on the Adafruit device?)

Which reminds me: be sure to check the frequency of the respective LoRa devices: they need to match not only each other, but also be allowed in respective county of use!

  (source: RF Wireless World)

After having the proof of concept working with the two 32u4 devices (RadioHead RFM95 libraries)  - which I was able to show them working hundreds of meters apart through very obstructed signal path and certainly not a straight line-of-site (e.g. hill, buildings, trees, etc)... I thought it would be cool to have a display module on one end, controlling the GPIO's on the other.

Some time ago, I had ordered an ESP32-based M5Stack so I decided to use this for a "console" along with their LoRa Module to talk to a very remote 32u4. Seems simple enough in concept, eh? Ha! Nothing is ever as easy as is is supposed to be.

First, the M5Stack core library uses different Sandeep Mistry LoRa drivers. (see also github) Thinking that "LoRa is LoRa", I assumed that they would work together. Indeed the workbench test was a complete success the first time.

However, the first real field test was a disaster. Taking the dog for a walk with an M5Stack connected to USB battery pack in hand, I expected to be tweeting success far from home. I was barely out of WiFi range across the street when the M5Stack stopped receiving messages from the 32u4. Certainly a long way from kilometer LONG Range.

As it turns out, KongDuino recently left a rather interesting blog review of the M5Stack and LoRa modules. It would seem that I'm not the only one with LoRa range problems. If it was easy, it wouldn't be any fun - right?

Note that the 32u4 devices use so little power, that the Anker portable power supply turns off after a few minutes - perhaps thinking nothing is actually connected. Perhaps a USB hub or something might help for a road trip with it.

I've posted my code on GitHub under a project called LoRa-GPIO. This is a pitiful hack of sample code, but an otherwise operational proof of concept of the 32u4 transmitting a signal for the M5Stack to receive and display.

So to investigate the range issues, we'll need some tools such as break-point debugging and signal analysis.

Note for anyone using VisualMicro for development (like me). If any problems are encountered debugging the ESP32, be sure to check the CP210x USB driver version - particularly just after Windows Updates. There's apparently a known problem with recent drivers not working, Simply select (or install as needed) an older version to fix:

Ok, so anytime there's a signal transmission issue at hand, it is helpful to have some visualization tools. I have the inexpensive Nooelec Smart SDR on hand.

See Using SDR Sharp Quick Start Guide. Download Windows SDR Package from https://airspy.com/download/  Need to disable new security feature that prohibits unsigned drivers.

bcdedit /set testsigning on

Reboot. To turn off:

bcdedit /set testsigning off

Even running zadig as administrator, I was unable to change drivers. So ok, I guess I needed to download new driver installer from the Nooelec Getting Started.  Windows is brutal; it completely removed the prior SDR drivers I had installed and working. Grr,,,

SDR Sharp had complained about the Visual Studio 2015 C++ runtime not being able to be installed (I have Visual Studio 2017 installed)... so rather than fuss with that, I installed the CubicSDR 0.2.2 software also located at the bottom of the Nooelec Getting Started with NESDR page.

Note there's an entire CubicSDR web site, and the most recent version appears to be v0.2.3 released in January of this year (2018) complete with source code on GitHub.

Once finally installed, the LoRa signal can be visualized:

So, ok.. I've fussed with Visual Studio debugging, SDR software install, and typing up all these notes and most of the day has flown by. No progress today on the actual problem of poor LoRa range. Clearly a part two is due and coming soon...

• VisualMicro IDE for Visual Studio
• M5Stack.com
• M5Stack LoRa Module on AliExpress
• DIYmall LoRa32u4 LORA RA-02 SX1278 for Arduino
• Adafruit Feather 32u4 with LoRa Radio Module
• Arduino 433Mhz Lora SX1278 Module DRF1278F on tindie
• 433MHz LoRa SX1278 long range RF wireless module DRF1278F For Arduino on ebay
• Semtech SX1272/3/6/7/8 LoRa Designer's Guide
• https://github.com/sandeepmistry/arduino-LoRa
• https://github.com/m5stack/M5Stack
• http://www.electrodragon.com/w/SX1278
• https://github.com/gojimmypi/LoRa-GPIO
• Sparkfun Serial Peripheral Interface (SPI) tutorial
• M5Stack Custom Fonts sample
• https://github.com/espressif/arduino-esp32/issues/821
• CP210x USB to UART Bridge VCP Drivers
• Semtech - What is LoRa
• SDR Software

First FPGA Test Drive with Altera Cyclone IV

I decided to finally learn how to program an FPGA! Here are some first impressions and notes to self for future reference.

TL;DR

• Blaster drivers need to be manually installed from C:\intelFPGA_lite\17.1\quartus\drivers
• Cyclone IV board is EP4CE6E22C8; do not use default "auto device" (for Pin Planner) 
• Verilog file added manually, module name must match file name and is case sensitive
• Source files in the project are "Design Entities"
• Do not insert to remove the USB Blaster ribbon cable while the device is powered on.
• Download vendor board files here
• JTAG programming of FPGA is temporary and lost upon power cycle

I ordered my first FPGA board - the Altera Cyclone IV EP4CE6 FPGA Development Kit and USB Blaster from the Numon Electric Cyberport Store on Aliexpress thanks to inspiration by Amitesh. He did all the footwork to find what seems to be the coolest Cyclone FPGA board that can still be programmed with the free version software. (note the really cool GX version with Nios processor needs software costing thousands of dollars)

If you order the board from Numon Electric, they have a download available on one-drive that includes a ton of really great documentation, sample code, and more. The file is called "RZ301 EP4CE6 development board.zip" however the contents of that zip file consist of mainly a single file "Altera Cyclone IV board V3.0.rar". Windows users will be annoyed that there's no native tool to easily extract RAR files. Having a linux VM or WSL will be handy here. The latest version of winzip also appears to now support RAR extraction.

Overall I was quite happy with the responsive customer service, prompt delivery, and quality of my new FPGA board. If you look close at the picture of my board, the actual silkscreen quality is much better than shown: the blur is from the poor picture.

While awaiting delivery of my Cyclone, I found this other tiny, inexpensive FPGA created by Luke Valenty. Note that if you order on the tinyfpga store web site, you can pay with Amazon, without having the hassle of creating an account, etc. This board is so cool, I think I will have a separate blog about it later.

Surprisingly, my Cyclone board arrived relatively quickly in only about 2 weeks! (the estimate at order time was 19 to 39 days)

In order to program the Cyclone board, the Altera Quartus Prime Lite software is needed. Unlike some other programs, installation was quick and easy.

IMPORTANT: Do not insert to remove the USB Blaster ribbon cable while the device is powered on. There was an included warning that the board would likely be damaged. I did not test this.

The USB Blaster was not Plug-N-Play, and Quartus Prime did not see it:

A quick google search indicated that the drivers need to be manually installed; instructions copied from Altera site here for reference:

The Altera On-Board USB-Blaster II cable appears as Altera USB-Blaster (unconfigured) when first attached to your system. After it has been configured by the Quartus Prime software, it will appear as Altera USB-Blaster II (JTAG interface) and then Altera USB-Blaster II (SystemConsole interface). You might need to install drivers for each of these interfaces; follow the steps below to install the drivers.

You must have system administration (Administrator) privileges to install the USB-Blaster and USB-Blaster II download cable driver.

Driver Installation for Altera USB-Blaster

1. Plug the USB-Blaster download cable into your PC. The Found New Hardware dialog box appears.
2. Select Locate and install driver software (recommended).
3. Select Don't search online.
4. When you are prompted to Insert the disc that came with your USB-Blaster, select I don’t have the disc. Show me other options.
5. Select Browse my computer for driver software (advanced) when you see the Windows couldn’t find driver software for your device dialog box.
6. Click Browse, and browse to the <Path to Quartus Prime installation>\drivers\usb-blaster directory.
   • Note: Do not select the x32 or x64 directories.
7. Click OK.
8. Select the Include subfolders option, and click Next.
9. If you are prompted Windows can’t verify the publisher of this driver software, select Install this driver software anyway in the Window Security dialog box. The installation wizard guides you through the installation process.
10. When The software for this device has been successfully installed dialog box appears, click Close.
11. To complete your installation, set up programming hardware in the Quartus Prime software.

Driver Installation for Altera USB-Blaster II

1. Plug the USB-Blaster II cable into your PC.
2. Open the Device Manager, and right-click on the Unknown device under the Other devices branch.
3. Select Update Driver Software.
4. Select Browse my computer for driver software.
5. Enter the location of the Quartus Prime software USB-Blaster II driver files directory (<Path to Quartus Prime installation>\drivers\usb-blaster-ii) in the Search for driver software in this location field.
6. Click Next.
7. Click Install in the Would you like to install this device software? Windows security dialog box.
8. Close the Update Driver Software - Altera USB-Blaster II (Unconfigured) successful installation notification. The Device Manager now shows a new branch called JTAG cables with an Altera USB-Blaster II (Unconfigured) node.
9. Open the Quartus Prime Programmer. Within a few seconds, the JTAG cables branch displays two nodes: Altera USB-Blaster II (JTAG interface) and Altera-USB Blaster II (System Console interface).

The pin-out of the USB Blaster cable is such that it can be used for three different programming modes: AS, PS and JTAG, as shown in this pin definition table from the Intel FPGA USB Download Cable User Guide:

The important thing to note here is that programming via JTAG is temporary! My board came pre-programmed with something that cycles though the 4 LED's on the board. There's always a little fear of sending a new program that toasts your new FPGA (yes, this is absolutely possible!). So it is cool that upon power cycle, the original config is loaded back into the FPGA to confirm all us well. Fortunately my first program actually worked the very first time!

As with all development environments, Quartus has its own annoyances. I found it very difficult to simply: File - Create New Project and get something to actually work without a bit of fussing.

The first annoyance is the default directory. For example, in Visual Studio, the IDE is smart enough to know to actually create a directory for your project. Any you only need to type it once. Here, the default directory is the IDE, and projects are created there unless explicitly stated in THREE places. So the new Project Wizard starts here:

Be sure to append a project name to the directory:

Or better yet, I keep all my project in c:\workspace\ in this case for the new myFPGAgizmo project:

You can set the default location in: Tools - Options - General - Default File Location.

I created an empty project...

and did not add any design files...

This next step is important... the default device is set to "Auto". What this does is completely disables the Pin Planner feature needed later, giving an error:

Cannot display Pin Planner the current Compiler settings assign an AUTO device.

For a newbie like me.. the solution was not very obvious. To avoid this, change the default at new project time to EP4CE6E22C8

The tools are left as default:

On the final Project Wizard page, the summary is shown:

Tada! All done, right? Nope. The "Wizard" still does not actually complete a project.

Double-click on "myFPGAgizmo" to edit the code, and a nice, less-than-intuitive error pops up:

Can't find design entity "myFPGAgizmo".

Not exactly to most intuitive error message for a newbie. 

Good luck finding "Add Design Entity" in the menu. Here, you just need to know that a new Design File needs to be manually added (why the wizard does not do this, I do not know).

So from what I can tell:  a source "File" == "Design Entity".

File - New - Verilog HDL File:

Quartus does not give you an opportunity to name this file when it is first created. Only at save time will it prompt to give it a new name. Visual Studio users will not be impressed.

Now another important note: The name of the module MUST MATCH the name of the "top level" file name, and it is case sensitive. The "top level design entity" is that file first listed. You just need to know this. Otherwise the Quartus software gives the less-than-intuitive error message:

Top level design entity "myFPGAgizmo" is undefined 

Here the "myFPGAgimoName" needs to be the same as the file name "myFPGAgizmo":

So after dealing with those annoyances the learning curve, I was finally able to write some Verilog that I found in another tutorial (see page 14):

module myFPGAgizmo (x1, x2, f); 
  input x1, x2; 
  output f; 
  assign f = (x1 & ~x2)|(~x1 & x2); 
endmodule 

This is where things get interesting. It is one thing to write some code, but getting it to interface to the real world is what makes it fun! Normally I/O is abstracted through complex device drivers and API calls. However, it does not get much more direct in FPGA programming, as the actual pins on the chip are assigned to variables in our code! Even better, there's no bizarre renumbering that I find ridiculously frustrating in the world of Arduino programming. There's a single pin number. Ahhh. What bliss.

As can be seen in the schematic, Pin 87 is LED4, and Pins 88 and 89 are tied to keys (button switches) KEY1 and KEY2 (but yes, instead labeled S1 and S2 on the board). Yes, those are the actual pins numbers on the Cyclone IV - pins 87, 88, and 89. No big deal, right? Well, sure - but apparently not all engineers agree. Just google "pin numbering arduino" to see how many hours have been lost to frustrating abstracted re-numbering.

Once code is entered, it is compiled using the menu: Processing - Start Compilation. When the pins are not actually assigned, there will be a compiler warning:

Critical Warning (169085): No exact pin location assignment(s) for 3 pins of 3 total pins. For the list of pins please refer to the I/O Assignment Warnings table in the fitter report.

Click on Assignments - Pin Planner. (recall above, we explicitly assigned our chip part number, otherwise this feature is not available).  If you double-click in the Location column, a drop-down list will appear:

We need to assign the pins to keys and LED as shown in the schematic:

Simply close the Pin Planner and compile again. We're ready to send the FPGA code to our device!

Note the USB Blaster connection in the very first picture on this page.

Click Tools - Programmer. If the currently selected hardware says "No Hardware", click the "Hardware Setup" button (make sure your device is plugged inn, and drivers installed)....

In this case, I selected the USB Blaster by double-clicking on it.

To send the FPGA code to the device, select "Processing - Start" (or simply press the "Start Button"). If successful, there will be an indication in the progress box:

That's it! There's now an XOR gate programmed in the FPGA. Press S1 or S2 to have the LED got out. Press both or leave both unpressed and the LED1 will be illuminated. Cool.

Note we've programmed the FPGA via the JTAG connector on the board. When the board is power cycled, we'll lose these changes and the board will revert back to vendor ship default.


Note that if you find cheap Cyclone boards on flea bay, the most recent version of Quartus does NOT support the older chips! I sadly learned this after buying a cheap, bare-bones Cyclone II and then noticed it was not listed as a device option in the Quartus IDE. The latest version supporting the Cyclone II is Quartus version 13.0sp1 from 2013. (I wonder if side-by-side installs are supported? I didn't try)

Here's a chart of supported devices vs Quartus versions specifically the Cyclone series:

That's it for now... send me a message on twitter if you have any feedback / suggestions / notice any typos.


Resources, Inspiration, Credits, and Other Links:

• Altera - My First FPGA Design Tutorial 
• Quartus Prime Introduction Using verilog Designs
• UDemy - Learn VHDL and FPGA Development
• UDemy - FPGA Turbo Series - Implementing a UART
• Verilog HDL support for VSCode
• Verilog Tutorials and Examples at nandland
• Altera Cyclone IV from Numon Electronic Cyberport Store
• Resource file with documentation and samples
• Intel FPGA USB Download Cable User Guide
• Quartus Prime Download
• Altera Device Downloads
• Gnarly Grey UPDuino v1.0 Board
• A Look at TinyFPGA Boards
• UART, Serial Port, RS-232 Interface Code in both VHDL and Verilog for FPGA Implementation
• Altera-Lime Connectivity and DUC/DDC Design Example

Sino:bit Test drive & attempt to single-step debug with OpenOCD and GDB

Sino:bit - Arduino, OpenOCD and GDB?

A little while back, I responded to an offer to get a free Sino:bit from the nice folks at Elecrow. Well, it was not completely free; I paid $4 for shipping from China, as it was not really practical for me to pick it up. ;)

In case you've not heard - this is the Chinese version of the BBC Micro:bit - or more precisely, based on the Calliope mini, which is based on the Micro:bit. Me... I'm in favor of pretty much any technology that may help inspire the next generation of programmers.

Although there are a variety of ways to program this device, I followed along with the Adafruit instructions to use the Arduino IDE (and/or the VisualMicro add-in for Visual Studio).

Initial programming was really quite easy. There was one little instruction missing from the Adafruit site. Hopefully they will notice my tweet and make the correction. In short, the Arduino HT1632 libraries need to be manually added. So if you see an error like this:

...then simply add the library:

I like to turn on verbose compiling and uploading:

When doing so, a successful upload will look like this:

In particular, I noticed that a forked version of Open OCD is used to upload the sketch. The first thing that comes to mind when mentioning OpenOCD, is of course GDB! So I thought I'd see if I could get some single-step debugging working without the need for a potentially expensive hardware debugger.

One line to notice during the verbose compile / upload is the last line of the compile. Note that a unique directory is created for the binaries. In my case: ~\arduino_build_91191

The full line from my Arduino IDE looked like this:

C:\Users\gojimmypi\AppData\Local\Arduino15\packages\sandeepmistry\tools\openocd\0.10.0-dev.nrf5/bin/openocd.exe -d2 -f interface/cmsis-dap.cfg -c ; -f target/nrf51.cfg -c program {{C:\Users\GOJIMM~1\AppData\Local\Temp\arduino_build_91191/sinobit.ino.hex}} verify reset; shutdown; 

In order to launch OpenOCD to simply listen, and not upload - minor modifications are needed. Remove everything after and including the "-c program":

C:\Users\gojimmypi\AppData\Local\Arduino15\packages\sandeepmistry\tools\openocd\0.10.0-dev.nrf5/bin/openocd.exe -d2 -f interface/cmsis-dap.cfg -c ; -f target/nrf51.cfg  

Upon launching this in a DOS window, the resulting output looks like this:

Note that OpenOCD will not exit. It is waiting and listening for a GDB connection.

In my case, I could not find a suitable Windows GDB executable. So I ventured into the land of WSL - specifically Ubuntu. (I also wrote a little blog on OpenOCD on WSL Ubuntu). Once a local Ubuntu is installed an operational, GDB can be added:

sudo apt-get install gdb

Note that in WSL Ubunto, there's no C:\ drive and the slashes all go in the opposite directions. I went to my specific directory created by the Arduino IDE:

cd /mnt/c/Users/gojimmypi/AppData/Local/Temp/arduino_build_91191

GDB is launched like this:

gdb -d ./ -d /mnt/c/Users/gojimmypi/AppData/Local/arduino15/packages/sandeepmistry/hardware/nRF5/0.4.0/cores/nRF5 -f sinobit.ino.elf

If all goes well, when GDB is running and accepting commands, if will look something like this in the WSL Ubuntu window:

Due to the oddities of Windows vs Linux, I first ran these commands:

# C:\ is found in /mnt/c
set substitute-path c:/ /mnt/c

# There was an odd case problem in Arduino15 vs arduino15
set substitute-path /mnt/c/Users/gojimmypi/AppData/Local/Arduino15/ /mnt/c/Users/gojimmypi/AppData/Local/arduino15/

# make really sure the current directory is used
directory ./

Then connect:

target remote localhost:3333
monitor reset init

The resulting GDB window in Ubuntu should look something like this:

The OpenOCD DOS window should have updated, and look something like this, showing the successful connection:

At this point, things are really exciting! Ready to debug? Sadly, no. Typing the GDB "step" command results in the dreaded message:

Cannot find bounds of current function

I also tried to use the VisualMicro add-in for Visual Studio, no joy there, either:

Although it certainly works to compile and upload code in "release" (no single-step debugging) mode:

@TheFlyingSephyr also suggested trying the Embedded Studio IDE with the Segger hardware debugger. Perhaps another blog for another day...

On a side note, it might me interesting to peek at the elf file:

sudo apt-get install binutils
readelf -a /mnt/c/Users/gojimmypi/AppData/Local/Temp/arduino_build_91191/sinobit.ino.elf

In the end, it seems that you simply can't get to there from here when attempting to debug a "soft device".  :| If you have any ideas, please leave a comment or send me a message at gmail.

UPDATE: I've had a few replies regarding other debugging options. In particular a tweet from Tomas indicating that perhaps Mbed tools might help. Indeed there's some interesting info that shows using arm-none-eabi-gdb and pyOCD. Although I was able to get that toolchain installed and working:

I was not able to actually get single-step debugging working (nor does the Mbed instruction page indicate this is even possible). Note the error:

(gdb) step
Warning:
Cannot insert hardware breakpoint 0.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.

As show here:

Another more promising method (although considerably more complex and potentially expensive) - would be the hardware debugging method using JTAG. One of the key things needed here is of course is how to connect the debugger. Many thanks to Elecrow for the prompt reply on twitter for information on the Sino:bit JTAG pins:

What you cannot immediately see from the silkscreen is that those are pads and not through-holes. Another item on my wish list for version 2! (ok, let's make the proper wish: how about a actual header for JTAG connector!)

I'll create another blog page for the Sino:bit JTAG. My first attempt will be using my $2 Blue Pill STM32F103 board converted to a Black Magic Probe.

Overall the Sino:bit seems very cool, despite the problems with OpenOCD and GDB. It would be awesome if some sort of single-step debugging was possible - bit that certainly is not a showstopper. Most people, certainly not beginners - would never even attempt this type of debugging. Other changes I would make would be having a less intensely bright power LED, and making the 12 x 12 grid of LED's multi-color.


Resources, Inspiration, Credits, and Other Links:

• github - sinobit hardware
• StackExchange - How do I debug a Arduino Uno with gdb on a Linux pc?
• https://github.com/sandeepmistry/arduino-nRF5#selecting-a-softdevice
• Bash for Windows colors are unreadable with default terminal theme #7556
• GDB - Specifying Source Directories
• GDB - Setting Breakpoints
• stackoverflow.com: Why I do get “Cannot find bound of current function” when I overwrite the ret address of a vulnerable program?
• Nordic Developer Zone: debugging softdevice applications with gdb
• going beyond the arduino ide
• forum.arduino,cc - How do I use a Makefile?
• Compiling Arduino sketches using Makefile
• github sudar/Arduino-Makefile
• arm MBED CMSIS DAP
• Nordic Semiconductor adds Embedded Studio IDE support for nRF51 and nRF52 SoC development