I am working with a G120 on a custom board. I’m using Visual C# 2010 Express & 4.2 SDK & can deploy & debug successfully. I have observed 2 issues that I think might be related.
From a cold start, the device is recognized by Win7 via USB, but none of the tools can talk to it (VCE, Fezconfig 1.0.1.0, MFDeploy 4.2.0.0). The GHI updater for G120 (1.0.4) can always see the device & talk to it. I run the GHI updater, which updates everything (except GHI b/l, I believe) and thereafter all the other tools work fine, as long as the device is powered.
In what I think is a related behavior, any application that I deploy to the device persists only until power is cycled.
I’ve been able to deploy with VCE, then use FezConfig to capture a hex file of my app. After power cycle, I need to run GHI Updater again. Then I can successfully deploy the hex file with FezConfig (& sometimes with MFDeploy). Unfortunately, once again, this only persists until the next power cycle.
Any ideas? Running the GHI Updater every time is a PITA but not being able to retain an image across power cycles is clearly a deal-breaker. Help?
In case this sheds any light, this is the output of the GHI Updater:
– Log –
Connecting to device…
GHI Boot Loader Interface found at Port#: COM4
GHI Bootloader Version: 1.01
Device will be updated automatically! DO NOT disconnect or turn off the device!
Erasing…
Erase successful!
Updating TinyBooter. Please wait…
Update successful!
Disconnecting COM4
Rebooting…
TinyBooter updated sucessfully. Version number: 4.2.11.1
Updating Firmware. Please wait…
Deploying C:\Program Files (x86)\GHI Electronics\GHI Premium NETMF v4.2 SDK\G120\Firmware\Config.hex … successful!
Deploying C:\Program Files (x86)\GHI Electronics\GHI Premium NETMF v4.2 SDK\G120\Firmware\Firmware.hex … successful!
Deploying C:\Program Files (x86)\GHI Electronics\GHI Premium NETMF v4.2 SDK\G120\Firmware\Firmware2.hex … successful!
Rebooting…
Firmware updated sucessfully. Version number: 4.2.11.2
Updating TinyBooter and Firmware is complete!
You may have something there, thank you. I can’t post a schematic though.
I see that the custom board has no pull-ups on the mode pins, allegedly because the designer saw none on the reference design. I’m having those added.
I also noticed something very significant that’s probably been there all the time. After leaving the board disconnected from power for a long time (not sure yet how long), when I powered it up it began to run the last app I had been working on in VC#E! When I cycled power, nothing. When I let it sit for another long time, it (usually) runs my app.
I had not noticed this before, because I’m usually not cycling power, especially as mentioned in my OP that I’d need to run the GHI Updater again.
So now I’m pretty convinced that the application is being retained, but it’s just not being run (most of the time).
I’m wondering if there’s some massive capacitance or something on this board (combined with no pull-ups on the mode lines) that causes the G120 to restart from a power cycle in either GHI boot loader, TinyBooter, or some internally unstable state. Toggling the reset line to the G120 doesn’t help.
Any suggestions on how I might zero in on this? As some of you can probably relate, this is currently seen as a “software” issue, at least until I can prove otherwise.
Bit hard to offer much else without seeing at least some of the schematic.
Other option maybe taking to it someone with a working custom board but that depends on where you are etc.
Sounds like a good start copying the reference design as much as possible.
I don’t think the LDR Pins Needs to be pulled up.
On the G120HDR they are Floating as well.
But wasn’t there an issue with one of the analog in Pins, which must not be pulled to gnd on Startup.
I think it’s listed in the release notes of the G120 firmware or SDK.
My thoughts are go back to something really simple to make sure the app works - a simple LED blink for example, that doesn’t take much to initialize after power on. Make sure you test it just externally powered by a non-PC power supply (so debugging doesn’t get in the way) as well as when connected to a PC.
Thank you all for the suggestions. The valuable information in this community has probably been the main reason I haven’t pitched in the towel on this whole project.
In fact it is a “blink-the-LEDs” test app. Based on experience to date with the tool chains, revolving APIs, etc., I set a low bar for this project. Yes, I’ve tested with external supply & no USB. The behavior seems to be unaffected by that.
It may be that the G120HDR was the reference that was used by the designer. So that would explain why there are no pull-ups on those lines.
Thanks for the tip about some line that must be handled carefully on power up. I’ll search the docs but please do reply if you remember anything that will shrink the haystack or enlarge the needle.
Thank you, yes, I do have a thread sleep. Again, thanks to a tip I found here on the forum.
I’ve made some measurements & think now that I can rule out a slow droop power rail.
I think I located the reference that Reinhard mentioned about a pin that must not be pulled low at power on. The G120 user manual v1.0 makes exactly this statement about pin 59 (P1_30 AD4/COM4 OE) on page 17. I checked our schematic & it is floating.
So at this point, the behavior seems somewhat random, which would tend to indicate a pin state issue at power on.
I’m working with Gerry on this product and got a suggestion from GHI to read up on SPI functions.
I may have found a problem. In the G120 manual there is a section (see below) that specifically says to use a chip select if using SP2 as this is also the flash memory interface. I looked at the schematic and I see the traces going from SP2 to the Bluetooth??? I don’t know if this will be fixable just by implementing the code below but I’m skeptical. Has anyone had experience with this? See section from manual below, along with attached image of partial schematic.
7.9. SPI
G120 supports three SPI interfaces, SPI1, SPI2 and SPI3. SPI Bus is designed to interface
with multiple SPI slave devices, the active slave is selected by asserting the Chip Select line
on the relative slave device.
Important note: SPI2 is shared internally with the flash memory G120 uses. Using a chip
select is required with devices connected using SPI2. Improper use of SPI2 will cause G120
to not boot or not work properly. The use of SPI1 is recommended.
using System.Threading;
using Microsoft.SPOT.Hardware;
public class Program
{
public static void Main()
{
SPI.Configuration MyConfig =
new SPI.Configuration(Cpu.Pin.GPIO_Pin1,
false, 0, 0, false, true, 1000, SPI.SPI_module.SPI1);
SPI MySPI = new SPI(MyConfig);
byte[] tx_data = new byte[10];
byte[] rx_data = new byte[10];
MySPI.WriteRead(tx_data, rx_data);
Thread.Sleep(Timeout.Infinite);
}
}
@ michellemoline - no code will fix the problem if the hardware has an issue.
Do you have chip select to your Bluetooth module? Dies the module follow the spi standard and it releases the miso? Do you have pull up on the chip select pin to keep the Bluetooth module from using the spi pins on system power up?