03:44 <sb0> cr1901_modern: online migen manual fixed

05:26 <mtrbot-ml> [mattermost] <sb10q> @hartytp so I connected thermostat JTAG, and indeed, it is powered, but now it does this:

05:27 <mtrbot-ml> [mattermost] <sb10q> ```

05:27 <mtrbot-ml> [mattermost] <sb10q> ~/ionpak/firmware]$ openocd -f openocd.cfg

05:27 <mtrbot-ml> [mattermost] <sb10q> Open On-Chip Debugger 0.10.0-snapshot (2019-04-12-09:15)

05:27 <mtrbot-ml> [mattermost] <sb10q> Licensed under GNU GPL v2

05:27 <mtrbot-ml> [mattermost] <sb10q> For bug reports, read

05:27 <mtrbot-ml> [mattermost] <sb10q> http://openocd.org/doc/doxygen/bugs.html

05:27 <mtrbot-ml> [mattermost] <sb10q> Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.

05:27 <mtrbot-ml> [mattermost] <sb10q> adapter speed: 500 kHz

05:27 <mtrbot-ml> [mattermost] <sb10q> Info : clock speed 500 kHz

05:27 <mtrbot-ml> [mattermost] <sb10q> Info : JTAG tap: tm4c1294kcpd.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)

05:27 <mtrbot-ml> [mattermost] <sb10q> Info : DAP transaction stalled (WAIT) - slowing down

05:27 <mtrbot-ml> [mattermost] <sb10q> Error: Timeout during WAIT recovery

05:27 <mtrbot-ml> [mattermost] <sb10q> Error: Debug regions are unpowered, an unexpected reset might have happened

05:27 <mtrbot-ml> [mattermost] <sb10q> ```

05:33 <mtrbot-ml> [mattermost] <sb10q> same bug with openocd 0.10.0

09:15 <mtrbot-ml> [mattermost] <hartytp> @sb10q wrong open ocd config?

09:15 <mtrbot-ml> [mattermost] <hartytp> https://paste.debian.net/1093444/

09:16 <mtrbot-ml> [mattermost] <hartytp> how are you powering it?

09:16 <mtrbot-ml> [mattermost] <hartytp> I had GDB up and running before I sent it to you

09:22 <mtrbot-ml> [mattermost] <sb10q> @hartytp the one from ionpak... didn't modify it

09:22 <mtrbot-ml> [mattermost] <sb10q> PoE, also tried the 12V barrel connector, same thing

09:23 <mtrbot-ml> [mattermost] <hartytp> don't you need to modify?

09:23 <mtrbot-ml> [mattermost] <hartytp> slightly different cpu part

09:23 <mtrbot-ml> [mattermost] <hartytp> I had no issues with the config file I posted

09:23 <mtrbot-ml> [mattermost] <sb10q> same + additional error with your file

09:24 <mtrbot-ml> [mattermost] <sb10q> http://paste.debian.net/1093447/

09:24 <mtrbot-ml> [mattermost] <hartytp> what's the new error?

09:24 <mtrbot-ml> [mattermost] <sb10q> also I'm using this JTAG cable source [find interface/ftdi/olimex-arm-usb-tiny-h.cfg]

09:25 <mtrbot-ml> [mattermost] <sb10q> also craps out in the same way with adapter_khz 10

09:27 <mtrbot-ml> [mattermost] <hartytp> that's odd. I didn't have any issues using the STLink adapter I had with: GNU MCU Eclipse OpenOCD, 64-bitOpen On-Chip Debugger 0.10.0+dev-00593-g23ad80df4 (2019-04-22-20:18)

09:28 <mtrbot-ml> [mattermost] <hartytp> IIRC @rjo got his card to work, so may have some advice. Otherwise, i'd check the obvious things like all relevant voltages, etc

09:30 <mtrbot-ml> [mattermost] <hartytp> are you using JTAG or SWDB?

09:35 <mtrbot-ml> [mattermost] <sb10q> JTAG

09:36 <mtrbot-ml> [mattermost] <hartytp> well, this isn't something I know a huge amount about, so prob nothing very productive I can add here

09:36 <mtrbot-ml> [mattermost] <sb10q> or maybe we can SSH into your computer where there's a working setup. debugging this kind of typical embedded system behavior is frustrating, and a waste of time since we won't use tm4c in the end

09:38 <mtrbot-ml> [mattermost] <hartytp> maybe, but getting you VPN access could be a hassle. In the first instance, I'd prefer to try shipping you the ST-Link adapter that I got it up and running with

09:38 <mtrbot-ml> [mattermost] <hartytp> but, let's see if @rjo has any ideas first

09:39 <mtrbot-ml> [mattermost] <hartytp> and, please do stick a DMM on all supplies first in case something broke during shipping

09:39 <mtrbot-ml> [mattermost] <hartytp> (if you haven't already)

10:00 <rjo[m]> i haven't used jtag on arm chips in a while. swd worked fine.

10:07 <mtrbot-ml> [mattermost] <sb10q> @rjo maybe we could use your setup remotely then?

10:12 <mtrbot-ml> [mattermost] <sb10q> IC4 (reset chip) seems to have been removed; is that normal?

10:13 <mtrbot-ml> [mattermost] <sb10q> voltage on the tantalum caps is 5V/12V which looks normal

10:16 <mtrbot-ml> [mattermost] <sb10q> other supplies are harder to locate. might be a good idea to add test points on v2 (seems that's not done according to the sch)

10:19 <mtrbot-ml> [mattermost] <sb10q> the 3.3V from IC3 is also OK

12:45 <rjo[m]> what do you want to do? i'd have to set it up again. currently the probe is in use.

13:18 <mtrbot-ml> [mattermost] <sb10q> develop the test firmware (pwm and adc)

13:19 <mtrbot-ml> [mattermost] <sb10q> or @hartytp could send me a probe, but then there's the risk that the problem is elsewhere and it still won't work