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> 

I’m going to see if I can connect the Nordic Eval board to the EVK eval board.

The first thing to do is to make sure that I have all the switch settings, and jlink connections recorded.

I was thinking of connecting the Nordic EVK to the DW EVK1000 board.  The EVK user manual (attached) has some words of wisdom on p12, and a diagram.

If I connect the Nordic to USB for power, flashing and debugs, and connect one of our batteries to DW1000 J7, what will go wrong?

 DC:

Do you know what the I/O voltage is on the Nordic eval board? It can anything from 1.8V to 3.6V. I think it must be 3.3V. That would be good, because the EVK1000 is running at 3.3V. Then the I/O voltages will be compatible. If the Nordic is running at 1.8V then there would be a problem because 1.8V wouldn’t drive the EVK1000 reliably and 3.3V from the EVK1000 to the Nordic board would overdrive it. Even if they aren’t the same the Nordic seems to be quite robust since we already did things to it that should have destroyed it but didn’t. On the other hand you don’t want to take unnecessary chances. Is there a schematic of the Nordic board or other documentation? If you think the Nordic board is 3.3V then go for it.

ML:

Here some stuff I uncovered.

HOWEVER I Fluked Vcc to ground on the Nordic when connected to USB and it was 2.978 which is weird.

GO or NO GO mission control? 

DC:

Go, because the reason there would be any damage is if the ESD diodes become forward biased.

Since the drop across a diode is about 0.6V, as long as the voltage on the input is less than 0.6V higher than Vdd / V+ (or more than 0.6V lower than GND / V-) it will be OK.
2.9V is pretty low but maybe the errors are adding up. Or maybe the regulator is set to 3.0V instead of 3.3V. It doesn’t matter; go ahead and try it, as long as the pins are connected correctly.

ML:

OooooKaaaaay   🙂 

<later>

ML:

So I’m out of my depth again.  The EVK1000 manual p21 shows the connections for SPI.  There is no chip-select pin.
 

Am I supposed to know what these SS1..3 pins are?  

DC:

These are the TotalPhase Cheetah pin descriptions.
2.1.4 SPI Pins
SCLK (Pin 7):
Serial Clock – control line that is driven by the master and regulates the flow of the data bits.
MOSI (Pin 8):
Master Out Slave In – this data line supplies output data from the master which is shifted into the slave.
MISO (Pin 5):
Master In Slave Out – this data line supplies the output data from the slave to the input of the master.
SS1 (Pin 9):
Primary Slave Select – the primary control line that allows slaves to be turned on and off via hardware control. (This SS is in the same location as the SS line of the Aardvark and Beagle products.)
SS2 (Pin 1):
Second Slave Select – an additional control line that allows slaves to be turned on and off via hardware control.
SS2 (Pin 3):
Third Slave Select – an additional control line that allows slaves to be turned on and off via hardware control.

So let’s find the SPI pins in Nordic’s  pca10001.h header file.

#define SPIM0_SCK_PIN     23u   /**< SPI clock GPIO pin number. */
#define SPIM0_MOSI_PIN    20u   /**< SPI Master Out Slave In GPIO pin number. */
#define SPIM0_MISO_PIN    22u   /**< SPI Master In Slave Out GPIO pin number. */
#define SPIM0_SS_PIN      21u   /**< SPI Slave Select GPIO pin number. */ 

Sig_Name  nRF51822_Pin  PCA10001_Pin EVB1000_Pin EVB_Sig_Name
SPIM0_SCK         23            P5.8             J6.7       EVB.SCK
SPIM0_MOSI        20            P5.5             J6.5       EVB.MISO
SPIM0_MISO        22            P5.7             J6.8       EVB.MOSI
SPIM0_SS                  21            P5.6             J6.9       EVB.SS1
GND                             P5.9             J6.10      EVB.GND
GPIO?                                            J6.4       EVB.IRQ

DC:

Do you have a schematic of the Nordic eval board? Then I can see what regulator they are using to see if it can supply the extra current. However, I”m almost certain that it can. Neither board draws a lot of average current.

ML:

I looked around for a Nordic schematic myself, and couldn’t find one.  I googled “scematic”  and “BOM” both on the web, and our shared documents.  Nada.

Maybe a AP7333-33SAG-7   It looks like an LDO 

DC:

The part number is for a 3.3V regulator so I think you’re correct. It can supply 300mA, which isn’t a lot, but probably enough. You won’t hurt anything by trying because it has current limit protection, so go ahead and hook it up.

I wondered what this “Smart Power” code was all about, so I did a bit of research.

In the process I tripped over a really interesting article dated May 15th, 2014 by Bob Cringely, called “Did the NSA help kill UWB?“.

The UWB startup that got the most press back then was called Time Domain and the name says a lot about how the technology worked. Rather than using specific frequencies UWB transmitted on all frequencies at the same time. The key was knowing when and where in the frequency band to expect a bit to appear. Two parties with synchronized clocks and codebooks could agree that at 10 nanoseconds after the hour at a certain frequency or range of frequencies a bit would appear if one was intended. The presence of that signal at that time and place was a 1 and the absence was a 0. But if you didn’t know when to listen where — if you weren’t a part of the conversation — it all looked just like noise.

There was a San Diego startup called PulseLINK that came up with the idea to try UWB not only through the air but also over wires. They reasoned that RF travelled through copper as well as it travelled through air. So they injected their UWB signal into the local cable TV system (without permission of course) just to see what would happen. Could they establish point-to-point and point-to-multipoint communications as an Over-The-Top network on the local cable plant? It worked. They created a gigabit network atop established cable infrastructure without the cable company even noticing it was happening.

One fascinating aspect of the PulseLINK test was that UWB, which is an electrical signal, was able to propagate throughout the Cox cable plant even though sections of the Cox network used optical signaling. They went from electrons to photons back to electrons again and the fact that was even possible came down to the fact that it was CATV, not IP. Had the cable system been IP-based every electrical to optical conversion point would have involved capturing packets, fixing them as needed, then retransmitting them, which would have foiled UWB. But in the rotgut world of cable there were no packets — just an analog signal carrying digital and analog data alike which was block converted from one medium to another and back. So the UWB data was converted and retransmitted throughout the cable plant as noise.