Have to compile for the appropriate soft machine or it won’t load

When my code was compiled without the soft machine it loaded into low memory which I happened to have previously erased using the nRFgo tool. It worked just fine.  However, if there was a soft-machine in low memory then during the flashing process it says: Error: Flash Download failed  –  “Cortex-M0”

With a soft-machine already loaded into low-memory, I recompiled it with the soft-machine option and it the loaded it and it worked fine.
So the moral of the story is:  If there is a soft-machine loaded in low memory, then the application has to be compiled knowing that, and has to be located above it.  If there is no soft-machine in low-memory then it can be compiled in the ordinary (sans soft-machine) mode and will run just fine.
Today I have been reduced to basics.  I can’t really make much progress until I have managed to get characters between a Nordic and a PC.

There is a program that allegedly does this called uart_example.  It’s really very simple, but I just can’t get it to work because these dongles are old, and incompatible with the software.  I have to see if there is a workaround.

Reduced to groping around the Nordic Developer zone I found this useful little contribution.

https://devzone.nordicsemi.com/question/701/pca10000-tx/

I just got stung by this too.
Turns out I have an earlier version of the PCA10000 board. Check your board to see if you have V1.0 like I do. If so, this fix is easy… once you know anyway.
Go to Includes/boards/pca10000.h. There is an #if /#else construct for selecting between board versions. Change to #if 0 for V1.0 and away you go.

So I made a new version of  pca10000.h changing the one critical character from a ‘1’ to a ‘0’!

I recompiled the program.  The dongle resides on COM7, so I launched putty at 38400 8N1 + DTR fc.  And hey presto.  Characters are echoed ok.

Success!!

I have to start somewhere writing code.  There is a stock piece of code from Nordic that claims to use a BLE library, plus a dongle to emit advertising packets from a PC.

The code is pretty simple, and the library is a DLL.  I have to arrange that the DLL ends up in the same directory as the executable before the program runs, but every time I clean the code it get’s deleted.  Then the program is simply silent.  It took a while to figure that bit out.

So far I seem to have managed to compile the code and get it to start the DLL.  It runs but doesn’t do anything.

If I run the code from a command line I get a bit more information than the zero I get from within Eclipse.

The dongle is actually on COM7.  Small code change.  Seems a bit better, but now what?

I think the Nordic dongle has to be programmed with some alternative code.  I have not found instructions to that effect yet.  Need to poke around.  Also, presumably the dongle needs to have the right sort of soft machine installed.

I have not found any help yet, but I notice that there are three hex files packaged with the C code.

I’ll use the nRFgo Studio tool to load it into the program space.  What soft machine is appropriate though?
Not made any difference?  Maybe it is working…?  What am I supposed to see?  Should my phone see some BLE device advertising?
Nope.  Nada!
Reading the fine print now.
Supported boards:  pca10000  nRF51822 development dongle (v2.1 or higher only)

Oh bugger.  

So I have to use the new eval board pca10001 for which they say:
pca10001/pca10003 nRF51822/nRF51422 evaluation board (v2.1 or higher recommended)
Good news, I have a V2.2.0 board.  So I flash it with the connectivity_evkit_115k2.hex and…
bad news, it still doesn’t work.

Now what?

I started seeing if I could get these Nordic eval boards to talk to my BLE phone.  Not yet is the answer.

The funny thing is that I’m having no trouble at all getting those little StickNFind things to show up on the phone.  I can even tell the phone to make them beep, or flash.

Now to be fair I don’t know what I’m actually doing.  I have downloaded some Nordic example coad, compiled it without error, and tried to run it.  There are actually seven different example BLE programs that I can compile and load, but none of them produces a thing.  Even the “beacon” code which is supposed to be about the same as a stickNfind doesn’t work.

So I reckon the next step is to see if I can get some radio sniffer program to report in.

So there seems to be a rather good packet sniffer program called Wireshark.  It seems to pick up packets from the FitBit on my wrist, and and and all of the StickNFinds.  But I’m not getting any data out of the Nordic board.  I think it is a fair guess that the software is not emitting anything.

I’ve tried both boards and neither produces any radio traffic that the sniffer can see.  This has to be something fundamental.

Started to try and debug the example code.  Two weird things:  1) the code seems very reluctant to load – the previous program resumes;  I can’t get the debugger to work.  This has to be something even more fundamental.  Retiring to read a bunch of stuff.

It is fundamental indeed

