Serial interface no longer shows after flashing a Due on Mac OS 10.6.8

Home Forums TinyG TinyG Support Serial interface no longer shows after flashing a Due on Mac OS 10.6.8

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #9600
    lincob
    Member

    Hi,

    I’ve posted this on the github but found out afterwards this more appropriate place…

    I’m running OS X Snow Leopard (10.6.8)

    I’ve flashed the bin found there : http://synthetos.github.io/g2/ (TinyG2_Due-edge-078.03-default.bin)

    …On an Arduino Due, using bossac Version 1.3a… here is my output :

    MacBookPro:macosx lincob$ ./bossac -p tty.usbmodem1d11 -e -w -v -b TinyG2_Due-edge-078.03-default.bin
    Erase flash
    Write 125860 bytes to flash
    [==============================] 100% (492/492 pages)
    Verify 125860 bytes of flash
    [==============================] 100% (492/492 pages)
    Verify successful
    Set boot flash true
    MacBookPro:macosx lincob$

    I’ve read somewhere that the firmware on this page may be quite old so i’ve build my own from the edge branch :

    MacBookPro:TinyG2 lincob$ make PLATFORM=gShield SETTINGS_FILE=settings_default.h
    Make: /Library/Frameworks/Python.framework/Versions/3.4/bin:/Library/Frameworks/Python.framework/Versions/3.4/bin:/Library/Frameworks/Python.framework/Versions/2.7/bin:/Library/Frameworks/Python.framework/Versions/3.2/bin:/Library/Frameworks/GDAL.framework/Programs:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/local/CrossPack-AVR/bin:/opt/Ghostscript/bin:/usr/local/go/bin:/opt/ImageMagick/bin:/usr/X11/bin:/Users/lincob/Applications/android-sdk-mac_86/tools:/Users/lincob/Applications/android-sdk-mac_86/platform-tools:../Tools/gcc-arm-none-eabi/bin
    Git: git
    Looking for tools...
    cd ../Tools && make "ARCH=gcc-arm-none-eabi"
    make[1]: Nothing to be done for 
    all'.
    Compiling c CMSIS/Device/ATMEL/sam3xa/source/system_sam3xa.c
        -> build/gShield/CMSIS/Device/ATMEL/sam3xa/source/system_sam3xa.o 
    Compiling c CMSIS/Device/ATMEL/sam3xa/source/gcc/startup_sam3xa.c
        -> build/gShield/CMSIS/Device/ATMEL/sam3xa/source/gcc/startup_sam3xa.o 
    Compiling c platform/atmel_sam/cortex_handlers.c
        -> build/gShield/platform/atmel_sam/cortex_handlers.o 
    Compiling c platform/atmel_sam/hooks.c
        -> build/gShield/platform/atmel_sam/hooks.o 
    Compiling cpp motate/AvrUSB.cpp
        -> build/gShield/motate/AvrUSB.o 
    Compiling cpp motate/SamPins.cpp
        -> build/gShield/motate/SamPins.o 
    Compiling cpp motate/SamSPI.cpp
        -> build/gShield/motate/SamSPI.o 
    Compiling cpp motate/SamTimers.cpp
        -> build/gShield/motate/SamTimers.o 
    Compiling cpp motate/SamUSB.cpp
        -> build/gShield/motate/SamUSB.o 
    Compiling cpp canonical_machine.cpp
        -> build/gShield/canonical_machine.o 
    Compiling cpp config.cpp
        -> build/gShield/config.o 
    Compiling cpp config_app.cpp
        -> build/gShield/config_app.o 
    Compiling cpp controller.cpp
        -> build/gShield/controller.o 
    Compiling cpp coolant.cpp
        -> build/gShield/coolant.o 
    Compiling cpp cycle_homing.cpp
        -> build/gShield/cycle_homing.o 
    Compiling cpp cycle_jogging.cpp
        -> build/gShield/cycle_jogging.o 
    Compiling cpp cycle_probing.cpp
        -> build/gShield/cycle_probing.o 
    Compiling cpp encoder.cpp
        -> build/gShield/encoder.o 
    Compiling cpp gcode_parser.cpp
        -> build/gShield/gcode_parser.o 
    Compiling cpp gpio.cpp
        -> build/gShield/gpio.o 
    Compiling cpp hardware.cpp
        -> build/gShield/hardware.o 
    Compiling cpp help.cpp
        -> build/gShield/help.o 
    Compiling cpp json_parser.cpp
        -> build/gShield/json_parser.o 
    Compiling cpp kinematics.cpp
        -> build/gShield/kinematics.o 
    Compiling cpp main.cpp
        -> build/gShield/main.o 
    Compiling cpp persistence.cpp
        -> build/gShield/persistence.o 
    Compiling cpp plan_arc.cpp
        -> build/gShield/plan_arc.o 
    Compiling cpp plan_exec.cpp
        -> build/gShield/plan_exec.o 
    Compiling cpp plan_line.cpp
        -> build/gShield/plan_line.o 
    Compiling cpp plan_zoid.cpp
        -> build/gShield/plan_zoid.o 
    Compiling cpp planner.cpp
        -> build/gShield/planner.o 
    Compiling cpp pwm.cpp
        -> build/gShield/pwm.o 
    Compiling cpp report.cpp
        -> build/gShield/report.o 
    Compiling cpp spindle.cpp
        -> build/gShield/spindle.o 
    Compiling cpp stepper.cpp
        -> build/gShield/stepper.o 
    Compiling cpp test.cpp
        -> build/gShield/test.o 
    Compiling cpp text_parser.cpp
        -> build/gShield/text_parser.o 
    Compiling cpp util.cpp
        -> build/gShield/util.o 
    Compiling cpp xio.cpp
        -> build/gShield/xio.o 
    Compiling cpp platform/atmel_sam/Reset.cpp
        -> build/gShield/platform/atmel_sam/Reset.o 
    Compiling cpp platform/atmel_sam/UniqueId.cpp
        -> build/gShield/platform/atmel_sam/UniqueId.o 
    Compiling cpp platform/atmel_sam/syscalls_sam3.cpp
        -> build/gShield/platform/atmel_sam/syscalls_sam3.o 
    Linking bin/gShield/gShield.elf 
    Using linker script: /Users/lincob/Desktop/TinyG/macosx/g2/TinyG2/platform/atmel_sam/gcc_flash.ld 
    Exporting symbols bin/gShield/gShield.elf.txt 
    --- SIZE INFO ---
       text	   data	    bss	    dec	    hex	filename
     130660	      0	  12736	 143396	  23024	bin/gShield/gShield.elf
    Making binary bin/gShield/gShield.bin 
    4+0 records in
    4+0 records out
    4 bytes transferred in 0.031591 secs (127 bytes/sec)
    4+0 records in
    4+0 records out
    4 bytes transferred in 0.004925 secs (812 bytes/sec)
    MacBookPro:TinyG2 lincob$ 
    

    No error reported so i’m guessing the action is successful.

    – I then now flash the board with Bossac 1.3a (using programming port) :

    
    MacBookPro:macosx lincob$ stty -f /dev/tty.usbmodem1a21 1200
    MacBookPro:macosx lincob$ ./bossac -p tty.usbmodem1a21 -e -w -v -b gShield.bin
    Erase flash
    Write 130660 bytes to flash
    [==============================] 100% (511/511 pages)
    Verify 130660 bytes of flash
    [==============================] 100% (511/511 pages)
    Verify successful
    Set boot flash true
    MacBookPro:macosx lincob$ 

    I press the reset button, i guess there is something happening because the RX pin starts to blink every 2 seconds or so (the RX pin close to the native port, not the one close to the programming port)… which i later found out that was a normal behavior.

    When i plug back the Due native port on the mac, there is no more serial interface… so i can’t connect to the board…

    – On the system profiler, the board seems to be recognized by the system :

    Apple system profiler

    The programming port of the due still shows as /dev/tty.usbmodem1a21 but the native port doesn’t appear in the list anymore.

    I’ve tried with different USB cables.

    Do i need specific drivers ? Have i done something wrong ? Any help would be greatly appreciated.

    #9602
    cmcgrath5035
    Moderator

    We do not get much MAC traffic here, so I am not all that familiar with what you should see on-screen, in English or in French.

    Your process steps appear to be OK, but it is not obvious what you actually built.

    My first suggestion would be to reinstall $fb=72.08.
    It is old, but any other edge builds, such as current, might be too edgy.

    The 2 second “led heartbeat’ does say that tinyG is running.

    I have seen build issues on Mac talked about, a ways back.

    If 72.08 runs well, get used to the USB port appearance so that you know what to look for when loading your local builds.

    FYI, once you have tinyG and it’s bootloader installed (sounds like you do), you can flash via the native USB port.

    #9616
    lincob
    Member

    Hi,

    Thanks for your answer… I’ve tried with the 72.08 but same problem occurred…

    After further investigation, as i’ve found somewhere in some other post, it is actually driver related. The fact that i was actually lacking confidence about my ability to compile binaries sure didn’t help ! 😉

    I was bothered not to have another computer around to test the serial port… But that was forgetting about my Raspberry Pi… I’ve installed the latest Raspbian, installed go (hint : don’t install from apt-get as it installs a really old version), compiled the serial json server… And the G2 now works flawlessly (with both FW versions)… Here is the start of the output of the $$ command :

    {"r":{"fv":0.98,"fb":89.03,"hp":3,"hv":0,"id":"0213-2335-e323","msg":"SYSTEM READY"},"f":[1,0,1]}
    tinyg [mm] ok> 
    [fb]  firmware build             89.03
    [fbs] firmware build "                           build"
    [fv]  firmware version            0.98
    [cv]  configuration version       7.00
    [hp]  hardware platform           3.00
    [hv]  hardware version            0.00
    [id]  TinyG ID       0213-2335-e323

    Used chilipeppr over network and seems to work fine for the moment.

    I was first a bit scared of the process of building and configuring TinyG G2 on due (compared to other arduino IDE based solutions)… But i can tell you that even for a less than qualified person like me, the process is quite straightforward and easy.

    About the Mac… the problem lies in the VCP FTDI drivers, which apparently requires the 2.3 version (only available from OS 10.9 though)… So basically, on all previous versions, you’re stuck with 2.2.18 version drivers and it simply doesn’t work.

    However i’m still able to control the board from the mac through LAN/WLAN using the Pi, i don’t know if the network latency will do with buffers and stuff, but that’s another issue, i will find a workaround if i’d happen to run into problems with that.

    So… now that i have a working G2 with Due… Let the adventure begin. Thanks for your help, i’ll sure come back with more questions 😉

    #9620
    cmcgrath5035
    Moderator

    Great news.
    And now we know what the current Edge will build ($fb=89.03).

    Using a wifi connected Pi as your SPJS target should work OK, if it seems sluggish consider a Pi2

    I am actually a little surprised that changing the driver was the cause – DUE does not use FTDI devices, on Linux ports appear as /dev/ttyACM_, …. ?

    As you probably realize, you could now run CP from a well performing tablet or phone, should you wish

    #9622
    lincob
    Member

    You’re right… My bad… I actually got the information from this page… having a couple of dozen of tabs opened, i haven’t realized until now the page was actually referring to the TinyG board only, which obviously have an FTDI chip… Since I can’t find how to edit the second post, it would be nice to delete the bold comment from it.
    The status remains the same, it must be driver related but the info i provided about the FTDI drivers must be wrong.

    And now we know what the current Edge will build ($fb=89.03).

    A precision though, the build actually failed… I’ve solved it commenting out those two lines from config_app.cpp.

    	{ "sys","mfoe",_fipn,0, cm_print_mfoe,get_ui8, set_01,   (float *)&cm.gmx.mfo_enable,           MANUAL_FEEDRATE_OVERRIDE_ENABLE},
    	{ "sys","mfo", _fipn,3, cm_print_mfo, get_flt,cm_set_mfo,(float *)&cm.gmx.mfo_parameter,        MANUAL_FEEDRATE_OVERRIDE_PARAMETER},

    I’ve later on found this issue. Which have not been committed to the edge branch. I’ve edited the config_app.h file manually, and build was successful.

    Using a wifi connected Pi as your SPJS target should work OK, if it seems sluggish consider a Pi2

    I’m actually using a Pi2… I will report the results using wifi, but i have to build the CNC first 😉

    I am actually a little surprised that changing the driver was the cause – DUE does not use FTDI devices, on Linux ports appear as /dev/ttyACM_, …. ?

    Yes, on the Pi2, both serial ports show up straight from the Raspbian distrib :

    pi@raspberrypi:~ $ ls /dev/ttyACM*
    /dev/ttyACM0  /dev/ttyACM1

    As you probably realize, you could now run CP from a well performing tablet or phone, should you wish

    Yes !… I’ve tried from my phone and it’s actually quite amazing !!

    #9623
    cmcgrath5035
    Moderator

    The perils of living near the EDGE, but you seem to know how to help yourself.

    Good luck

Viewing 6 posts - 1 through 6 (of 6 total)
  • You must be logged in to reply to this topic.