Debug Backplane Fixes (RevB errata) #23

adkinsjd · 2017-01-31T06:07:01Z

Switch module 1 and 0 programming silkscreen (light is still correct)

adkinsjd · 2017-01-31T08:59:17Z

Probably should put default off resistors on the debug LEDs

adkinsjd · 2017-01-31T10:33:40Z

Nit - put the programming signals in order
Move silkscreen out to accommodate a knurled knob

adkinsjd · 2017-01-31T10:47:05Z

A big 5V warning. maybe a protection circuit

ppannuto · 2017-02-14T21:57:13Z

Moving from #26 here:

Add LED for fake radio module.

ppannuto · 2017-02-14T21:58:56Z

Deal with USB Hub Reset problem

brghena · 2017-02-14T22:04:37Z

USB Hub Reset

Reboot: Hub still good
Power cycle (with ten seconds physically powered off): Hub still good

I'm guessing just asserting BackplaneReset at boot will be sufficient

bradjc · 2017-02-20T19:51:35Z

Doesn't say "Signpost"
Module 0, Module 1, Controller font are not the same size.
"MEM" -> "Storage"
What is the empty programming switch position for?
Move the JTAG header to the top of the board.

brghena · 2017-02-20T21:21:15Z

No easily accessible ground post for probing (Oscilloscope alligator clippy thing is too big for any of the 0.1" debug headers)

adkinsjd · 2017-02-20T21:26:09Z

Literally every screw? Or the 4 gnd testpoints at various spots on the board?

…

On Feb 20, 2017 1:21 PM, "Branden Ghena" ***@***.***> wrote: - No easily accessible ground post for probing — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGIJUMtfpqvZRFuCBSI_kr8sG2lFymzuks5regPLgaJpZM4LyRZM> .

brghena · 2017-02-20T21:27:43Z

Sorry, first message was unclear. I edited it to include the real intent, which is the ground connections on oscilloscope leads, which are too big and would short to other pins on the 0.1" headers and cannot latch on to round-headed screws.

ppannuto · 2017-02-20T21:39:08Z

I'm a fan of the ground bar-like thing. Draw a rectangular poly of exposed ground metal along the edge so that leads can just clip to the pcb.

adkinsjd · 2017-02-20T21:40:23Z

You should unscrew one of the feet for now

…

On Feb 20, 2017 1:39 PM, "Pat Pannuto" ***@***.***> wrote: I'm a fan of the ground bar-like thing. Draw a rectangular poly of exposed ground metal along the edge so that leads can just clip to the pcb. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGIJUJUW1AqyRxAc3OxfdXEj1UDZ6xylks5regf9gaJpZM4LyRZM> .

bradjc · 2017-02-21T17:45:02Z

Mod0 and Mod1 debug headers should be identical.

brghena · 2017-02-21T20:31:51Z

Enable programming of modules even without a valid controller app

Currently, when you just plug a module in to the debug backplane, you can't program it unless the controller has disabled isolation for that module. One solution to this would be powering modules explicitly even when the programming switch is set to it.

bradjc · 2017-02-21T20:35:37Z

Bigger !RESET button switches.

adkinsjd · 2017-02-21T20:37:43Z

I am actually pretty strongly against this unless you can enable and disable it strictly when the jlink is actually flashing. I think that a module staying on when the controller wants it off would be more problematic in the long run, and I don't think requiring turning the switch to be selecting none of the boards is viable, as you would inevitably forget. There is probably a jlink signal that could switch on/off for the duration of programming that could make this happen though.

…

On Feb 21, 2017 12:31 PM, "Branden Ghena" ***@***.***> wrote: - Enable programming of modules even without a valid controller app Currently, when you just plug a module in to the debug backplane, you can't program it unless the controller has disabled isolation for that module. One solution to this would be powering modules explicitly even when the programming switch is set to it. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGIJUD7p0tJnIDTsNDVoqEf99e0N0VOIks5re0m4gaJpZM4LyRZM> .

ppannuto · 2017-02-21T20:53:41Z

Yeah, the whole flashing / dev story needs a little work. Currently we have the annoying problem where flashing one quite often tends to leave other boards in the "i2c lines stuck low until reset" state that the SAM4L likes to get into. The big hammer is obviously to put all boards into reset during a flash, power on the target module forcefully, and then take things out of reset - but that could be obnoxious in practice. I'd rather understand this buggy i2c state On Tue, Feb 21, 2017 at 3:37 PM Joshua Adkins <notifications@github.com> wrote:

…

I am actually pretty strongly against this unless you can enable and disable it strictly when the jlink is actually flashing. I think that a module staying on when the controller wants it off would be more problematic in the long run, and I don't think requiring turning the switch to be selecting none of the boards is viable, as you would inevitably forget. There is probably a jlink signal that could switch on/off for the duration of programming that could make this happen though. On Feb 21, 2017 12:31 PM, "Branden Ghena" ***@***.***> wrote: > > - Enable programming of modules even without a valid controller app > > Currently, when you just plug a module in to the debug backplane, you > can't program it unless the controller has disabled isolation for that > module. One solution to this would be powering modules explicitly even when > the programming switch is set to it. > > — > You are receiving this because you were assigned. > Reply to this email directly, view it on GitHub > <#23 (comment)>, or mute > the thread > < https://github.com/notifications/unsubscribe-auth/AGIJUD7p0tJnIDTsNDVoqEf99e0N0VOIks5re0m4gaJpZM4LyRZM > > . > — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUt3qLY0RgxN8LZpPwRWsopdxHKt0ySks5re0sYgaJpZM4LyRZM> .

adkinsjd · 2017-02-21T21:00:33Z

The buggy I2C state is a separate issue, which I worry we will never be able to fix because it's a chip bug (although the first thing I would try is adding a few extra jlink resets at the end of the flashing script).

…

On Feb 21, 2017 12:53 PM, "Pat Pannuto" ***@***.***> wrote: Yeah, the whole flashing / dev story needs a little work. Currently we have the annoying problem where flashing one quite often tends to leave other boards in the "i2c lines stuck low until reset" state that the SAM4L likes to get into. The big hammer is obviously to put all boards into reset during a flash, power on the target module forcefully, and then take things out of reset - but that could be obnoxious in practice. I'd rather understand this buggy i2c state On Tue, Feb 21, 2017 at 3:37 PM Joshua Adkins ***@***.***> wrote: > I am actually pretty strongly against this unless you can enable and > disable it strictly when the jlink is actually flashing. I think that a > module staying on when the controller wants it off would be more > problematic in the long run, and I don't think requiring turning the switch > to be selecting none of the boards is viable, as you would inevitably > forget. > > There is probably a jlink signal that could switch on/off for the duration > of programming that could make this happen though. > > On Feb 21, 2017 12:31 PM, "Branden Ghena" ***@***.***> > wrote: > > > > > - Enable programming of modules even without a valid controller app > > > > Currently, when you just plug a module in to the debug backplane, you > > can't program it unless the controller has disabled isolation for that > > module. One solution to this would be powering modules explicitly even > when > > the programming switch is set to it. > > > > — > > You are receiving this because you were assigned. > > Reply to this email directly, view it on GitHub > > <#23 (comment)>, > or mute > > the thread > > < > https://github.com/notifications/unsubscribe-auth/ AGIJUD7p0tJnIDTsNDVoqEf99e0N0VOIks5re0m4gaJpZM4LyRZM > > > > . > > > > — > You are receiving this because you were assigned. > > > Reply to this email directly, view it on GitHub > <#23 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ AAUt3qLY0RgxN8LZpPwRWsopdxHKt0ySks5re0sYgaJpZM4LyRZM> > . > — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGIJULLDDh1GodUsrCFE-GYQ9iCI-nMBks5re07XgaJpZM4LyRZM> .

ppannuto · 2017-02-21T21:03:28Z

Yeah.. adding jlink resets won't help. It's _other_ SAM4Ls that aren't being flashed that tend to hold low it in my experience. On Tue, Feb 21, 2017 at 4:00 PM Joshua Adkins <notifications@github.com> wrote:

…

The buggy I2C state is a separate issue, which I worry we will never be able to fix because it's a chip bug (although the first thing I would try is adding a few extra jlink resets at the end of the flashing script). On Feb 21, 2017 12:53 PM, "Pat Pannuto" ***@***.***> wrote: > Yeah, the whole flashing / dev story needs a little work. Currently we have > the annoying problem where flashing one quite often tends to leave other > boards in the "i2c lines stuck low until reset" state that the SAM4L likes > to get into. > > The big hammer is obviously to put all boards into reset during a flash, > power on the target module forcefully, and then take things out of reset - > but that could be obnoxious in practice. I'd rather understand this buggy > i2c state > > On Tue, Feb 21, 2017 at 3:37 PM Joshua Adkins ***@***.***> > wrote: > > > I am actually pretty strongly against this unless you can enable and > > disable it strictly when the jlink is actually flashing. I think that a > > module staying on when the controller wants it off would be more > > problematic in the long run, and I don't think requiring turning the > switch > > to be selecting none of the boards is viable, as you would inevitably > > forget. > > > > There is probably a jlink signal that could switch on/off for the > duration > > of programming that could make this happen though. > > > > On Feb 21, 2017 12:31 PM, "Branden Ghena" ***@***.***> > > wrote: > > > > > > > > - Enable programming of modules even without a valid controller app > > > > > > Currently, when you just plug a module in to the debug backplane, you > > > can't program it unless the controller has disabled isolation for that > > > module. One solution to this would be powering modules explicitly even > > when > > > the programming switch is set to it. > > > > > > — > > > You are receiving this because you were assigned. > > > Reply to this email directly, view it on GitHub > > > <#23 (comment) >, > > or mute > > > the thread > > > < > > https://github.com/notifications/unsubscribe-auth/ > AGIJUD7p0tJnIDTsNDVoqEf99e0N0VOIks5re0m4gaJpZM4LyRZM > > > > > > . > > > > > > > — > > You are receiving this because you were assigned. > > > > > > Reply to this email directly, view it on GitHub > > <#23 (comment)>, > or mute > > the thread > > <https://github.com/notifications/unsubscribe-auth/ > AAUt3qLY0RgxN8LZpPwRWsopdxHKt0ySks5re0sYgaJpZM4LyRZM> > > . > > > > — > You are receiving this because you were assigned. > Reply to this email directly, view it on GitHub > <#23 (comment)>, or mute > the thread > < https://github.com/notifications/unsubscribe-auth/AGIJULLDDh1GodUsrCFE-GYQ9iCI-nMBks5re07XgaJpZM4LyRZM > > . > — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUt3nvnrrlt_GnLjSGHjNdXTAabYaTLks5re1BxgaJpZM4LyRZM> .

adkinsjd · 2017-02-21T21:04:28Z

Really? That's not what I've found. Usually if I hit the reset button on the one I'm flashing it works.

…

On Feb 21, 2017 1:03 PM, "Pat Pannuto" ***@***.***> wrote: Yeah.. adding jlink resets won't help. It's _other_ SAM4Ls that aren't being flashed that tend to hold low it in my experience. On Tue, Feb 21, 2017 at 4:00 PM Joshua Adkins ***@***.***> wrote: > The buggy I2C state is a separate issue, which I worry we will never be > able to fix because it's a chip bug (although the first thing I would try > is adding a few extra jlink resets at the end of the flashing script). > > On Feb 21, 2017 12:53 PM, "Pat Pannuto" ***@***.***> wrote: > > > Yeah, the whole flashing / dev story needs a little work. Currently we > have > > the annoying problem where flashing one quite often tends to leave other > > boards in the "i2c lines stuck low until reset" state that the SAM4L > likes > > to get into. > > > > The big hammer is obviously to put all boards into reset during a flash, > > power on the target module forcefully, and then take things out of reset > - > > but that could be obnoxious in practice. I'd rather understand this buggy > > i2c state > > > > On Tue, Feb 21, 2017 at 3:37 PM Joshua Adkins < ***@***.***> > > wrote: > > > > > I am actually pretty strongly against this unless you can enable and > > > disable it strictly when the jlink is actually flashing. I think that a > > > module staying on when the controller wants it off would be more > > > problematic in the long run, and I don't think requiring turning the > > switch > > > to be selecting none of the boards is viable, as you would inevitably > > > forget. > > > > > > There is probably a jlink signal that could switch on/off for the > > duration > > > of programming that could make this happen though. > > > > > > On Feb 21, 2017 12:31 PM, "Branden Ghena" ***@***.***> > > > wrote: > > > > > > > > > > > - Enable programming of modules even without a valid controller app > > > > > > > > Currently, when you just plug a module in to the debug backplane, you > > > > can't program it unless the controller has disabled isolation for > that > > > > module. One solution to this would be powering modules explicitly > even > > > when > > > > the programming switch is set to it. > > > > > > > > — > > > > You are receiving this because you were assigned. > > > > Reply to this email directly, view it on GitHub > > > > <#23# issuecomment-281470960 > >, > > > or mute > > > > the thread > > > > < > > > https://github.com/notifications/unsubscribe-auth/ > > AGIJUD7p0tJnIDTsNDVoqEf99e0N0VOIks5re0m4gaJpZM4LyRZM > > > > > > > > . > > > > > > > > > > — > > > You are receiving this because you were assigned. > > > > > > > > > Reply to this email directly, view it on GitHub > > > <#23 (comment) >, > > or mute > > > the thread > > > <https://github.com/notifications/unsubscribe-auth/ > > AAUt3qLY0RgxN8LZpPwRWsopdxHKt0ySks5re0sYgaJpZM4LyRZM> > > > . > > > > > > > — > > You are receiving this because you were assigned. > > Reply to this email directly, view it on GitHub > > <#23 (comment)>, > or mute > > the thread > > < > https://github.com/notifications/unsubscribe-auth/AGIJULLDDh1GodUsrCFE- GYQ9iCI-nMBks5re07XgaJpZM4LyRZM > > > > . > > > > — > You are receiving this because you were assigned. > > > Reply to this email directly, view it on GitHub > <#23 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AAUt3nvnrrlt_ GnLjSGHjNdXTAabYaTLks5re1BxgaJpZM4LyRZM> > . > — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGIJUDJGLslQIAFOkya1FLHeCD_1uansks5re1EigaJpZM4LyRZM> .

adkinsjd · 2017-02-21T21:05:13Z

I just assumed something about pressing the button reset the chip differently

…

On Feb 21, 2017 1:04 PM, "Joshua Adkins" ***@***.***> wrote: Really? That's not what I've found. Usually if I hit the reset button on the one I'm flashing it works. On Feb 21, 2017 1:03 PM, "Pat Pannuto" ***@***.***> wrote: > Yeah.. adding jlink resets won't help. It's _other_ SAM4Ls that aren't > being flashed that tend to hold low it in my experience. > > On Tue, Feb 21, 2017 at 4:00 PM Joshua Adkins ***@***.***> > wrote: > > > The buggy I2C state is a separate issue, which I worry we will never be > > able to fix because it's a chip bug (although the first thing I would > try > > is adding a few extra jlink resets at the end of the flashing script). > > > > On Feb 21, 2017 12:53 PM, "Pat Pannuto" ***@***.***> > wrote: > > > > > Yeah, the whole flashing / dev story needs a little work. Currently we > > have > > > the annoying problem where flashing one quite often tends to leave > other > > > boards in the "i2c lines stuck low until reset" state that the SAM4L > > likes > > > to get into. > > > > > > The big hammer is obviously to put all boards into reset during a > flash, > > > power on the target module forcefully, and then take things out of > reset > > - > > > but that could be obnoxious in practice. I'd rather understand this > buggy > > > i2c state > > > > > > On Tue, Feb 21, 2017 at 3:37 PM Joshua Adkins < > ***@***.***> > > > wrote: > > > > > > > I am actually pretty strongly against this unless you can enable and > > > > disable it strictly when the jlink is actually flashing. I think > that a > > > > module staying on when the controller wants it off would be more > > > > problematic in the long run, and I don't think requiring turning the > > > switch > > > > to be selecting none of the boards is viable, as you would > inevitably > > > > forget. > > > > > > > > There is probably a jlink signal that could switch on/off for the > > > duration > > > > of programming that could make this happen though. > > > > > > > > On Feb 21, 2017 12:31 PM, "Branden Ghena" ***@***.*** > > > > > > wrote: > > > > > > > > > > > > > > - Enable programming of modules even without a valid controller > app > > > > > > > > > > Currently, when you just plug a module in to the debug backplane, > you > > > > > can't program it unless the controller has disabled isolation for > > that > > > > > module. One solution to this would be powering modules explicitly > > even > > > > when > > > > > the programming switch is set to it. > > > > > > > > > > — > > > > > You are receiving this because you were assigned. > > > > > Reply to this email directly, view it on GitHub > > > > > <#23 (comment)- > 281470960 > > >, > > > > or mute > > > > > the thread > > > > > < > > > > https://github.com/notifications/unsubscribe-auth/ > > > AGIJUD7p0tJnIDTsNDVoqEf99e0N0VOIks5re0m4gaJpZM4LyRZM > > > > > > > > > > . > > > > > > > > > > > > > — > > > > You are receiving this because you were assigned. > > > > > > > > > > > > Reply to this email directly, view it on GitHub > > > > <#23 (comment) > >, > > > or mute > > > > the thread > > > > <https://github.com/notifications/unsubscribe-auth/ > > > AAUt3qLY0RgxN8LZpPwRWsopdxHKt0ySks5re0sYgaJpZM4LyRZM> > > > > . > > > > > > > > > > — > > > You are receiving this because you were assigned. > > > Reply to this email directly, view it on GitHub > > > <#23 (comment)>, > > or mute > > > the thread > > > < > > https://github.com/notifications/unsubscribe-auth/ > AGIJULLDDh1GodUsrCFE-GYQ9iCI-nMBks5re07XgaJpZM4LyRZM > > > > > > . > > > > > > > — > > You are receiving this because you were assigned. > > > > > > Reply to this email directly, view it on GitHub > > <#23 (comment)>, > or mute > > the thread > > <https://github.com/notifications/unsubscribe-auth/ > AAUt3nvnrrlt_GnLjSGHjNdXTAabYaTLks5re1BxgaJpZM4LyRZM> > > . > > > > — > You are receiving this because you were assigned. > Reply to this email directly, view it on GitHub > <#23 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AGIJUDJGLslQIAFOkya1FLHeCD_1uansks5re1EigaJpZM4LyRZM> > . >

ppannuto · 2017-02-21T21:07:39Z

Often is too strong. I'd say.. 75% of the time the one I flashed, maybe 25% of the time another chip on the network somewhere. But at this point I'm just in the habit of resetting all of them, so my empirical evidence isn't great. Maybe I can unlearn that habit. On Tue, Feb 21, 2017 at 4:04 PM Joshua Adkins <notifications@github.com> wrote:

…

Really? That's not what I've found. Usually if I hit the reset button on the one I'm flashing it works. On Feb 21, 2017 1:03 PM, "Pat Pannuto" ***@***.***> wrote: > Yeah.. adding jlink resets won't help. It's _other_ SAM4Ls that aren't > being flashed that tend to hold low it in my experience. > > On Tue, Feb 21, 2017 at 4:00 PM Joshua Adkins ***@***.***> > wrote: > > > The buggy I2C state is a separate issue, which I worry we will never be > > able to fix because it's a chip bug (although the first thing I would try > > is adding a few extra jlink resets at the end of the flashing script). > > > > On Feb 21, 2017 12:53 PM, "Pat Pannuto" ***@***.***> > wrote: > > > > > Yeah, the whole flashing / dev story needs a little work. Currently we > > have > > > the annoying problem where flashing one quite often tends to leave > other > > > boards in the "i2c lines stuck low until reset" state that the SAM4L > > likes > > > to get into. > > > > > > The big hammer is obviously to put all boards into reset during a > flash, > > > power on the target module forcefully, and then take things out of > reset > > - > > > but that could be obnoxious in practice. I'd rather understand this > buggy > > > i2c state > > > > > > On Tue, Feb 21, 2017 at 3:37 PM Joshua Adkins < > ***@***.***> > > > wrote: > > > > > > > I am actually pretty strongly against this unless you can enable and > > > > disable it strictly when the jlink is actually flashing. I think > that a > > > > module staying on when the controller wants it off would be more > > > > problematic in the long run, and I don't think requiring turning the > > > switch > > > > to be selecting none of the boards is viable, as you would inevitably > > > > forget. > > > > > > > > There is probably a jlink signal that could switch on/off for the > > > duration > > > > of programming that could make this happen though. > > > > > > > > On Feb 21, 2017 12:31 PM, "Branden Ghena" < ***@***.***> > > > > wrote: > > > > > > > > > > > > > > - Enable programming of modules even without a valid controller app > > > > > > > > > > Currently, when you just plug a module in to the debug backplane, > you > > > > > can't program it unless the controller has disabled isolation for > > that > > > > > module. One solution to this would be powering modules explicitly > > even > > > > when > > > > > the programming switch is set to it. > > > > > > > > > > — > > > > > You are receiving this because you were assigned. > > > > > Reply to this email directly, view it on GitHub > > > > > <#23# > issuecomment-281470960 > > >, > > > > or mute > > > > > the thread > > > > > < > > > > https://github.com/notifications/unsubscribe-auth/ > > > AGIJUD7p0tJnIDTsNDVoqEf99e0N0VOIks5re0m4gaJpZM4LyRZM > > > > > > > > > > . > > > > > > > > > > > > > — > > > > You are receiving this because you were assigned. > > > > > > > > > > > > Reply to this email directly, view it on GitHub > > > > < #23 (comment) > >, > > > or mute > > > > the thread > > > > <https://github.com/notifications/unsubscribe-auth/ > > > AAUt3qLY0RgxN8LZpPwRWsopdxHKt0ySks5re0sYgaJpZM4LyRZM> > > > > . > > > > > > > > > > — > > > You are receiving this because you were assigned. > > > Reply to this email directly, view it on GitHub > > > <#23 (comment) >, > > or mute > > > the thread > > > < > > https://github.com/notifications/unsubscribe-auth/AGIJULLDDh1GodUsrCFE- > GYQ9iCI-nMBks5re07XgaJpZM4LyRZM > > > > > > . > > > > > > > — > > You are receiving this because you were assigned. > > > > > > Reply to this email directly, view it on GitHub > > <#23 (comment)>, > or mute > > the thread > > <https://github.com/notifications/unsubscribe-auth/AAUt3nvnrrlt_ > GnLjSGHjNdXTAabYaTLks5re1BxgaJpZM4LyRZM> > > . > > > > — > You are receiving this because you were assigned. > Reply to this email directly, view it on GitHub > <#23 (comment)>, or mute > the thread > < https://github.com/notifications/unsubscribe-auth/AGIJUDJGLslQIAFOkya1FLHeCD_1uansks5re1EigaJpZM4LyRZM > > . > — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUt3s2MDyuOKqI1GgTvvXUWdA3ttVqMks5re1FdgaJpZM4LyRZM> .

bradjc · 2017-02-21T21:34:06Z

My experience is basically 100% of the time it's the fault of the one I just flashed and that resetting the just flashed module fixes the issue.

adkinsjd · 2017-02-21T21:35:18Z

Have we tried just running JLinkExe and resetting a few times to see if that fixes it?

…

On Feb 21, 2017 1:34 PM, "Brad Campbell" ***@***.***> wrote: My experience is basically 100% of the time it's the fault of the one I just flashed and that resetting the just flashed module fixes the issue. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGIJUEaon9r13FK06HRXNBSw-ysXG3smks5re1hTgaJpZM4LyRZM> .

ppannuto · 2017-02-21T21:49:28Z

Master reset button that resets everything

ppannuto · 2017-02-22T02:08:40Z

Another USB hub upstream of the FTDIs so that you can just plug in one USB cable

nealjack · 2017-02-22T21:56:36Z

Radio Module clock unstable - gpios don't work on cold boot
- Neal Jackson [17:13]
  That was an issue I saw on my weird led flipped board - so I'm not sure it's an actual issue. I added a delay in the radio app that seemed to stabilize things
- This was added to work around issue ac68837#diff-777998fb3b386dba9f5f4d2db1f9852cR119

HACK for debug backplane Added delay for debug backplane "radio" clock to stabilize. Without it GPIOs were not stabilizing. #23

ppannuto · 2017-03-07T18:58:48Z

Add GPIO extender to reset / monitor the USB hub. Set to address 3

ppannuto · 2017-04-10T03:26:29Z

power metering jumpers for modules/controller
eeprom chip

ppannuto mentioned this issue Feb 14, 2017

Debug Backplane Updates #26

Closed

1 task

ppannuto added the hardware label Feb 17, 2017

ppannuto assigned adkinsjd and ppannuto Feb 17, 2017

nealjack added a commit that referenced this issue Feb 22, 2017

Ensure radio module gets initialized first

ac68837

HACK for debug backplane Added delay for debug backplane "radio" clock to stabilize. Without it GPIOs were not stabilizing. #23

ppannuto changed the title ~~Debug Backplane Fixes~~ Debug Backplane Fixes (RevB errata) Mar 8, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Debug Backplane Fixes (RevB errata) #23

Debug Backplane Fixes (RevB errata) #23

adkinsjd commented Jan 31, 2017 •

edited by nealjack

adkinsjd commented Jan 31, 2017 •

edited by nealjack

adkinsjd commented Jan 31, 2017 •

edited by nealjack

adkinsjd commented Jan 31, 2017 •

edited by nealjack

ppannuto commented Feb 14, 2017 •

edited

ppannuto commented Feb 14, 2017 •

edited

brghena commented Feb 14, 2017

bradjc commented Feb 20, 2017 •

edited by ppannuto

brghena commented Feb 20, 2017 •

edited by ppannuto

adkinsjd commented Feb 20, 2017 via email

brghena commented Feb 20, 2017

ppannuto commented Feb 20, 2017

adkinsjd commented Feb 20, 2017 via email

bradjc commented Feb 21, 2017 •

edited by ppannuto

brghena commented Feb 21, 2017 •

edited by ppannuto

bradjc commented Feb 21, 2017 •

edited by ppannuto

adkinsjd commented Feb 21, 2017 via email

ppannuto commented Feb 21, 2017 via email

adkinsjd commented Feb 21, 2017 via email

ppannuto commented Feb 21, 2017 via email

adkinsjd commented Feb 21, 2017 via email

adkinsjd commented Feb 21, 2017 via email

ppannuto commented Feb 21, 2017 via email

bradjc commented Feb 21, 2017

adkinsjd commented Feb 21, 2017 via email

ppannuto commented Feb 21, 2017 •

edited

ppannuto commented Feb 22, 2017 •

edited

nealjack commented Feb 22, 2017 •

edited by ppannuto

ppannuto commented Mar 7, 2017 •

edited

ppannuto commented Apr 10, 2017 •

edited

Debug Backplane Fixes (RevB errata) #23

Debug Backplane Fixes (RevB errata) #23

Comments

adkinsjd commented Jan 31, 2017 • edited by nealjack

adkinsjd commented Jan 31, 2017 • edited by nealjack

adkinsjd commented Jan 31, 2017 • edited by nealjack

adkinsjd commented Jan 31, 2017 • edited by nealjack

ppannuto commented Feb 14, 2017 • edited

ppannuto commented Feb 14, 2017 • edited

brghena commented Feb 14, 2017

USB Hub Reset

bradjc commented Feb 20, 2017 • edited by ppannuto

brghena commented Feb 20, 2017 • edited by ppannuto

adkinsjd commented Feb 20, 2017 via email

brghena commented Feb 20, 2017

ppannuto commented Feb 20, 2017

adkinsjd commented Feb 20, 2017 via email

bradjc commented Feb 21, 2017 • edited by ppannuto

brghena commented Feb 21, 2017 • edited by ppannuto

bradjc commented Feb 21, 2017 • edited by ppannuto

adkinsjd commented Feb 21, 2017 via email

ppannuto commented Feb 21, 2017 via email

adkinsjd commented Feb 21, 2017 via email

ppannuto commented Feb 21, 2017 via email

adkinsjd commented Feb 21, 2017 via email

adkinsjd commented Feb 21, 2017 via email

ppannuto commented Feb 21, 2017 via email

bradjc commented Feb 21, 2017

adkinsjd commented Feb 21, 2017 via email

ppannuto commented Feb 21, 2017 • edited

ppannuto commented Feb 22, 2017 • edited

nealjack commented Feb 22, 2017 • edited by ppannuto

ppannuto commented Mar 7, 2017 • edited

ppannuto commented Apr 10, 2017 • edited

adkinsjd commented Jan 31, 2017 •

edited by nealjack

adkinsjd commented Jan 31, 2017 •

edited by nealjack

adkinsjd commented Jan 31, 2017 •

edited by nealjack

adkinsjd commented Jan 31, 2017 •

edited by nealjack

ppannuto commented Feb 14, 2017 •

edited

ppannuto commented Feb 14, 2017 •

edited

bradjc commented Feb 20, 2017 •

edited by ppannuto

brghena commented Feb 20, 2017 •

edited by ppannuto

bradjc commented Feb 21, 2017 •

edited by ppannuto

brghena commented Feb 21, 2017 •

edited by ppannuto

bradjc commented Feb 21, 2017 •

edited by ppannuto

ppannuto commented Feb 21, 2017 •

edited

ppannuto commented Feb 22, 2017 •

edited

nealjack commented Feb 22, 2017 •

edited by ppannuto

ppannuto commented Mar 7, 2017 •

edited

ppannuto commented Apr 10, 2017 •

edited