Dah,  There it is on page 2/35: “program the S110 Softdevice onto the chip using the….”.   The softdevice (the standard stuff that implements the BLE stack) has to be loaded spearately from my program.  There was I expecting it to be bundled with my program code, but of course you don’t want to have to load it every time, do you?  It resides in the top part of memory.

To program the softdevice into the 51822 you have to first install their special program called nRFgo Studio.  So… yet another download, and installation.

Then you have to get permission to download the Softdevice itself.  This requires credentials.  There are multiple softdevices.  S110 seems to be a stack for the “Peripheral” role, while s120 is the stack for the “central” role.  You can’t both initiate connections, and accept them from others!

So I install the S110 softdevice and notice that it consumes 88K, leaving only 168K for all the application code, and in our case, for the code we need to drive the DW stack.

nRFgo Studio: Downloading the S110 softdevice

Ah… that makes quite a difference.  I follow instructions and download the heart rate monitor simulator program.  It woiks.   PROGRESS!

Nordic Heart Rate Monitor Simulator

After playing around with this system for a while I have to say it doesn’t seem very robust!

Seems like we should put this in the blog for future reference.  

//Mik

———- Forwarded message ———-
From: David Carkeek <dcarkeek@gmail.com>
Date: Tue, Sep 16, 2014 at 10:26 AM
Subject: Marketplace
To: Mik Lamming <mik@lamming.com>

Marketplace (NPR) had an interesting section on how school children are being "tracked".

Skip ahead to the last third of the program.

I am so happy that the scope still works.  Pls thank the donor for me again!

You don’t need to follow the code, but for your edification its a pair of nested loops.  The outer loop never ends (line 1), calling the inner loop which selects characters from the sequence “A-Z” (line 3) and sends them to the uart (line 6) with a small delay (line 10) between each character.  
There is an arcane bit of code that quite honestly even I don’t understand now, that reverses the bits (I comment that line in, or out depending on the test I’m doing).  Wrapped around the line that outputs the character, I have statements that turn on and off the LED1, which I use as a scope trigger – just as you taught me.  (I am amzed I recall how to use the scope)
Here is the code which I have annotated.  I’m sure you really do understand it.

  1. while (true)  // never-ending outer loop
  2. {
  3.   for (b=’A’; b<=’Z’; b++)  // set ‘b’ to each of the asci characters in the range A-Z
  4.   {
  5. nrf_gpio_pin_write(ERROR_PIN, 1);  // turn on the LED as a scope trigger
  6.     simple_uart_put(b); // emit the selected character in variable ‘b’
  7.     // simple_uart_put(((b * 0x0802LU & 0x22110LU) | (b * 0x8020LU & 0x88440LU)) * 0x10101LU >> 16);
  8.     // to reverse bits I uncomment the line above, and comment out the one above it
  9. nrf_gpio_pin_write(ERROR_PIN, 0); // turn off the LED/trigger
  10.   nrf_delay_us(1000*100); // a delay to make characters come out at 10Hz
  11.   }
  12. }
No, the photo captions are not reversed.  It seems like the data is.  I am mystified.
I am pursuing two lines of inquiry as to why Nordic serial data is displayed as incorrect (junk) characters on the laptop.  Theory 1 is that the bits are in the wrong order;  Theory 2 is that the voltage levels are incorrect.

Bit Order

I can’t believe that after all these years I don’t know this.  It seems such a very basic thing, but now that I am poking around I find that very few people seem to know the truth.

So given the scope data, I had the same thoughts.  It looked like the bits were reversed, which is why I took a picture or 0x80 and 0x01.  To be honest I thought I remembered that serial data was always sent most significant bit (MSB) first, but this seemed to show LSB first.  To be sure I googled RS232 bit order and saw this.


The diagram and the text are not explicit about the bit order.  By that I mean, is the chracter in the above example 0x51 = ‘Q’, or reading in the opposite direction 0x8a = Š (Latin capital letter S with caron).   The latter seemed an unlikely choice for this example, which implies MSB-first is more likely.

The serial port has many pins. We will discuss the transmit and receive pin first. Electrically speaking, whenever the serial port sends a logical one (1) a negative voltage is effected on the transmit pin. Whenever the serial port sends a logical zero (0) a positive voltage is effected. When no data is being sent, the serial port’s transmit pin’s voltage is negative (1) and is said to be in aMARK state. Note that the serial port can also be forced to keep the transmit pin at a positive voltage (0) and is said to be the SPACE or BREAK state. (The terms MARK and SPACE are also used to simply denote a negative voltage (1) or a positive voltage(0) at the transmit pin respectively).When transmitting a byte, the UART (serial port) first sends a START BIT which is a positive voltage (0), followed by the data (general 8 bits, but could be 5, 6, 7, or 8 bits) followed by one or two STOP BITs which is a negative(1) voltage. The sequence is repeated for each byte sent.


