Forum Replies Created
-
AuthorPosts
-
cmcgrath5035
ModeratorYes, J15 is NO Reset leads.
Have a confirming look here
Sheet 1 I believe
ModeratorCongratulations!
I misread this commentIn this code, output portC 0,1,3,4,5,6,7 blinking well, but portC 2 not blink (the RX input). No output, either HIGH or LOW. This is broken!
Missed the ” 2 “, thought you were reporting all of PortC broken.
And thanks for the detailed summary to help out the next poor soul…..
ModeratorSPI – I believe this is part of the debugger interface, so there could be internal conflicts with the tinyG code if you just hijack the leads.
I can’t comment yes/no on your test, but it looks directionally correct.
They appear to be shared functionality pins (PC1/XCK0), are you sure the PORTC.DIRSET is all you need (I have no experience)?But, I am not super surprised that your 5V oops did more damage than just that one port interface – overvoltage could have leaked back into the 3.3vBus and done random (or widespread) damage.
Oh well
ModeratorDid you, as Riley suggested, review
And have you reviewed the schematic for your TinyG version?
And have you verified that you can in fact get physical access to those leads on the device?
A quick look to me sees PortC ser 1 already connects to the SPI Connector (J13), probably causing a lot of other conflicts?ModeratorBummer
You might want to repost this query over atThe developers hang out in that space a lot more than here, and that’s the help source you probably need here.
ModeratorGood find, chmr.
Looking at current fw build parameters, $_lv=100 but $_jh=10000.
I’ll suggest that those be reviewed.ModeratorHmmm, nothing obvious in your $$ parameter setup.
New machine, or have you used it for a while, without issues?
You might try a $defa=1, to reset all parameters to factory default.
Alas, you will then have to reset all you parameters, but it seems some units have some non-visible (via $$) issues sometimes.ModeratorI resolved my build issue, I think.
SeeModeratorThanks for added info.
At the moment, I am staring at the Makefile.
I built a settings file based on my machine, derived from one of the existing files. But it appears that the default, settings_default.h got used, ignoring my make command
make PLATFORM=gShield SETTINGS_FILE=settings_shapeoko2_cjm_v1.0.h >gShield_build.logDid you try to make with other than defaults?
ModeratorI’m curious; connected as I am, the Tx or RX led that flashes about 1/sec is still flashing 1/sec. You seeing the same?
I expected that to stop once a connection was established, perhaps I misread.ModeratorWell how about that – I’m in!
There is now a CoolTerm down loadable for Linux.
I opened that, it automagically connected to /dev/ttyACM0 at 9600baud, I upped that to 115200I am physically connected to the Native USB Port.
The Edge build I have is `[fb] firmware build 71.04
[fv] firmware version 0.97
[cv] configuration version 5.00
[hp] hardware platform 3.00`ModeratorWin7 or Win8?
I have seen implications that Win8 is too fussy about signing of drivers to use the TinyG driver, I was about to try Win7.Are you physically connected to the programming USB or the Native USB port on the Due?
ModeratorThanks.
What Host OS you using?I am running Linux, And see Two connection options when connected to the USB main port: /dev/ttyACM0 and /dev /ttyACM1.
Coolterm does not connect to either.But you don’t actually use Coolterm, correct?
ModeratorThanks. CTS? I’ll hack about a bit.
-
AuthorPosts
