Multi-threading on the STM32L031 Nucleo with the Keil IDE

An earlier blog post showed multi-threading on the TI MSP432. Recently I have been working on an STM32L031 Nucleo board with the Keil ARM-MDK environment. I wanted to demonstrate multi-threading and so ported the code from the MSP432 to the L031. A section of the main.c file looks like this:





#define STACK_SIZE 128
__attribute__((noreturn))  void threadA(void);
__attribute__((noreturn)) void threadB(void);
__attribute__((noreturn)) void threadC(void);
static uint32_t StackA[STACK_SIZE];
static uint32_t StackB[STACK_SIZE];
static uint32_t StackC[STACK_SIZE];

void threadA()
{
	while (1)
	{
		static int State = 0;
		if (State == 0)
		{
			GPIOA->ODR &=~(1u << 0);
			State = 1;
		}
		else
		{
			GPIOA->ODR |= (1 << 0);
			State = 0;
		}
		delay(100000);
	}	
}
int main()
{
	// Initialize I/O ports
	RCC->IOPENR = 1; // Enable GPIOA
	pinMode(GPIOA,0,1); // Make GPIOA Bit 0 an output
	pinMode(GPIOA,1,1); // Make GPIOA Bit 1 an output
	pinMode(GPIOA,2,1); // Make GPIOA Bit 2 an output
	initClock();		// Set the MCU running at 16MHz
	createThread(threadA,StackA, STACK_SIZE);
	createThread(threadB,StackB, STACK_SIZE);
	createThread(threadC,StackC, STACK_SIZE);
	startSwitcher();
}

Three threads are created in this example and they each change the state of a bit on Port A. I should have used the BSRR register to set and clear the bits but for the purposes of getting the ideas behind multi-threading across this was sufficient. The createThread function takes three arguments: The thread’s start address, a pointer to the thread’s stack and the size of this stack. Stacks for the threads are simply declared as arrays of uint32_t’s.

The startSwitcher function starts the SysTick timer running, does some stack adjustments and enables interrupts. It does not return. The SysTick handler is written in assembler and it performs the context switch between threads.

Source code is available on github. I did not include the project (uvproj) files as they contain lots of path information that would not transfer to other systems. If you want to try this for yourself just create a project for the STM32L031 Nucleo in Keil and add the files from github. You should first remove the other source files in your project.

Breadboard Games 2021

Given the pandemic restrictions this year Breadboard Games will be delivered remotely. Participants will each receive a kit and work with a parent to assemble the gaming console. Remote support will be provided via video.

Instructions

This is a breadboard. It allows us to connect electronic components together by pushing them into the holes. In the centre region all the holes in column 1 are connected together inside the board apart from the gap in the middle. Columns 2 to 30 work similarly. You can see more about breadboards at this location


In the outer, between the blue and red lines, connections run horizontally within the breadboard. We usually use these areas to connect power supplies for our electronic components.

Lets begin by putting the black wires into the board as shown above. The top row of holes next to the blue line will be used to distribute the 0V connections for our circuit (the negative terminal on our battery). The connections are expressed in Row,Column terms as follows:

j6 to 0V (approximately directly above just next to the blue line)
j9 to 0V
a1 to 0V
a24 to 0V
a27 to 0V
a30 to 0V

A diode only allows electricity to flow in one direction. We include one here to protect our game in case somebody connects the battery pack in backwards. The diode has two wires : Cathode and Anode.

We want electrical current to flow into hole j7 so put the cathode in there and the anode just above the red line as shown.

Connect the red wire between j5 and j10.
The other component is a resistor. Resistors control the flow of electrical current. We are using this one to limit the brightness of our display so that the batteries last longer. The resistor connections between f9 and f16. Note the way the resistor sits in the valley between both halves of the breadboard.

The screen in our game is a “touch-screen”, just like a phone. We have to add a couple of wires to support this. The yellow wire goes from e10 to f13. The blue wire goes from d9 to f23