But then this article seemed to be explicit, though we don’t know the authority of the source.  Obviously it makes sense to look at the official RS232 specification which I anticipate is inpenetrable.  The article says:

Assume we want to send the letter ‘A’ over the serial port. The binary representation of the letter ‘A’ is 01000001. Remembering that bits are transmitted from least significant bit (LSB) to most significant bit (MSB), the bit stream transmitted would be as follows for the line characteristics 8 bits, no parity, 1 stop bit, 9600 baud.
LSB (0 1 0 0 0 0 0 1 0 1) MSB

So that suggests that it is indeed LSB first with optional parity and stop-bit.  So my bits would seem to be reversed.  This seems pretty unlikely huh?

Here for comparison is my scope image of ‘A’ allegedly with even parity.

Character ‘A’
Character ‘C’

Voltage
So now onto my second line of attack.  The example code from Nordic seems to suggest that it is OK simply to connect the output of the Nordic Tx GPIO to the input of the laptop serial.  I have done that, and used both a genuine serial port, and a USART->USB converter – the latter on both laptops.  To the extent that I can see, I get exactly the same results – junk.  
My bits appear to be about 2.7 volts peak to peak, and the standard suggests that +25 to -25 is the required level, for which I’d need some sort of level shifter, like a MAX232 chip.  But that flies in the face of what they imply in the Nordic example.

More investigation required.

I started to persuade the ARM chip to emit characters out its UART.  I connected the output of the ARM UART to the UART on my PC and after some fiddling around… didn’t get a thing.

Connections to laptop and scope

First issue, there isn’t a serial port on my new laptop.  Had to dig out my old USB->Serial cable.  Then of course none of the drivers work.

Still nothing, but then I discovered I was monitoring the wrong pin.  OK.. progress!  There is stuff coming out.  But it’s garbage.

Here’s what it says in the documentation for the Nordic UART example program.

The UART Example demonstrates basic UART usage for communicating with a PC terminal. It transmits and receives data through the configured pins as a serial device. The configure pins needs to be redirected to a COM port (terminal programs like putty can listen to this COM port through a terminal session). When the program starts it will transmit “START: ” through this serial device usingsimple_uart_putstring and this should be visible on the terminal. All typed characters on this terminal will be transmitted to the program through simple_uart_get and when an exit character ‘q’ or ‘Q’ is typed the program will end into an infinite loop after transmitting “EXIT!” on a new line of the terminal.

Tried all the usual things, baud rate, stop bits, parity…  still garbage.

Now I dragged out the ‘scope.  Used one of the LED pins as a trigger.  I made a program that outputs all characters from 0..127 at 100ms intervals.

simple_uart_config(RTS_PIN_NUMBER, TX_PIN_NUMBER, CTS_PIN_NUMBER, RX_PIN_NUMBER, HWFC);  // hardware flow-control = false
nrf_gpio_cfg_output(ERROR_PIN);
while (true)
{ for (b=0; b<127; b++)
{
nrf_gpio_pin_write(ERROR_PIN, 1); // trigger for scope
simple_uart_put(b);
nrf_gpio_pin_write(ERROR_PIN, 0);
nrf_delay_us(1000*100);  // a respectable pause
}
}

The scope showed the bits coming out like this.  i.e. a byte value of 0x01 actually appears on the scope like this.

Character code 0x01 (no parity bit)
and 0x80 looks like this.
Character code 0x80 (no parity bit)

Now the PC has decided that it won’t listen to the USB->UART COM any more.

Connected using a regular serial connection to my old laptop.  Same issue, so that rules out the USB->UART problem.  The result is garbage.
Confused, but at least the development environment is reasonably easy to use.
Looking at those traces I don’t see any start, stop or parity bits.  Even with everything turned off I ought to be seing a (low) start bit, and space for a parity bit.
The UART section of the reference manual talks about parity and a stop bit, but I don’t see any such thing being generated.
Found how to turn on even parity.  Still getting garbage.  I’m out of bullets?  Clearly there is something fundamental that I don’t understand here.

So what could it be?

A google of Nordic  UART Example shows that a lot of people are having problems.  My problem at least seems to be unique though.
The UART signal is 0 – 2.7V which may not be enough to post into a laptop without some extra hardware I guess.  However, the example suggests that just looping the correct wires across ought to work.
Only one pin TX, which is pin 9 on the eval board has any data on it, and I have connected that to pin 2 (rx) on the serial port of the laptop.  The only other pin I have connected is ground.  That seems right.

