Fio v3 does not seem to execute code

Development Boards Arduino
1

Hi there,

I’ve got an interesting effect here, which I’m unable to figure: My sketch seems to upload successfully, yet I don’t see any effect (I’d expect the LEDs blinking).

I’ve been through various incarnations of Arduino boards in the last 4 to 5 years, but this is the first time I’m using a Fio. No external connections to any I/O port yet. I received the Fio v3 in a state where the CHARGE, POWER, RX and TX LEDs are all lit statically, bought in December. The vendor assured me that he ships the devices with the latest firmware. I’m using Windows 7 (32 Bit) with Arduino IDE 1.0.3 (fresh install, no relicts) BTW.

So far I’ve been installing the driver archive (Sparkfun website) in the sketchbook folder and registered the .inf file.

  • I see the board is detected in Windows Device Manager.

  • “Fio v3” shows up in the “Board” dropdown menu.

  • I can compile the code for “Fio v3”.

  • I see the related mapped serial port in “Serial Port” (happens that its not in there occasionally, though).

  • I’m able to upload the code, see the progress bar and the blue RX LED flashing, followed by “Done uploading” in the end.

What I would assume now is that it just works and my code is executed. This is not the case. I don’t see that anything changed for the LEDs, no blinking whatsoever.

I’ve been testing 3 cables as well: The Sparkfun Cerberus, a Sony-shipped cable with ferrit core, an unshielded one. Cable length is always < 3 m.

This is the test code I’m running:

int RXLED = 14;

void setup()
{
 pinMode(RXLED, OUTPUT);
 digitalWrite(RXLED, LOW);
 Serial.begin(9600);
 Serial1.begin(9600);
}

void loop()
{
 Serial.println("Serial Default"); 
 Serial1.println("Serial One");

 digitalWrite(RXLED, HIGH);
 TXLED1;
 delay(1000);
 digitalWrite(RXLED, LOW);
 TXLED0;
 delay(500);
}

Does anybody more intimate with the device have an idea what’s going on here?

Thanks in advance,

/M

2

Hi,

I managed to get my hands on a 0.5 m cable (with small ferrit core), which remedied the issue - sort of. The code I’m uploading runs successfully now, which leaves only one conclusion:

The data is corrupted in transit, using quality cables >= 1.0 m in a virtually ESD-unpolluted place. That most likely means that USB bulk resend is either not implemented or the data still comes in scrambled after the 3rd resend. In the latter case, the bus should yield an error, alternatively the device could check if the sent data is correct and signal errors.

I can live with it, though it doesn’t really meet my expectations.

Regards,

/M