Hi all... I dont get it When i start udoo (powe on) every time arduino stops to function (like freezes or dont even boot) seems like it erases itself when i reflash firmware it starts to run properly what can be the cause? is there automatic firmware erase or something like that?
Yep it behaves like it is erased i reflash and it starts to work is there any pin from udoo which erases arduino?
At schematic i see that arduino restarts when udoo restarts there is also IC called PIC10F200T(which get data from uart) which goes to Erase pin maybe it is erasing flash?
Hi there mushketer888, erase it's not automatic during the boot. There is a jumper to do the erase of the Arduino, which is j16 If you reset UDOO using the reset button you'll reset iMX6 but not Arduino. Could you explain specifically when does it reset? Three possibilities: a) when you plug off and in the power plug? b) using the reset button (sw1)? c) shutting down Ubuntu from menu?
I think the Arduino/SAM3X erase jumper is actually J22 (behind main system power button). J16, near the two microUSB ports resets the SAM3X instead. Page 15 of the schematic shows them. It's normal, if slightly annoying for a Udoo to restart the SAM3X chip as the main i.MX6 CPU is powered up (probably due to brief low-level output on the GPIO0 line), so your sketch needs to accomodate this. Spontaneous erasure is not normal, though-- despite there being a pin connection from the i.MX6 for that purpose also (GPIO117), these signals must be pulsed in the right sequence to trigger an erase. I'd definitely check for an errant jumper on J22.
Thanks for replies Yes i know that there is jumper But it is very strange It behaves like after power on it erases automatically There is PIC10 microcontroler inside which controls erase via UART (as i understand) DO you have such problem? when you flash arduino after power off and power on flash erases?
I have such problem only with RepetierFirmware i tested firmware ASCIITABLE and it works every time (doesnt erase)
Well as im using repetierfirmware i noticed: arduino send data to PC data from PC also goes to arduino BUT! but arduino dont receive commands its like pc send data and all is ok but arduino cant receive this arduino send data normally, for example "wait" command
I thought that problem is in RepetierFirmware but no.... i made testing script: Code: byte byteRead; void setup() { // Turn the Serial Protocol ON Serial.begin(115200); } void loop() { /* check if data has been sent from the computer: */ if (Serial.available()) { /* read the most recent byte */ byteRead = Serial.read(); /*ECHO the value that was read, back to the serial port. */ Serial.write(byteRead); } } and testing it from Putty sometimes it echo my data,but sometimes not (when linux is initialised) strange seems like Linux is blocking UART somehow
Strange but UDOO blocks sending data from PC to Arduino I recompiled kernel with usb_gadget_serial support (rather thatn usb ethernet) and use # stty -F /dev/ttymxc3 115200 # socat /dev/ttyGS0,raw,echo=0,crnl /dev/ttymxc3,raw,echo=0,crnl command to tunnel data from usb to ttymxc3 all works great now!
When connector CN6 is switched to the Arduino, the i.MX6's /dev/ttymxc3 interface conflicts with its transmit signal-- two RS-232 transmitters driving the same receiver pin doesn't work so well. The UDOO board designers probably should have arranged for J18 to also disconnect serial TX from the i.MX6 whenever CN6 is switched away, but you can work around this by tri-stating the i.MX6's transmit pin under software control. See this older thread: http://www.udoo.org/forum/serial-port-cn6-not-working-expected-t1881.html That's an interesting workaround, using CN3 in Gadget mode as a serial bridge. I usually force this port to be a USB Host, though, since it's on a separate EHCI controller & bus from all the others and so doesn't share bandwidth with them. Oh, that PIC chip you mention isn't actually present on production UDOO boards-- note the /X after its part number on the schematic (at U114), which indicates it was omitted from the final design ("/X = NOT MOUNTED" on page 1). So, it can't be responsible for any issues. There are a few other parts that were removed, like the SST25VF040 SPI boot EEPROM at U13 (they decided to boot directly from SD instead -- but those empty SO-8 pads underneath the board might be a handy place to tap into ECSPI bus #1 without tying up any Arduino pins, if pin-muxing is set appropriately).
Hi, to verify if SAM3X erases the sketch every time you reboot the i.MX 6 try this sketch (and insert a led on pin 13): void setup(){ pinMode(13, OUTPUT); for(int i=0; i < 10; i++){ digitalWrite(13, HIGH); delay(100); digitalWrite(13, LOW); delay(100); } } void loop(){ delay(1000); } So this shetch blinks the led ONLY when the SAM3x is rebooted. Then try the following test: - plug and unplug a jumper on J16: it is the SAM3X reset command - try to reboot UDOObuntu from menu - try to press RST button: it reset i.MX 6 but should not reset the SAM3X Can you verify in which cases the led blink and when the sketch is erased? Thanks
Well... actually it doesnt erase flash it just blocks sending data from PC to arduino but it is possible to receive data from arduino to PC UDOO cpu or multiplexor is blocking this... to avoid this is ability: * to recompile kernel with serial gadget * connect to other usb CN6 * using tty tunneling- socat command
Hi mushketer888, are you programming the Arduino from inside or from an external PC? If you are doing it the inside way, try the external way and tell us what happens.
I said that flashing goes OK outside and inside! PC can read data, but sometimes Linux imx cpu blocks transmitting data from PC to arduino... thats all it is the only problem so i made tunneling with socat (with virtual usb serial port) so at now iMX is processing UART communication with PC
