I’m using the G400-D V1.2 module that came with my G400-D best test kit. My board is using a Newhaven Display (PN: NHD-4.3-480272EF-ATXL#-CTP) connected directly to the module. I have verified the pins are correct from the module to the 40pin.
When powering the system I’m not getting the standard dos style loading screens that I am used to seeing on the EMX modules. Does this module come with software present or must I load it right out of the package? The screen back-light powers up and the screen just flickers a bit.
Any help as to what may be the problem would be great.
what firmware? Read the release notes, I suspect you might find a hint - I think there was a decision to turn off LCD by default so you won’t see that boot message. I can’t confirm as I don’t have the SDK on this PC
I’m using the G400-D on my own PCB. I’m noticing now that there may have been a few changes to the PDF specification document mid development.
I’m looking now at the PWR_EN, NRST, and NRTST pins. Right nows is difficult to determine if the chip is running or now. Since I should be seeing data on the screen and the connections look to be right, I’m leaning towards thinking the chip is not running.
Thanks for the info and help. I’m looking at the G400-D brochure and it doesn’t identify the function of pin 31 or the port number for the Atmel chip.
When connecting the board to the computer via the USB device pins it is not detected. I’m going to attempt to put the device into bootloader by grounding P11 and see if it is detected then.
Anyone have experience with a stock G400-D showing up when connected to a windows PC right out of the box? Or do I have to have it in bootloader mode? I’ve verified the connections to the USB Device pins.
Ok, so I’ve been playing with my setup and whether I ground PA11 on reset or not, the board is detected by windows but I’m unable to find a driver that allows the device to be seen by the FEZ Config tool.
I’ve followed the instructions on the developers page and haven’t been able to get the software to recognize the device. I have tried to get this going on a 32bit Windows XP PC and a 64bit Windows 8 PC without luck. External power to the device as well.
hehe, I had my PA11 to GND for 20 secs+ since I was waiting for the driver to install. I hope there’s no long term effect.
Edit: to me it seems you need to get the bootloader driver working, because you may actually need a netmf install on it (SAM-BA). If you can get on to testing the HDR you’ll be able to see that. Can you explicitly tie PA11 high?
Since I’m still using my board (not the HDR), PA11 does have a 4.7K pull-up on it. On my Windows 8 system I do have the bootloader driver installed and when I run the SAM-BA software app it seems to open and connect correctly. I’m not sure where to go from there since I can’t see any instructions specifically for this tool.
Sorry about the unorganized thread. My problem started out with some confusion about the LCD connections and signal. Basically, in my custom board the LCD screen was displaying a white screen and no boot screen. It looks as though the LCD pins are turned off by default on the D400 and thus I need to use the FEZ Config Tool in order to turn them from I/O to LCD.
Currently, I’m attempting to use the FEZ tool and have been unable to get it to connect. After some debugging with Brett, it looks like my board is continuously entering bootloader mode based off the VID and PID that he was getting when his boards boots. No matter what I do, the board boots into the bootloader mode and so I have been unable to proceed with updating the firmware of using the FEZ tool.
I’m in the process of connecting up my G400HDR so that I can test the module with my board taken out of the equation.
Ok, so I was able to get the G400 working correctly when connected to the G400HDR. I have verified on my board that PA11 is being controled properly and I’m at a loss as to why the unit would be entering bootloader mode.
I’m using quite a few of the I/O pins, is there any other way that the unit could be entering bootloader mode other than PA11?
So the next test I would do on the G400HDR is to make sure you have a consistent tinybooter and netmf version installed, make sure you follow the update instructions and then report back what you see from MFDeploy’s Device Capabilities list. Then I’d be going over your board with a magnifying glass and look for solder bridges
Yes there is a possibility that bootloader mode is being triggered. PA11 is the MOSI pin on the SPI bus that controls the dataflash. If the other SPI pins are being pulled high or low disrupting the flow of data on the bus when the processor is trying to communicate with the dataflash chip, the Atmel processor will think that there is not a bootable program on the board to boot and will go into the default bootloader mode. PA11, PA12, PA13, and PA14 are all connected to the dataflash. Check these pins to see what you have them connected to. PA11, PA12, and PA13 should not be used at all except as SPI pins. Also note that PA14 should not be connected either.
Thanks for all your help. That seems like information that should be listed in the brochure or development area. LOL
My board does not use PA12 - PA14 so these pins are currently unconnected. PA11 is connected to a button and had filtering and a pull-up resistor in order to ward off false presses from noise. Removing these components and leaving PA11 floating now gives me the ability to enter bootloading mode only when needed.
Unfortunately, I’m not getting any USB device when its running outside of bootloader mode. My first guess is that there are more IO that are causing problems because of internal uses on the module. Are there any other pins that MUST be used as the brochure indicates and not as general IO?
The firmware seems to be OK as moving the G400 over to the HDR board allows it to be picked up by the PC.