I need to be able to build different versions of my code, one for debugging and one for “release”, for example.

The standard mechanism for doing this is to define, or leave undefined, various symbols that cause the compiler to include, or exclude chunks of source code.  The symbols are not in the code, but are submitted to the compiler when it is called.   So called the compiler with the flag -Drelease inserts a symbol called “release” in the compiler’s symbol table before it gets started.  Then during compilation the compiler can conditionally switch in, or out, chuncks of code based on whether this is “release” code or not.

Eclipse works this way too – only it doesn’t.

Here is a very simple program, to illustrate my vexing issue.   My conditional compilation variable is called “FOO”

The program is silly, and is designed to fail during compilation if x=0.  (If x=0 the compiler will detect that the program is null, and will signal a compiler error.)

The important part is at the top.   It says that if a symbol called FOO has been previously defined then the compiler should compile the statement “int x = 1”, and if FOO is not defined it should instead compile the statement “int x = 0”.

Elsewhere in the property definitions for this program I have defined FOO.   

Eclipse kindly grays out the code that it is going to ignore.  In this example something has gone wrong because Eclipse implies that x=1, but the compilation fails (little yellow exclamation mark) because clearly x=0.

Whatever I do, I get the compiler error.   What a time-waster Eclipse is!

We have had issues getting the debugger to work.  I discovered that it wasn’t so much that the connections were wrong, as Eclipse being very finicky.

When it falls into a trap before getting to main, it can be because: the code is expecting SEMIHOSTING, but gdb is not ready to catch.  If semi-hosting libraries are used in the firmware, then semi-hosting must be enabled in gdb.

Put another way, code will simply fail to start (trap at 0x0) if semi-hosting apparatus is not physically set up.

The following has to be  setup exactly right for semi-hosting to work:

If it hits a trap at 0x0 then there is no trap handler for semi-hosting, or there is no code loaded.

If the code should hit a breakpoint, but simply starts automatically, then it is perhaps because debugging has not been specified to the compiler, and it is not generating the debug handles.  It ought to look like this:

If user-breakpoints are being skipped then it might be because the code has been optimized away.  Turn all optimization off like this:

If it hits the breakpoint at main, but the source doesn’t show up then it probably failed to load the symbols from the elf file.   The spec should look like this.

If there are incorrect load symbol files, or no load symbol files specified, or the file names don’t look like the above, then close this dialog, close the project, re-open it, and refresh the projects and then see if the right file names are turning up.

To remove semihosting the following has to be done:

1. Remove the defined constants
   DEBUG_NRF_USER
   DEBUG
2. Remove the other linker flags: -mabi=aapcs –specs=rdimon.specs -Wl,–start-group -lgcc -lc -lc -lm -lrdimon -Wl,–end-group
3. Clear these check boxes
   
   and on the previous “debugger” tab: 
   

I have found a version of the Segger tools that appears to simply offer flashing, and erasing.

https://www.segger.com/jlink-software-beta-version.html

1. The RayTac module uses XL1/XL2 and not XC1/XC2.
2. RayTac pin 3 and nRF51822 pins 35+36 use different capacitors.
3. I think many pins are internally connected to ground and so they don’t appear on the module.

I think I have made a grave mistake.

Previously I connected the EVB1000 board to the Segger using a squid cable.  I managed to program it just fine.

Today I connected the EVB1000 to the SEGGER using the ribbon cable, making sure to connect it the right way around.  The pinout seemed identical.  The SEGGER responded, but the board didn’t.

So I connected the squid cable back and it communicated and loaded code, which is good, but puzzling

But now the DW1000 chip won’t answer the SPI line.   Have I blown up another one?

I think it was because I had connected the ribbon cable instead of the squid (and that’s the most likely reason). After pondering, maybe that 5V supply pin on the SEGGER ribbon is a bad idea? But last week I was trying to hook up the DW1000 SPI lines, and I wonder if they might be super-sensitive?

Today I have spent all day trying to figure out how to organise our project so that it can be archived and shared with the minimum of effort.   I’ve also set up David’s laptop ready to fetch projects from egit and run them.

I wrote it all down.

Using eGit in eclipse

Yesterday David gave me the new TS06.2 board.    Today I tried to figure out the connections and talk to it.

Having has a lack of joy with the TS06.2 I realized that it was important for David to be able to test the hardware too.   It would be good if I can make test programs and squirt them down the line to his house to poke at.

So yesterday I set up a spare laptop with a basic development environment so he could test the software.

At “Mimis” today David discovered that a couple of the jLink wires were crossed and with penknife and other stuff we happened to have in our pockets D fiddled it.

Although the jLink was now able to talk to the Nordic, and could apparently flash code into it, the code would not execute.   I’m now even more sure I have blown up the module.

The next step is to find a free sharable repository where we can exchange our code.

ALSO

Flashing binary (*.bin) files is possible with J-Link Commander.
Just start it the following way:

JLink.exe -if SWD -device nRF51822 -speed 4000

Then type:
J-Link>r
J-Link>loadbin <Path>,<DownloadAddr>