signpost
signpost copied to clipboard
lab11
Debug Backplane Fixes (RevB errata)
- [x] Nit - put the programming signals in order
- [x] Move silkscreen out to accommodate a knurled knob
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
- [x] Doesn't say "Signpost"
- [x] Module 0, Module 1, Controller font are not the same size.
- [x] "MEM" -> "Storage"
- [x] What is the empty programming switch position for?
- [x] Move the JTAG header to the top of the board.
- [x] No easily accessible ground post for probing (Oscilloscope alligator clippy thing is too big for any of the 0.1" debug headers)
Literally every screw? Or the 4 gnd testpoints at various spots on the board?
On Feb 20, 2017 1:21 PM, "Branden Ghena" [email protected] 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 .
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.
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 should unscrew one of the feet for now
On Feb 20, 2017 1:39 PM, "Pat Pannuto" [email protected] 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 .
- [x] 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.
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" [email protected] 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 .
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 [email protected] 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" [email protected] 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 .
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" [email protected] 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 [email protected] 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" [email protected] 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 .
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 [email protected] 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" [email protected] 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 [email protected] 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" [email protected] 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 .
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" [email protected] 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 [email protected] 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" [email protected] 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 < [email protected]> 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" [email protected] 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 .
I just assumed something about pressing the button reset the chip differently
On Feb 21, 2017 1:04 PM, "Joshua Adkins" [email protected] 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" [email protected] 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 [email protected] 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" [email protected] 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 < [email protected]> 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" <[email protected]
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 .
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 [email protected] 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" [email protected] 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 [email protected] 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" [email protected] 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 < [email protected]> 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" < [email protected]> 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 .
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.
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" [email protected] 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 .
- [x] Another USB hub upstream of the FTDIs so that you can just plug in one USB cable
- [ ] 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 https://github.com/lab11/signpost/commit/ac68837df1fd405e7306dded32b567f29f427b06#diff-777998fb3b386dba9f5f4d2db1f9852cR119
-
