search

lab11 / signpost

Exploring what happens when you put computers on sign posts.
Apache License 2.0
90 stars 7 forks source link

Debug Backplane Fixes (RevB errata) #23

Open adkinsjd opened 7 years ago

adkinsjd commented 7 years ago
adkinsjd commented 7 years ago
adkinsjd commented 7 years ago
adkinsjd commented 7 years ago
ppannuto commented 7 years ago

Moving from #26 here:

ppannuto commented 7 years ago
brghena commented 7 years ago

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 commented 7 years ago
brghena commented 7 years ago
adkinsjd commented 7 years ago

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

On Feb 20, 2017 1:21 PM, "Branden Ghena" notifications@github.com 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 https://github.com/lab11/signpost/issues/23#issuecomment-281183906, or mute the thread https://github.com/notifications/unsubscribe-auth/AGIJUMtfpqvZRFuCBSI_kr8sG2lFymzuks5regPLgaJpZM4LyRZM .

brghena commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

You should unscrew one of the feet for now

On Feb 20, 2017 1:39 PM, "Pat Pannuto" notifications@github.com 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 https://github.com/lab11/signpost/issues/23#issuecomment-281187424, or mute the thread https://github.com/notifications/unsubscribe-auth/AGIJUJUW1AqyRxAc3OxfdXEj1UDZ6xylks5regf9gaJpZM4LyRZM .

bradjc commented 7 years ago
brghena commented 7 years ago

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 commented 7 years ago
adkinsjd commented 7 years ago

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" notifications@github.com 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 https://github.com/lab11/signpost/issues/23#issuecomment-281470960, or mute the thread https://github.com/notifications/unsubscribe-auth/AGIJUD7p0tJnIDTsNDVoqEf99e0N0VOIks5re0m4gaJpZM4LyRZM .

ppannuto commented 7 years ago

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" notifications@github.com 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 https://github.com/lab11/signpost/issues/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 https://github.com/lab11/signpost/issues/23#issuecomment-281472531, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUt3qLY0RgxN8LZpPwRWsopdxHKt0ySks5re0sYgaJpZM4LyRZM .

adkinsjd commented 7 years ago

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" notifications@github.com 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 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" notifications@github.com 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 https://github.com/lab11/signpost/issues/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 https://github.com/lab11/signpost/issues/23#issuecomment-281472531, 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 https://github.com/lab11/signpost/issues/23#issuecomment-281476796, or mute the thread https://github.com/notifications/unsubscribe-auth/AGIJULLDDh1GodUsrCFE-GYQ9iCI-nMBks5re07XgaJpZM4LyRZM .

ppannuto commented 7 years ago

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" notifications@github.com 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 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" notifications@github.com 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 <https://github.com/lab11/signpost/issues/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 https://github.com/lab11/signpost/issues/23#issuecomment-281472531, 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 https://github.com/lab11/signpost/issues/23#issuecomment-281476796, 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 https://github.com/lab11/signpost/issues/23#issuecomment-281478680, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUt3nvnrrlt_GnLjSGHjNdXTAabYaTLks5re1BxgaJpZM4LyRZM .

adkinsjd commented 7 years ago

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" notifications@github.com 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 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" notifications@github.com 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 < 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" notifications@github.com 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 <https://github.com/lab11/signpost/issues/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 <https://github.com/lab11/signpost/issues/23#issuecomment-281472531 , 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 https://github.com/lab11/signpost/issues/23#issuecomment-281476796, 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 https://github.com/lab11/signpost/issues/23#issuecomment-281478680, 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 https://github.com/lab11/signpost/issues/23#issuecomment-281479477, or mute the thread https://github.com/notifications/unsubscribe-auth/AGIJUDJGLslQIAFOkya1FLHeCD_1uansks5re1EigaJpZM4LyRZM .

adkinsjd commented 7 years ago

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

On Feb 21, 2017 1:04 PM, "Joshua Adkins" adkinsjd@umich.edu 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" notifications@github.com 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 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" notifications@github.com 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 < 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" <notifications@github.com

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 <https://github.com/lab11/signpost/issues/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 <https://github.com/lab11/signpost/issues/23#issuecomment-281472531 , 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 https://github.com/lab11/signpost/issues/23#issuecomment-281476796, 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 https://github.com/lab11/signpost/issues/23#issuecomment-281478680, 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 https://github.com/lab11/signpost/issues/23#issuecomment-281479477, or mute the thread https://github.com/notifications/unsubscribe-auth/AGIJUDJGLslQIAFOkya1FLHeCD_1uansks5re1EigaJpZM4LyRZM .

ppannuto commented 7 years ago

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" notifications@github.com 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 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" notifications@github.com 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 < 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" < notifications@github.com> 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 <https://github.com/lab11/signpost/issues/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 < https://github.com/lab11/signpost/issues/23#issuecomment-281472531 , 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 <https://github.com/lab11/signpost/issues/23#issuecomment-281476796 , 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 https://github.com/lab11/signpost/issues/23#issuecomment-281478680, 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 https://github.com/lab11/signpost/issues/23#issuecomment-281479477, 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 https://github.com/lab11/signpost/issues/23#issuecomment-281479744, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUt3s2MDyuOKqI1GgTvvXUWdA3ttVqMks5re1FdgaJpZM4LyRZM .

bradjc commented 7 years ago

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 commented 7 years ago

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" notifications@github.com 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 https://github.com/lab11/signpost/issues/23#issuecomment-281488256, or mute the thread https://github.com/notifications/unsubscribe-auth/AGIJUEaon9r13FK06HRXNBSw-ysXG3smks5re1hTgaJpZM4LyRZM .

ppannuto commented 7 years ago
ppannuto commented 7 years ago
nealjack commented 7 years ago
ppannuto commented 7 years ago
ppannuto commented 7 years ago