Hello World in embedded space is something that just blinks a LED.  My version is called MikBlinky.  To compile and run this code on a Nordic PCA10001 eval board you need to do the following:

  1. Download this code from our shared directory at Google.
  2. Unpack it to this place.
    ** If you don’t have this place already set up then you probably didn’t manage to install the Nordic SDK   nrf51_sdk_v6_1_0_b2ec2e6.msi and you should have another look at this blurb.  You need to have all the Nordic libraries and stuff set up in the right place or the compile won’t find them.
  3. So, assuming you have it in the right place now, de-compress it.
  4. Now drill down into the mikBlinky directory and find the file blinky.uvprojx.  Note the “x” on the end which signifies it is a uVision5 project.   
  5. Double-click on blinky.uvprojx to open the uVision IDE and load the program into the workspace.  You should see the main loop of my program. 
  6. Compile it by clicking on the Build Target menu.  You can also press F7.
  7. Now plug the PCA10001 board into the USB socket of you computer.  It ought to be discovered. 
  8. Now you can send the program to the PCA10001 to be flashed and started by clicking on the Download menu item.
  9. Now you can fiddle about with the code (change some of the delays for example);
    F7 to save changes and compile them, Download to flash and watch the changes.

David and I met after my long summer “vacation” in England. I guess I started work on TS06 yesterday Sept, 8th. Today, of course, we can expect semen to be all over the sidewalks of SF because Apple announce their iWatch today. How has this company managed to get such blatant world-wide free advertising?

Objective

Basically we are trying to make a smaller version of TS05b with the following improvements:

  1. Better ranging using the DW chip 
  2. Better power utilization, maybe incorporating some on-board generation capabilities 
  3. Smaller – with a view to a wrist worn device 

There are a bunch of other little changes, but these are the fundamental ones.

Target Processor issues

So the first job was to figure out the plan of attack. The DW EVK uses an STM32F105 ARM chip, a Cortex-M3 core, as the processor. It has 256K flash, and 64K RAM and a maximum CPU speed of 72 MHz.
We are going to use a seriously more constrained processor – the Nordic nRF51822 BLE chip – because it has BLE.  It is only a 32-bit ARM Cortex M0 processor with 256kB flash, and only 16kB RAM. The BLE stack consumes a lot of space and we have only about 180K left for our code. The CPU speed is 16 MHz. Let’s hope it can handle the interrupts.
So my major worry is that the DW stack soaks up a lot of RAM for buffers and so forth and we run out. So the first goal is to answer this question, and until we have an answer it makes developing anything more than minimal hardware a potential big waste of time.

Setting up Keil IDE – Day #2

I’ve spent a lot of time trying to set up Eclipse for the Nordic and it has been quite a struggle. I suceeded but I’m not feeling confident that it is stable – or that I could do it again, but maybe I’ll have to.
Unfortunately the propreitary system from Keil system costs $9K, but it looks like it has some decent libraries and a RTOS which could be useful. It would be good to evaluate the Keil system and decide if all those apparent advantages are real. Yet again David has worked some kind of magic that was way beyond my capabilities and located a system we can evaluate for an extended period. Our problem now is downloading it and trying it out. It consumes 5GB, takes 2 hours to download, and has totally maxed out the laptop I was going to use to evaluate it.

Installation

  • Install mdk511a.exe  When it finishes the Pack Installer will start up and you’ll notice that there are no Nordic devices.  Quit the Pack Installer for now.
  • Install Legacy support mdkcm510.exe
  • Install nrf51_sdk_v6_1_0_b2ec2e6.msi from here.

    making sure to include the nRF51822 examples,

    Make sure to include nRF51822 examples

    and make sure that the nRF Device Family Pack is going to be included

  • and at the end accept the CDC OB CDC Driver package,
    and accept the terms of the nRF_device Family Pack

    Not that there are no Nordic devices
  • Start uVision and select Project/Manage/Pack Installer and make sure that the appropriate Nordic parts, and the STMF105 (DecaWave) are installed.  If not install them.
  • Now you have to make a valid license.  To do that right-click run-as-administrator the new Keil iVision5 system you have just created.
  • Click File/License Management
  • Copy the number out of the CID field
  • Disable Virus Checking, start the KeyGen, paste in the CID, and click generate.
  • Copy the key that gets generated in the bottom field of the KeyGen into the New License ID Code field of the License Manager, and press Add Lic
  • A license key will be generated and you can verify the expiry date.