**** BEGIN LOGGING AT Fri Jan 29 03:02:12 2021 Jan 29 07:45:22 zmatt: isn't every JTAG signal supposed to be synchronous to TCK? Except nTRST? Jan 29 07:46:47 yep, target samples TMS and TDI on rising edge of TCK, updates TDO on falling edge of TCK Jan 29 07:47:21 zmatt: so if the outputs change in between, that's not expected, right? Jan 29 07:47:49 zmatt: and inputs, too... Jan 29 07:48:18 zmatt: I'm staring at some vhdl code for the output buffer of a JTAG adapter and it seems plain wrong... Jan 29 07:49:02 well unless it's trying to do some cJTAG (TAP.7) stuff Jan 29 07:49:30 which has some escape sequences that use TMS pulses while TCK is high Jan 29 07:50:27 of course a jtag adapter is free to change TMS and/or TDI while TCK is low, that has no semantic meaning Jan 29 07:51:28 I'm just not getting the sensitivity list of the process that updates the signals between the FTDI and the JTAG interface... Jan 29 07:51:53 what are you looking at? Jan 29 07:52:07 let me pastebin Jan 29 07:52:37 so this vhdl is for some interface logic after the FTDI, similar to the CPLD in TI's XDS100v2 ? Jan 29 07:52:50 (which is mostly a glorified level shifter) Jan 29 07:53:26 https://pastebin.com/vG9VCrNS Jan 29 07:53:31 yes Jan 29 07:53:41 busblaster v4, dangerous prototypes Jan 29 07:54:19 first thing I'm seeing is "SWDIO" so clearly this thing is not just for JTAG but also for SWD Jan 29 07:54:26 yep Jan 29 07:54:26 and I'm seeing RTCK Jan 29 07:54:54 so that already creates a bunch of exceptions to the simple JTAG model Jan 29 07:55:22 so what part is unclear? Jan 29 07:55:43 the sensitivity list of the "process" Jan 29 07:56:24 is that not simply "everything" ? Jan 29 07:56:40 like, the CPLD is being used as combinatorial logic Jan 29 07:56:44 clearly Jan 29 07:56:50 this isn't synchronous logic Jan 29 07:57:05 the protocol is made by the FTDI Jan 29 07:58:02 this is just some muxes and tristate buffers combined Jan 29 07:58:41 looks like it's completely stateless even Jan 29 08:10:23 thinkfat: https://pastebin.com/raw/yVEke005 Jan 29 08:10:35 internet went out Jan 29 08:10:49 DSL line is down :-/ Jan 29 08:10:54 I figured Jan 29 08:11:52 yeah, it's sensitive to "everything", but then why use a process at all? Jan 29 08:12:16 easier to read then writing separate expressions for all lines Jan 29 08:12:31 because SWD and JTAG mode have rather different assignments Jan 29 08:13:25 I assume anyway... my knowledge of vhdl is very limited Jan 29 08:13:27 but can the logic not be formulated without the process? A process just makes stuff synchronous to certain events... Jan 29 08:13:55 ok.. Jan 29 08:14:03 with a bit of luck it gets optimized away Jan 29 08:14:14 I think I need to update my knowledge about vhdl a bit. Jan 29 08:14:30 like, a process which clearly has no state and which is sensitive to all inputs used is clearly just combinatorial logic Jan 29 08:14:44 that's easy enough for a compiler to infer too Jan 29 08:16:25 I do vaguely remember a "do always" kind of construct though... or is that verilog? Jan 29 08:16:46 that would be better than individual sensitivities Jan 29 08:21:55 I guess you're correct about the convenience aspect Jan 29 08:23:53 outside of a "process", you cannot use "if" in the simple way it's written here, because each statement is supposed to just "assign" some input expression to an output (or an internal buffer) Jan 29 08:25:10 so it's written like that for clarity and simplicity, instead of having a complex expression for each buffer Jan 29 08:25:17 ah, and an always-block without sensitivity list is indeed verilog Jan 29 08:27:39 never mind, that means no sensitivity, but it does have always @(*) Jan 29 08:28:11 "Verilog 2001 first introduced always @* as a shortcut to code combinational logic. The always @* is intended to infer a complete sensitivity list for both RTL simulation and synthesis from the contents of the block, saving a designer from having to manually specify a sensitivity list to code combinational logic." Jan 29 08:28:27 oh, ok Jan 29 08:28:35 so that's just "how it's meant to be". Jan 29 08:28:38 maybe vhdl has something similar, maybe not Jan 29 08:28:48 presumably if it had, they would have used it in this case Jan 29 08:29:00 likely Jan 29 08:29:17 so, it's not "wrong", it's just how you write that kind of stuff in vhdl Jan 29 08:30:09 it's kind of annoying, since it means you have to be careful to keep the sensitivity list in sync with the code inside it, and if it's out of sync you won't get an error but will get weird problems Jan 29 08:30:29 and your supposed-to-be-combinatorial logic will suddenly be stateful Jan 29 08:34:29 indeed Jan 29 08:34:41 Xilinx ISE gives a warning though if you forget it Jan 29 08:35:22 forget what? Jan 29 08:36:02 it checks every variable that is evaluated inside the process and warns you if it's missing in the sensitivity list Jan 29 08:36:05 in synchronous logic it's extremely normal to not be sensitive on all inputs (in fact usually you'll only be sensitive on the clock) so how would it know you "forgot" a sensitivity? Jan 29 08:36:13 rather than it being intentional Jan 29 08:36:37 yes, I get that, nevertheless it outputs a warning Jan 29 08:36:42 how bizarre Jan 29 08:37:12 I wonder if it somehow guesses whether the process is meant to be synchronous or not Jan 29 08:38:00 indeed Jan 29 08:39:37 still, I think being able to specify * in the sensitivity list would be a significant improvement Jan 29 08:39:57 but I do remember vhdl being a bit verbose in general Jan 29 08:53:08 well, I can have ISE show a "schematic" of the RTL to check what was synthesized Jan 29 08:53:18 but it's kind of convoluted Jan 29 08:59:28 though, I see no flip-flops, so apparently it guessed correctly about the process being just combinatorial Jan 29 09:41:13 well it doesn't need to guess that part if the sensitivities are specified correctly Jan 29 09:42:16 interestingly, no flip-flips appear if I make the process sensitive only to tck... I wonder why... Jan 29 09:42:31 I must be missing something Jan 29 09:42:47 yeah that doesn't sound right Jan 29 09:43:47 cplds do contain some flip-flops? right? Jan 29 09:44:09 probably depends on the cpld Jan 29 09:44:26 anyway, this should not influece the synthesis, it should complain afterwards if it cannot fit the design Jan 29 09:44:31 they don't have to, you can synthesize them if needed Jan 29 09:44:40 well, indeed... Jan 29 09:45:25 originally I think cplds were just sum-of-products (i.e. a bunch of AND-terms ORed together) Jan 29 09:45:57 like a gal or pal Jan 29 09:47:25 all that hassle for one careless "nand erase"... Jan 29 09:47:39 ? Jan 29 09:47:46 I was being stupid Jan 29 09:47:58 killed the boot flash of a device I was working on Jan 29 09:48:07 lol Jan 29 09:48:20 then I needed the jtag and I needed a console UART Jan 29 09:48:27 and one thing lead to anohter Jan 29 09:50:30 and yeah, a CPLD is like a bunch of PLA devices with configurable internal interconnect (allowing for feedback) Jan 29 09:50:39 traditionally anyway Jan 29 09:51:18 iirc the coolrunner-II (the only cpld I ever dug into a little bit) does embed blocks with a flip flop Jan 29 09:51:42 that's what is on the jtag Jan 29 09:51:47 rather big one, too Jan 29 09:52:08 xc2c64a Jan 29 09:53:02 the TI XDS100v2 which is still my favorite of all JTAG debuggers I've used, uses one too... the xc2c32a Jan 29 09:53:18 kinda funny it uses a smaller CPLD, since its logic is more complex than what you showed Jan 29 09:53:53 indeed Jan 29 09:54:20 the previous busblaster v3 had the xc2c32a but for some reason they decided they needed the bigger one Jan 29 09:54:33 it has one bit of state: if it detects target power loss, it tristates all target-side pins except optionally (based on some pins from the FTDI) it can pull EMU0 and/or EMU1 low (used to select certain modes at power-on) Jan 29 09:54:54 until power is back and the debugger acknowledges the power loss by toggling a line Jan 29 09:55:33 that not a bad idea... Jan 29 09:55:42 the reason I like the xds100v2 is because it's extremely well-behaved electrically Jan 29 09:55:46 tristating the pins Jan 29 09:56:21 you can hot-connect it without any risk of resetting the target by accident, you can leave it connected to the target while either the debugger or the target is unpowered Jan 29 09:57:32 all too often debuggers one or more of these things up Jan 29 09:57:40 *fuck one or more of these things up Jan 29 09:58:01 using an ftdi still sucks, but eh Jan 29 12:06:58 ftdi sucks but no too much Jan 29 12:07:19 it's kind of slower than it needed to be but meh... Jan 29 12:08:24 I'm sure using some cypress thingy or a small fpga could be faster but at what cost.. Jan 29 12:09:04 beaglebone with its PRU Jan 29 12:09:31 those cypress things with an 8051 uC? Jan 29 12:09:37 totally... but more expensive than a ftdi Jan 29 12:10:09 yeah but you could have openocd communicate directly with PRU via shared memory... it could be *very* fast Jan 29 12:11:21 though making a trace receiver may be higher on my priority list than a jtag adapter Jan 29 12:14:00 indeed Jan 29 12:14:03 that would be something Jan 29 12:14:43 but that's something I'd rather use a zynq for Jan 29 12:15:36 you can get decommisioned bitcoin miner boards for $10 nowadays, with a nice zynq-7000 on it, dual core even Jan 29 12:16:19 you'll have to deal with vivado though, to program the PL Jan 29 12:18:26 I don't know how complex the trace frontend would be, but I guess it's basically a latch? Jan 29 12:19:20 depends on which trace interface you're using Jan 29 12:19:55 and that thing sounds like overkill Jan 29 12:20:23 depends on how fast a source you want to trace ;) Jan 29 12:20:25 also, putting energy into repurposed boards with presumably no schematics and limited availability doesn't sound like a great time-investment Jan 29 12:20:29 sure Jan 29 12:20:50 well, a zedboard isn't expensive either Jan 29 12:21:33 actually, for the most common board (ebaz4205) there's schematics, even a full project in KiCAD ;) Jan 29 12:23:10 though commercially, it's a complete waste of time, sure Jan 29 12:23:26 I don't just mean commercially Jan 29 12:23:45 anyway, for my purposes I'm pretty sure PRU would be fine, so I'd just stick to what I already know Jan 29 12:24:27 not that I expect to get around to it anyway :P Jan 29 12:24:54 well yes there's that "time" resource... Jan 29 14:10:10 another day, another failed kernel update Jan 29 14:10:22 this time it's an am3517 Jan 29 14:11:33 omap3-but-not-quite Jan 29 14:11:39 that's the one Jan 29 14:14:50 btw, dunno if you're affected, but just in case it's useful to know: the "No workaround." for erratum 1.0.38 "GPMC Has Incorrect ECC Computation for 4-bit BCH Mode" is false, there's a pretty simple workaround Jan 29 14:15:37 whatever we're using works, so I'd rather not mess with that right now Jan 29 14:15:48 probably 8-bit BCH Jan 29 14:15:51 if you're using NAND Jan 29 14:16:25 or software ECC instead of letting the hardware do most of the work Jan 29 14:23:05 I actually posted the workaround to E2E in june 2014 ( https://e2e.ti.com/support/legacy_forums/omap/f/447/p/349230/1227573 ) ... kinda sad that the am35xx errata doc published two years later still says there's no workaround Jan 30 02:13:25 GenTooMan: Any other items of interest for motors we can discuss would be a good starting point. Armature and not stator windings. Yikes. Jan 30 02:13:37 I call blue orange and green. Jan 30 02:13:58 My illness is cured. I will start to think before I type. Jan 30 02:15:03 I read about some Chinese bot online. It had a write up and everything. Open Source bot but it used atmel instead of the complexity of am335x. So, I moved on. Jan 30 02:15:28 They made a power adapter too! Jan 30 02:15:39 24v! Jan 30 02:15:56 CMOS to 9v input/output! Jan 30 02:16:04 That seems a bit odd, no? Jan 30 02:17:23 Anyway, I hope to hear from you today. I got this messed up bot so far. I need to figure out wires or strings to handle joint action. Jan 30 02:17:44 No easy task is beyond the mechanical w/out 3D Printing. Jan 30 02:18:50 So, to the RepliCape (if I ever figure it out). Gosh. Jan 30 02:19:08 That sensor leveling bed thingy is complicated. Jan 30 02:22:46 That means. More motors or a nice 3D printed thing-a-ma-bobby. Jan 30 02:45:01 I am not affiliated but I am ram-tama-tamed out, bro. This bot is going to be glorious. Just you wait... Jan 30 02:46:41 GenTooMan! Jan 30 02:47:11 What proper steps would one take to handle this so-called bot exploration of a quadruped? Jan 30 02:48:02 For instance...1> Eat breakfast 2> Orientation of the Bot (but where?) 3> Stop being so silly? Jan 30 02:48:14 Fine. Jan 30 02:48:29 Never forget, never surender. Jan 30 02:54:43 All I am sassily saying is that my motor does not work at 25%. It works at 35% for some reason, though. Jan 30 02:55:53 I cannot run it below 25% either. Maybe this is due to a heat dissipation issue? Jan 30 02:57:02 For instance, my motor has no fan like w/ other motors that have the fan to keep it from expiry too soon and other issues. Jan 30 02:57:12 I mean... Jan 30 02:57:41 The source says blantantly 25% in and out but it does not listen. **** ENDING LOGGING AT Sat Jan 30 02:59:57 2021