The purple wires are used to connect the buttons to the little computer in our game. They are connected as follows:
a3 to a18
a19 to a28
a20 to a25

The buttons go in next. Each button has two “pins” that are connected together electrically when you push down. The left button we will call simply “Left”, the rightmost button we will call “Right” and the middle buttonw we will call “Fire”. The connections are as follows:
Left: c1 and c3
Fire: c25 and c27
Right : c28 and c30

We are nearly done. The computer board that controls our game needs to go in next. Before you put it in be sure that all of the previous connections are correct. It is difficult to remove the computer boards if you need to correct any errors. Push the board firmly into the breadboard with the pin marked “3.3” (top left) in hole g5.

And now for the screen. Be very careful putting this in. It goes in row i. The rightmost pin of the display goes into hole i24. Push down on the pins only, not the glass. The glass will crack if you push on it.

Our game makes sounds. The buzzer is connected between a17 and 0V (just below the blue line). The longer leg of the buzzer (labelled +) goes in to a17.

The battery pack plugs into the board as shown above. Note the red wire is closest to the red line on the breadboard. The on/off switch should be just behind the display on the right hand side. If you like you can stick the breadboard to the battery pack using the adhesive backing on the breadboard. If you decide to do this be very careful as the adhesive backing is very strong.

All software used in this game is available on my github repository

Waiting for /CS

I have been working on an interface between an STM32G431 and a W25Q128FV SPI flash memory chip (128 Mbit/16MByte). The image above shows the memory chip on a breakout board with a surface mount capacitor next to it. Given the nature of breadboards and the wires used I’ve been running the memory interface at a reduced speed (1.3MHz). A PCB will be used at a later stage and which should allow for higher speeds.

Erasing the chip was presenting some problems. The code for erase was as follows:

void serial_flash::bulk_erase()
{
	write_enable();
	SPI->startTransaction();
	SPI->transfer((uint8_t)0xc7);	
	SPI->stopTransaction();
	while(read_status1() & 1); // wait until erase has completed
}

The chip must be put into “write” mode before the erase command (0xC7) is sent. The function exits when the “busy” bit in status register 1 is clear. While everything seemed ok, the function did not erase the chip. I took a closer look at the SPI bus using a logic analyzer. I have a very cheap logic analyzer which doesn’t have a very good trigger mechanism. My normal workaround for this is to put the area under test into an everlasting loop and then view the pins of interest on the logic analyzer. This is a problem for erase operations like this as the SPI flash chip has only so many erase cycles. As a precaution I change the command code to 0xd7 (not a supported command) which allowed me look at the SPI bus without harming the chip. I also commented out loop that polled the status register.

The write enable command (0x06) is plainly visible as is the “fake” chip erase command 0xd7. The CS line is driven low just before the 0x06 command and goes high some time after the 0xd7 command. This is not the correct way to erase this chip. The data sheet clearly states that the CS line must go high for a period after each command. It does not do this after the write enable command. The write_enable function is as follows:

void serial_flash::write_enable(void)
{
	SPI->startTransaction();
	SPI->transfer((uint8_t)0x06);	
	SPI->stopTransaction();		
}	

The stopTransaction function should drive the CS line high but it didn’t seem to be working. The relevant SPI code is:

void spi::stopTransaction(void)
{	
	volatile unsigned Timeout = 1000;    
	while (SPI1->SR & ((1 << 12) + (1 << 11)) );     // wait for fifo to empty
	while (((SPI1->SR & (1 << 0))!=0)&&(Timeout--)); // Wait for RXNE
	Timeout = 1000;    
	while (((SPI1->SR & (1 << 1))==0)&&(Timeout--)); // Wait for TXE
	Timeout = 1000;    
	while (((SPI1->SR & (1 << 7))!=0)&&(Timeout--)); // Wait for Busy		
	SPI1->CR1 &= ~(1 << 6); // Disable SPI (SPE = 0)
				
}

