13:26 <Haohmaru> i went thru a pile of devices which had all kinds of problems, but one of them is left which i couldn't fix, it doesn't wanna get programmed

13:27 <Haohmaru> "Error: Error connecting DP: cannot read IDR"

13:27 <Haohmaru> there were a bunch of others like this but they had simple issues like shorts around the SWD signals, etc..

13:28 <Haohmaru> this one doesn't have shorts, everything appears to be the right value, pull resistors, etc... 3.3V reaching the chip, but still nothing

13:28 <Haohmaru> what else could cause this? afaiu this basically means that the MCU doesn't talk to the debugger

13:29 <Haohmaru> ehm, this is a Cortex-M4F

13:30 <Haohmaru> the pessimistic guess would be "dead chip"

13:38 <zapb_> Haohmaru, if you want support you should describe your setup and what are you trying to achieve... "I have a Cortex-M4F" is like "I have a microcontroller" - not sufficient to give you support ;)

13:39 <Haohmaru> it's not a bare microcontroller of course, it's part of a device

13:40 <Haohmaru> i have a pile of these, went thru them, got them working, except for this one

13:40 <Haohmaru> it's a SAME53N19A

13:41 <Haohmaru> the devices are actually a mix of SAMD51N19A and a few other variations under the same datasheet

13:42 <Haohmaru> the setup is... i power them up, then i plug a debugger (a daplink), and then i put my bootloader, target is powered, the daplink doesn't give power, both work on 3.3V

13:44 <Haohmaru> SWD port is done like Atmel says, with 1k pull up on SWCLK, and on the RESET there's a 10k pull up and a 47n capacitor to ground

13:45 <Haohmaru> hm, i don't actually know if the capacitor is really 47n, i could remove it to see if that makes it talk to the debugger

13:53 <Haohmaru> nope

14:19 <Haohmaru> okay, it seems the RESET signal stays at 3.3V and the debugger can't drive it low, yet i'm pretty sure i checked resistance to 3.3V so it's not a simple short

14:19 <Haohmaru> thus, i guess, dead reset pin

14:45 <zapb_> Hammdist, what debug adapter do you use?

14:46 <Haohmaru> he or moi?

14:46 <zapb_> Haohmaru, you, sorry :D

14:46 <zapb_> Most of the time MCUs are quite robust wrt external caps (in my experience)

14:46 <Haohmaru> daplink, kamamai.pl zl33prg

14:47 <Haohmaru> what do you mean?

14:47 <zapb_> Haohmaru, you mentioned that you're not sure about the 47n cap

14:48 <zapb_> Haohmaru, is your wiring solid? short cabels? proper GND connection? stable power supply?

14:48 <Haohmaru> yes, so i removed it

14:49 <Haohmaru> the SWD cable is maybe 40cm long, made of ethernet-grade cable of multri-strand copper conductor

14:50 <Haohmaru> i've programmed and debugged literally hundreds of boards with it

14:51 <Haohmaru> the power (3.3V) comes locally from the device's own regulator, which is a 12V->3.3V step-down regulator

14:53 <Haohmaru> well, there's another possibility that i didn't check, that is, whether the RESET happens to be broken along the path from the board to the debugger (that'll mean probably in the actual debug connector on the device)

15:02 <zapb_> Haohmaru, the reset should not influence the connection to the DAP

15:02 <zapb_> So even if you reset is not properly connected you should see a working connection at least to the DAP

15:03 <Haohmaru> not sure about that, $vendor says the RESET _must_ be wired to the debug port

15:04 <Haohmaru> thus i do it

15:05 <Haohmaru> i checked the SWCLK signal on the scope, it looked the debugger was clocking stuff normally there, the RESET was sitting at 3.3V and wasn't falling, i didn't check SWDIO, that signal goes directly from the debug connector to the MCU pin and there's no components involved

15:05 <zapb_> Well if that would be true, how would you connect under reset to a target? ;) Anyway, connect it to 3v3 and you're done.

15:06 <Haohmaru> but the SWDIO pin is not shorted to a neighbour pin, nor to GND/VDD, it's soldered, there is electrical connection from it to the debug port

15:06 <Haohmaru> connect what to 3.3V?

15:12 <Haohmaru> the thing i'm doing is running my silly "flash.sh" script which runs openocd with a "program" command and my bootloader.elf, i'd think the debugger would have to hold the chip in RESET for this operation, but i'm not sure

15:19 <zapb_> Haohmaru, keep your setup simple, try to just connect to the target with OpenOCD. Check again all VDD and GND connections if your target is hand soldered ;D

15:28 <Haohmaru> the debug port's connector is innocent too, there's electrical connection from the other end of the 40cm cable all the way to the pins on the MCU

15:29 <Haohmaru> for all of the important signals (RESET, SWCLK, SWDIO, VDD, GND)

15:32 <Haohmaru> the chip has been baked, perhaps the stencil might have been non-ideal and it has been touched by soldering iron afterwards, doesn't matter because after that i've put flux and went thru the whole chip with the iron, then i've cleaned it, and the soldering is good

15:33 <Haohmaru> it's well positioned, and the solder joints look fine, i don't see anything fishy or hairy, and i measured for shorts already several times

15:34 <Haohmaru> so, it smells like maybe "dead MCU"

22:14 <pedroa> Paul , you there ?

22:14 <pedroa> wrong channel