Cerbuino Bee fans…trying to determine whether Cerbuino Bee supports just a single SPI channel. I have a Cerbuino Bee board that seems to have a bad SPI channel, but wanted to test to be sure, so I set up a side-by-side test with 2 Bees, both updated to the latest firmware, loader, and TinyCLR versions (4.3.4/4.3.6).
On one board, using Nicholas3’s SPI WS2811 code (https://www.ghielectronics.com/community/codeshare/entry/649), I can make some WS281* blinkies blink. Using the board with the suspected bad SPI channel, the blinkies do not blink, whether I use SPI1 on the Gadgeteer socket via an Extender module, or via the Arduino headers (Pin 11 on the D side, if I’m reading the schematic properly). Not sure if there is a better way to troubleshoot, but this seems to confirm that SPI1 is toast.
My question is whether there’s another SPI channel on Cerbuino Bee I could try. From the schematic (http://www.ghielectronics.com/downloads/schematic/FEZ_Cerbuino_Bee_SCH.PDF), it looks like the answer is no, but I don’t fully trust my reading skills. 
@ devhammer - What Gadgeteer socket number did you use with SPI1?
@ devhammer - Never mind. Looks like only SPI1. SPI2’s MISO is taken by SD card.
Back to SPI1 issue, have you tried N18 display or any other S socket modules?
No, haven’t tried N18. Good idea. I’m probably getting myopic from staring at too many blinkies. 
Will give N18 a shot with both boards.
@ Architect - OK, tested with N18. On the “good” Cerbuino Bee board, N18 is initialized and shows what looks like a noise/static pattern. Drawing a rectangle:
displayN18.SimpleGraphics.DisplayRectangle(GT.Color.Blue, 5, GT.Color.Red, 5, 5, 50, 100);
works as expected.
On the “bad” Cerbuino Bee board, N18 is initialized and shows a blank white screen, and calling DisplayRectangle has no effect.
Seems like the SPI channel is indeed dead. 
Will just have to set this board aside for non-SPI tasks, I guess.
Did it ever work before, or you don’t know?
I would do another visual inspection. Maybe there is a solder jump or something.
@ devhammer - If you activate the GPIO of those pins (putting an LED on them and setting them high), do they function?
It’s been a while (I had set the board aside when I first encountered the problem, but that was months ago), but I’m pretty sure the SPI channel worked before.
Nothing obvious, in terms of solder bridges or such.
Tried it in a Gadgeteer project using this code:
namespace SPIPinBlink
{
public partial class Program
{
OutputPort LED;
bool LEDStatus = false;
// This method is run when the mainboard is powered up or reset.
void ProgramStarted()
{
Debug.Print("Program Started");
LED = new OutputPort(Cpu.Pin.GPIO_Pin11, false);
GT.Timer timer = new GT.Timer(1000);
timer.Tick += timer_Tick;
timer.Start();
}
void timer_Tick(GT.Timer timer)
{
LEDStatus = !LEDStatus;
LED.Write(LEDStatus);
}
}
}
but ended up hanging the board, and so far the only way to get it back is to re-flash the loader and firmware.
Will try a plain NETMF project and see if I can get it to work.
@ Aron - Just tried in plain NETMF, using the following code:
using System;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using System.Threading;
namespace SPIPin_Blink
{
public class Program
{
static OutputPort LED;
static bool LEDStatus = false;
public static void Main()
{
Debug.Print(
Resources.GetString(Resources.StringResources.String1));
LED = new OutputPort(Cpu.Pin.GPIO_Pin11, LEDStatus);
while (true)
{
LEDStatus = !LEDStatus;
LED.Write(LEDStatus);
Thread.Sleep(1000);
}
}
}
}
and as in the Gadgeteer attempt, it seems to hang the board.
Interestingly, when I plugged the LED into GPIO_Pin11 and GND, the LED glows dimly, even before deploying the project. Same for GPIO_Pin10 and GPIO_Pin12, both of which are also SPI pins according to the schematic. And if I test on GPIO_Pin12, it also hangs.
If I use the exact same code as above, but use a non-SPI Pin (I tested on GPIO_Pin9), it works fine.
Any further suggestions?
@ devhammer - Which revision of the board are you using? I will be further able to investigate when you can give me the board revision so I can know which schematics to reference.
The “bad” board is Cerbuino Bee rev. 1.2.
I double-checked the working board and it is also rev. 1.2.
@ devhammer - Those pins are also connected to pins D11 ~ D13 on the digital header. Do you happen to have anything connected to those pins?
Actually, those ARE the pins I connected to, since that was easier than using an extender.
@ devhammer - :-[ oops… I did not notice that you said you used those pins… I thought you were using the socket. Do you have an easy way to try the same test but with the socket?
Yep. I’ve got an extender module I can hook up. Will reply back with results shortly.
Connected with an Extender module on socket 1, using the following code, blinking an LED works fine (using Pin 3 on the extender):
Interestingly, if I switch to pin 7 on the extender (should be the same as pin 11 on the header), and use this code, it also works:
```cs]LED = new OutputPort(GHI.Pins.Generic.GetPin('B', 5), LEDStatus);[/code
and it also works if I switch the LED over to pin D11 on the header.
Appears that the GPIO works on pin D11 if I use GHI.Pins.Generic.GetPin, but not if I use Cpu.Pin.GPIO_Pin11.
@ devhammer - I suspect the reason that the board locked up was due to the method of how you called the GPIO port. When you used this code:
you were calling the 12th pin of the processor which is PA11 and not PB5. PB5 is the 21st pin. PA11 and PA12 of this processor are actually the USB signal lines which was why you needed to reflash to fix the board.
I ran the following code as a Gadgeteer program and the pins blinked fine on my board. See if these will work on your board as well.
```cs
using System;
using System.Collections;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Presentation;
using Microsoft.SPOT.Presentation.Controls;
using Microsoft.SPOT.Presentation.Media;
using Microsoft.SPOT.Presentation.Shapes;
using Microsoft.SPOT.Touch;
using Microsoft.SPOT.Hardware;
using Gadgeteer.Networking;
using GT = Gadgeteer;
using GTM = Gadgeteer.Modules;
namespace ForumTest01
{
public partial class Program
{
OutputPort LED11;
OutputPort LED12;
OutputPort LED13;
bool LEDStatus = false;
// This method is run when the mainboard is powered up or reset.
void ProgramStarted()
{
/*******************************************************************************************
Modules added in the Program.gadgeteer designer view are used by typing
their name followed by a period, e.g. button. or camera.
Many modules generate useful events. Type +=<tab><tab> to add a handler to an event, e.g.:
button.ButtonPressed +=<tab><tab>
If you want to do something periodically, use a GT.Timer and handle its Tick event, e.g.:
GT.Timer timer = new GT.Timer(1000); // every second (1000ms)
timer.Tick +=<tab><tab>
timer.Start();
*******************************************************************************************/
// Use Debug.Print to show messages in Visual Studio's "Output" window during debugging.
Debug.Print("Program Started");
LED11 = new OutputPort(GHI.Pins.Generic.GetPin('B', 5), LEDStatus);
LED12 = new OutputPort(GHI.Pins.Generic.GetPin('B', 4), LEDStatus);
LED13 = new OutputPort(GHI.Pins.Generic.GetPin('B', 3), LEDStatus);
GT.Timer timer = new GT.Timer(1000);
timer.Tick += timer_Tick;
timer.Start();
}
void timer_Tick(GT.Timer timer)
{
LEDStatus = !LEDStatus;
LED11.Write(LEDStatus);
Thread.Sleep(100);
LED12.Write(LEDStatus);
Thread.Sleep(100);
LED13.Write(LEDStatus);
Thread.Sleep(100);
}
}
}
@ Aron - OK, so that code works on my board. I set up an RGB LED to test with, and it blinks all three colors, both on the header pins (D11, D12, D13) and on socket one (extender pins 7, 8, 9).
Back to the original question…what, if anything, does that tell us about the status of the SPI functionality on the board? Any other tests I can run to troubleshoot that?
Thanks!
@ devhammer - do you have a data bus analyzer? You could hook up your analyzer to the N18 screen and see if the data is the same between the two boards. If the pin is working, but the N18 is still not functioning, then the processor’s SPI controller is probably damaged.