This should have worked but it clearly didn’t. Thinking about the sequence of events involved in the bulk_erase function it occurred to me that the call to startTransaction just after the write_enable command may actually be happening before the SPI peripheral had a chance to raise the CS line. The SPI peripheral is routed through GPIO port A in this setup. I noticed that I could monitor the status of the CS pin by reading GPIOA’s input data register and hence wait for it to go high. The stopTransaction code was modified as follows:

void spi::stopTransaction(void)
{	
	volatile unsigned Timeout = 1000;    
	while (SPI1->SR & ((1 << 12) + (1 << 11)) );     // wait for fifo to empty
	while (((SPI1->SR & (1 << 0))!=0)&&(Timeout--)); // Wait for RXNE
	Timeout = 1000;    
	while (((SPI1->SR & (1 << 1))==0)&&(Timeout--)); // Wait for TXE
	Timeout = 1000;    
	while (((SPI1->SR & (1 << 7))!=0)&&(Timeout--)); // Wait for Busy		
	SPI1->CR1 &= ~(1 << 6); // Disable SPI (SPE = 0)
		
	while((GPIOA->IDR & (1 << 4))==0); // wait for CS to go high
	
}

This produced the following output from the logic analyzer:

A high pulse can now be seen between the two SPI commands. As a final test, I replaced the fake “0xD7” command with “0xC7” and presto: erases now work.

Microbit V1 display driver

The image above shows a Microbit V1 connected to an ST7789 1.14′ display via a Kitronik breakout board. The SPI interface on the Microbit (NRF51822) is a little slow at 4MHz but it is ok for simple outputs as shown above. Code was developed using VSCode, PlatformIO the mbed framework. The full list of connections can be found in the file display.cpp which is available on the github repo over here

An NRF52832 with an ILI9341 display

The NRF52832 is a Bluetooth microcontroller from Nordic Semiconductor. Boards and modules based on it are available from a number of different suppliers. I got a few on Aliexpress that bear the Ebyte logo. These were pre-programmed (and locked) with a software image from Ebyte. As I planned writing my own code I had to first unlock the device. Normally I work with an STLink debugger (clone) but this is apparently not able to unlock the NRF52832. Fortunately I had previously bought a J-Link Edu probe and this able to unlock the module.

The next hurdle was to figure out which pin is which as the board labels are specific to some other application. With a bit of fishing around datasheets and poking with a multimeter I came up with this:

The pin numbers could now be related to port numbers in the NRF52832.

Next the device had to be connected up to the ILI9341 display module. This too was bought on AliExpress. It is an SPI device that includes a touch screen controller. The wiring to the NRF52832 module is as follows:

ili9341NRF52832Remarks
T_IRQP0_40 if screen is touched
T_DOP0_26MISO
T_DINP0_25MOSI
T_CSP0_5Chip select for touch interface (active low)
T_CLKP0_27SPI clock
SDO (MISO)N/C
LEDVia 10 ohm resistor to ground
SCKP0_27SPI clock
SDI (MOSI)P0_25MOSI
D/CP0_6Switches between data and command mode (0=Command mode)
RESETP0_7Clear to 0 to reset the display
CSP0_28Chip select for display (active low)
GND0V
VCC3.3V

MBed and Visual Studio Code / PlatformIO were used to write code for the device. Initially Mbed was used but it can be slow at certain times of the day so I switched to VSC/PlatformIO for local development. This was a little fiddly to set up but it worked out very well in the end. MBed OS was used as a basis for the code and a working demo is available over here.

Mbed does not have a board support library for this specific board however the DELTA DFBM-NQ620 board uses the same NRF52832 module and works fine.

There were a couple issues along the way:

The NRF52832 has a maximum SPI speed of 8MHz which is a little slow for a display like this.

The Touch screen controller does not work well with the 8MHz SPI clock rate so this is switched down to 2MHz temporarily when reading the touch interface.

The rats-nest final system is shown below.

