Is the Raptor more sensitive to USB cabling?

I’m upgrading a system that has been working quite well with a Spider board to a Raptor board. I need the extra serial ports and more speed and memory is always a good thing. Because my system sits in a sealed pressure housing, I use a 3 meter USB cable (for debug and download) that enters the pressure housing through a non-standard USB cable. This has worked without issue on the Spider system but the Raptor system takes 20 seconds or more to enumerate when it enumerates at all. At this point, the Raptor is enumerating as “GPS Camera Detect (COM6)” in the Windows Device Manager even with a short USB cable that goes straight to the dual USB board.

I haven’t figured out how to re-install the USB drivers and could use some help with that. Any other ideas on this issue would also be greatly appreciated.

Thanks - Gene

Sounds like you are in boot loader mode?

How would I have gotten in boot loader mode? More importantly, how do I get out?

The firmware was erased somehow or you are not connecting the spi pins properly. What us connected to the spi pins, the ones with no gpio feature?

After a fair amount of fumbling around, I pulled out a new Raptor board and plugged it in. Everything works fine with the new board installed, even with my long and non-standard USB lash up. I can’t connect to the first Raptor board with FEZConfig which leads me to believe I’ve either fried that board or have put it in a state where it isn’t enumerating. I can’t find the right document to tell me how to get it out of whatever state I may have put it in and any suggestions will be greatly appreciated.

Thanks to Mike for pointing me down this road.

Sorry Gus, our posts must have crossed.

I have a SPI device on X3, the dual USB module on X8, A microSD module on X9, an I2C gizmo on X14, RS232 serial modules on X4, X10, X11 and X12 and a TTL level serial device on X1. I use 3 of the GPIO pins on X2.

Can you point me at a doc for re-loading the firmware, or is the first board toast?

try running FezConfig and see if it will do the task (the board is certainly not toast)

Manual steps are in the documentation from https://www.ghielectronics.com/docs/112/g400

I’m trying to resurrect my old Raptor with the instructions Brett pointed me at starting with updating the loader. The GHI document says to short pin 8 of X3 to ground and hit the reset button to get the Raptor in loader mode. Pin 8 of X3 is also SPI1_MISO. I have a SPI device connected to X3 and everything has has been working fine (until now) while I bring up the system with the new Raptor board. However, it looks like if my SPI slave sets MISO low and I hit the reset button, I put the system into loader mode.

Is that right?
Does that mean I shouldn’t use SPI1?

I’d opt to move SPI to a different SPI channel, yes.

If you can take the SPI device off and the Raptor boots into netmf as per normal, then you can prove that this is the issue.

Any idea what the Raptor is doing with SPI1, or at least the the SPI1_MISO pin?

Unfortunately, it looks like SPI2 is only brought out to X1 which is also where COM4 is routed. I’ll have to build a interface board to run signals from a couple of Raptor connectors to all the places they need to go in order to use SPI2.

Hopefully, Atmel will give me a confirmation to download their Atmel programmer “SAM-BA 2.12 for Windows (XP, Vista, Seven editions)”. I’ve tried twice but so far no e-mail letting me download the file. Maybe tomorrow.

Thanks for all the help - Gene

@ Gene - The SPI pin is just sampled on startup to determine if the board should go into samba mode. We actually ship the program you are trying to download with the SDK. You should be able to update TinyBooter using the scripts in the G400 TinyBooter folder in the Premium SDK.

You can also find the program here: https://www.ghielectronics.com/downloads/NETMF/SDK/sam-ba.2.12.exe

Thanks for all the help, I really want to make sure I understand this before I have to build another interface card and rewire my system.

@ John - Currently, I have an analog to digital converter card (a CN0254 from Analog Devices) connected to SPI1. Since I don’t have any control over what state it’s MISO line might be in when the system powers up, nor do I have a power up sequencer (yet), it sounds like I really shouldn’t be using SPI1. Is that correct?

Thanks for pointing me at the programs and the scripts. I’ll try to resurrect my toasted Raptor later today.

@ Gene - If that line has a chance of being grounded on startup, then it is possible you can be sent into samba mode instead of booting the board. If the line isn’t actually being driven to ground and is just floating as the chip initializes, you’ll be fine.

OK, I’ll do the safe thing and switch to SPI2.

Many thanks for all the help on this issue.

Cheers - Gene

@ GHI - The pinout chart on the G400 module brochures (for the G400D and G400S) should be modified to emphasize these “gotcha” pins. Gotcha pins should be called out from the get-go and not be buried under layers of documentation.

@ Iggmoe - Your comment is noted and appreciated. Like many areas where we’re continually doing improvement, all of our documentation is currently being examined and brought up-to-date.

By the way, the G400 and G120 manuals coming in few days already include this in details. This is long overdue but they are finally coming soon.

1 Like