LGTM from our perspective - approving.
]]>Ah, shame - something to dig into later if/when we want to try and clean up HTML markup showing up in the content so we're more rendering output agnostic again in the future.
]]>Looks pretty good to me, expect the logo in the navbar on the homepage is oddly wrapping now instead of inline and a problem with the home page title rendering. Will look into that!
]]>Ok. I thought it is useful to show them they are getting traffic from us. But I guess they can see that from referrer anyways. I removed them.
]]>Corrected.
]]>Adjusted.
]]>Ok changed.
]]>done
]]>Unfortunately two new lines do not have the same effect as <br/>. Right now to get a separation of those two notes we need to use <br/>. I don't see another way to do it.
Spotted a couple of fairly small things - with them addressed we'll be happy to approve.
]]>This looks a little odd that it has a Unicode character inserted here (\u00a0) between author and = but this doesn't happen on any other pages - was this intentional?
Suggest V1 -> v1.x as it's the documentation for the entire release series.
Do we need to have Urchin Tracker links here? This looks like the original author of this put them in because they didn't realise.. but we should strip them while we're here as they serve no useful purpose to use or the reader.
]]>"hosted" here means BMDA - this should be adjusted to something like "Programming OTP with BMDA"
]]>Rather than an explicit <br/>, can this not be done by leaving a blank line or two in the Markdown?
This should either be Black Magic Debug Debugging, or be left as was as the name of the feature is Black Magic Inception whereby one uses a BMP to debug a BMP.
sadly mu thoughts for fix is not working.
]]>@dragonmux wrote in #2267 (comment):
]]>Target memory reads should not be causing resets, unless protocol recovery is being invoked - this has been working for others using the support and while, yes, that change is probably a little more correct.. you need too to investigate why the firmware is having to do protocol recovery as it should not be having to for your part and that indicates a more fundamental problem for your debug link.
Does your patch actually get you a working clean scan of the part at least?
]]>I think the issue is in nrf51.c, bool nrf51_probe(target_s *const target)
]]>Target voltage: 3.27V
Please report unknown device with Designer 0x244 Part ID 0x8
Available Targets:
No. Att Driver
*** 1 Unknown ARM Cortex-M Designer 0x244 Part ID 0x8 M4
Device I can see does a power on, but this used to work fine on older fw for BMP (1.8)
Target is NRf 52840
]]>Also looks good to me!
]]>I will now push a second commit as a proposal. The idea is to set PA12 low at boot regardless of the platform. I believe this will make things simpler and more robust
]]>if we use the stock bootloader, we need to PULL PA12 to GND
This was overlooked from my side when doing the original PR, because I used the BMD bootloader which managed to trigger re-enumeration. However when I flashed stock unmodified probe, it appeared to be stuck in bootloader mode because of the missing re-enumeration.