The STM32F411 “Black Pill”

The STM32F411 “Black Pill” board is a step up in performance from the Blue Pill (STM32F103). It contains a 100MHz ARM Cortex M4F CPU with 512kB Flash and 128kB of RAM. The usual sort of peripherals are also included (ADC, Timers, SPI, I2C etc.).

The Black Pill board comes with a set of pads on the underside that can accommodate an SPI flash chip. I was interested in giving this a go so soldered in an ST Micro M25P16 device. This has 2MB of storage that is page programmable (256 Byte pages) and sector erasable (64kB sector size). It also supports a bulk erase function.

There were no great problems getting a driver going except for one thing: When NSS is released (sent high) by the SPI peripheral I found that I had to introduce a short delay in the SPI driver. Without this delay, the interface to the flash chip did not work when one transaction immediately followed another. This may be because the pulse never left the STM32F411, or because of bad wiring, or because the flash chip just needs a moment (the datasheet seems to suggest at lease 100ns of a pause). Anyway, it now works and the image below shows a data read transaction captured using pulseview (Thanks pulseview authors! 🙂 ).

You can just make out the narrow NSS pulses (approx 400ns) that were necessary for the system to work. This image was captured with the SPI bus running at a reduced speed to allow for the limited bandwidth of my logic analyzer.

What could this be used for? Well, a data logger perhaps, or a store for various image assets for a screen or maybe even some sounds. If you use this be mindful of the write cycle limitation of these devices and especially don’t put a write in a fast loop.

Code for this and other examples can be found over on github : https://github.com/fduignan/stm32f411

Green power

The operators of the national grid in Ireland provide information about the fuel mix used for electrical power generation. This is updated every 15 minutes and can be seen here http://www.eirgridgroup.com/how-the-grid-works/system-information/

Delving into the source for this page a little it is possible to locate the web resource for the fuel mix which, it turns out, returns data in JSON.

So, a little bit of building later….

ESP32 with a PL9823 LED

Followed by a little bit of coding:

#include <ArduinoJson.h>
#include <WiFi.h>
#include <HTTPClient.h>
#include <SPI.h>
const char* ssid = "XXXXXXXXX";
const char* password =  "XXXXXXXXXX";
StaticJsonDocument<1024> doc; 
#define COAL 0
#define GAS 1
#define IMPORT 2
#define OTHER 3
#define RENEW 4
float coal, gas, import, other, renew;
float domestic;

void setup() {
  SPI.begin(1, 4, 2, 3); // (int8_t sck, int8_t miso, int8_t mosi, int8_t ss)
  Serial.begin(115200);
  
  delay(1000);
  WiFi.begin(ssid, password);

  while (WiFi.status() != WL_CONNECTED) {
    Serial.println("Connecting to Wifi");
    writePL9823(0x00);
    delay(1000);
    writePL9823(0xffff00);
    delay(1000);    
  }
  Serial.println("Wifi ready");
  
}

void loop() {
  // put your main code here, to run repeatedly:
  if ((WiFi.status() == WL_CONNECTED)) { //Check the current connection status

    HTTPClient http;

    // Interesting discovery : setting the date/time to a future data returns the latest value
    http.begin("http://smartgriddashboard.eirgrid.com/DashboardService.svc/data?area=fuelmix&region=ALL&datefrom=17-Dec-2050+23:59&dateto=17-Dec-2050+23:59"); //Specify the URL
    int httpCode = http.GET();                                        //Make the request

    if (httpCode > 0) { // Http error?

      String payload = http.getString();
      Serial.println(httpCode);
      Serial.println(payload);
      deserializeJson(doc, payload);
      coal = doc["Rows"][COAL]["Value"];
      gas = doc["Rows"][GAS]["Value"];
      import = doc["Rows"][IMPORT]["Value"];
      other = doc["Rows"][OTHER]["Value"];
      renew = doc["Rows"][RENEW]["Value"];
      domestic = coal + gas + other + renew;
      Serial.print("Total (without export)= ");
      Serial.println(domestic);
      Serial.print("Renew = ");
      Serial.println(renew);
      Serial.print("% = ");
      Serial.println(renew / domestic);
      if ( (renew / domestic) > 0.5)
      {
        writePL9823(0x00ff00);
      }
      else
      {
        writePL9823(0xff0000);
      }
      delay(15 * 60 * 1000); // wait 15 minutes as that is the update interval
    }
    else {
      Serial.print("HTTP Error ");
      Serial.println(httpCode);
      writePL9823(0xff);
      delay(10000);
    }
    http.end(); //Free the resources
  }
}

void writePL9823(uint32_t Colour)
{
  // each colour bit should map to 4 SPI bits.
  // Format of Colour (bytes) 00RRGGBB
  uint8_t SPI_Output[12];
  int SrcIndex = 0;
  int DestIndex = 0;
  for (DestIndex = 0; DestIndex < 12; DestIndex++)
  {
    if (Colour & (1 << 23))
    {
      SPI_Output[DestIndex] = 0xe0;
    }
    else
    {
      SPI_Output[DestIndex] = 0x80;
    }
    Colour = Colour << 1;
    if (Colour & (1 << 23))
    {
      SPI_Output[DestIndex] |= 0xe;
    }
    else
    {
      SPI_Output[DestIndex] |= 0x8;
    }
    Colour = Colour << 1;
  }
  SPI.beginTransaction(SPISettings(2000000, MSBFIRST, SPI_MODE0));
  SPI.transfer(SPI_Output, 12);
  delay(10);
  SPI.endTransaction();
}

And hey presto!

A traffic light which is green when renewable power on the grid is greater than 50%, red otherwise. This could inform you when is a good time to turn on the clothes dryer for example.

I wouldn’t recommend that this be used to control devices directly as there are many ways it could be hacked.

The SAML10E16A: A Cortex-M23 MCU

SAML10E16A and a Segger J-Link EDU debug probe

This is my first Cortex M23 MCU. It is made by Atmel/Microchip which may lead to I/O synchronization oddness later but time will tell. Initial attempts to get this working with an ST-Link clone were not successful however the J-Link Edu works great.

SVD data was obtained from Atmel over at http://packs.download.atmel.com/

When you extract the SAML10E zip file you will come across this file: ATSAML10E16A.svd. This can be used to produce a header file with I/O structures using the utility svdconv.exe (available from Keil’s MDK installation). This is done as follows:

SVDConv.exe ATSAML10E16A.svd –generate=header

On my Linux system I added “wine” and the full path in front of that – you may not have to do this on your own system.

This produces a header file although not without some errors. The biggest problem seems to be in the area of the RTC. A little bit of manual editing fixed the “show-stopping” error in the generated header file. More investigation needed here however as other problems may lurk. Anyway, the header file was good enough to get a basic blinky program off the ground.

Blinky sources can be found over here https://github.com/fduignan/atmel/. I expect to add more in the near future.

Dublin Maker 2020+ badge.

Dublin Maker didn’t happen this year because of Covid-19. I had been working on a badge (unofficial) but then parked the project for a while. Recently I resurrected it and have begun building badges. Software is not complete yet and the documentation needs to be developed but the picture above shows an almost complete badge without the display fitted (it overlays the MCU in the middle of the badge). Just about all of the background hardware driver code is done.

The 2019 badge took a hardwired wired approach to multi-player gaming. While this worked, it was a little unreliable mainly due to low quality 3.5mm stereo sockets and cables. This badge uses an NRF24L01 radio module instead and it appears to work quite well. Also it is actually a little cheaper than the wired version. Other differences include a change to the MCU which features more pins and double the flash memory (32kB!!). The most notable change however is probably the use of a PCB. This was designed in KiCad and fabricated by PCBWay – a process that was surprisingly cheap, quick and easy.

Lets hope Dublin Maker 2021 takes place.