https://libre-soc.org/HDL_workflow/ECP5_FPGA/ http://lists.libre-soc.org/pipermail/libre-soc-dev/2020-October/000873.html ``` see the litex/florent/README.txt you *MIGHT* be able to adapt that to "direct" contact with the HDL running on the FPGA. the thing is: where are you connecting that JTAG to? if you send JTAG commands to the *FPGA* why would you expect the *FPGA* to know about the TAP HDL in the processor core running *on* that FPGA? the JTAG TAP interface on the *FPGA* is hard-coded silicon. the JTAG TAP interface connected on the processor and soft-implemented *by* the FPGA is likely completely inaccessible until someone allocates pins to "jtag_tdi/tdo/tms/tck" in the litex config. which means: someone's going to have to to through this file: https://github.com/enjoy-digital/litex/blob/master/litex/boards/platforms/ulx3s.py#L72 (which defines the pin allocations) and in this file do some Voodoo Magic on this file's TestSoC: https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/litex/florent/ulx3s85f.py;hb=HEAD similar to these four lines: https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/litex/florent/ls180soc.py;h=4279effcffe2fbf15f877e9b2a1b76beab248dac;hb=HEAD#l460 but instead doing something like... err.... gpio0_pads = platform.reqiest("gpio", 0) # because back in ulx3s.py there's gpio 0, 1, and 2 self.comb += self.cpu.jtag_tck.eq(gpio0_pads.p) # because again back in that file there are 2 pins, one named "p", one named "n" self.comb += self.cpu.jtag_tms.eq(gpio0_pads.n) # etc. and then request gpio1 for the other 2 pins theeeen you'll need to go back to that ulx3s.py litex platform file, look up the pin names B11, C11, A10, A11, and find out what the hell they are, whether they're suitable for use. if they are, then great! these are what you wire up the STLINKv2 to, according to what you decided to connect to just above. but for god's sake do not get this wrong, such as driving an input as an output or vice-versa, or wiring up 5.0V to GND with those jumper-cables. do *NOT* randomly upload and power up the ulx3s until this has been THOROUGHLY triple-checked. or, you are entirely free to not bother and to end up learning the hard way by destroying the FPGA. ``` Connecting the dots: litex platform file ```litex-boards/litex_boards/platforms/ulx3s.py ("gpio", 0, Subsignal("p", Pins("B11")), Subsignal("n", Pins("C11")), IOStandard("LVCMOS33") ), ("gpio", 1, Subsignal("p", Pins("A10")), Subsignal("n", Pins("A11")), IOStandard("LVCMOS33") ), ``` ulx3s contstraints file ```github.com/emard/ulx3s/blob/master/doc/constraints/ulx3s_v20.lpf#L341-342 LOCATE COMP "gp[0]" SITE "B11"; # J1_5+ GP0 PCLK LOCATE COMP "gn[0]" SITE "C11"; # J1_5- GN0 PCLK LOCATE COMP "gp[1]" SITE "A10"; # J1_7+ GP1 PCLK LOCATE COMP "gn[1]" SITE "A11"; # J1_7- GN1 PCLK ``` ```https://github.com/emard/ulx3s/blob/master/doc/schematics_v308.pdf J1 J2 PIN number 1-40 is for FEMALE 90° ANGLED header. For MALE VERTICAL header, SWAP EVEN and ODD pin numbers. J1 Label [GP{x}]|PCB pin label|[GN{x}] Label (Pin count +)(Pin count -) _________________V__________V________________ IO VOLT REF 3V3 2 |3.3V| 1 NOT CONNECTED [GND] 4 | -| | 3 NOT CONNECTED PCLKT0_0 [GP0] 6 | 0 | 5 [GN0] PCLKC0_0 PCLKT0_1 [GP1] 8 | 1 | 7 [GN1] PCLKC0_1 GP,GN 0-7 single-ended connected to Bank0 GP,GN 8-13 differential bidirectional connected to BANK7 ``` ``` Connecting all the dots Board pin # (count) | Board pin label # | FPGA IO PAD | GPIO # (n/p) | Label | 5 (J1_5-) | 0 | C11 | gn[0] | PCLKC0_0 | 6 (J1_5+) | 0 | B11 | gp[0] | PCLKT0_0 | 7 (J1_7-) | 1 | A11 | gn[1] | PCLKC0_1 | 8 (J1_7+) | 1 | A10 | gp[1] | PCLKT0_1 | ``` As noted in the schematic pins GP,GN 0-7 are single ended non-differential pairs, whereas pins GP,GN 8-13 I haven't mapped out here as they are bidirectional differential pairs. ```proposed FPGA External Pin to STLINK JTAG pin connections all pin #'s have headers pins on the fpga unless denoted as (no header) ______________________________________________________________________________ | | board | | | | | | | label | | |STLINKV2 JTAG | | | pin # | # | FPGA IO PAD |GPIO # (n/p) | Pin # (Signal)|Wire Colour| |_____________|_______|_____________|_____________|________________|___________| |1 (no header)| 3.3v |NOT CONNECTED|NOT CONNECTED| NOT CONNECTED | NOT | |2 | 3.3v | IO VOLT REF | IO VOLT REF | 2 (MCU VDD) | Red | |3 (no header)|-|(GND)|NOT CONNECTED|NOT CONNECTED| NOT CONNECTED | NOT | |4 |-|(GND)| NONE | GND | 4 (GND) | Black | |5 (J1_5-) | 0 | C11 | gn[0] | 5 (JTDI) | Green | |6 (J1_5+) | 0 | B11 | gp[0] | 7 (JTMS) | Blue | |7 (J1_7-) | 1 | A11 | gn[1] | 9 (JTCK) | White | |8 (J1_7+) | 1 | A10 | gp[1] | 13 (JTDO) | Yellow | |_____________|_______|_____________|_____________|________________|___________| ``` ```complete diagram Pins intentionally have no header or are not connected to the STLINKVT are marked and therefore have no value are marked with 'NOT' (ST# JTAG) = (STLINKV2 pin # JTAG signal name) J1 Wire Wire Colour [GP{x}]|PCB label|[GN{x}] Colour (ST# JTAG) (Pin count +)(Pin count -) (ST# JTAG) ________________________V__________V_________________________ | | |( 2 JVDD) red [VREF] 2 |3.3V| 1 NOT NOT NOT | |( 4 JGND) black [GND] 4 | -| | 3 NOT NOT NOT | |( 7 JTMS) blue [GP0] 6 | 0 | 5 [GN0] green (5 JTDI) | |(13 JTDO) yellow [GP1] 8 | 1 | 7 [GN1] white (9 JTCK) | |_____________________________________________________________| ``` Luke do the labels of PCLK[C|T]0_[0|1] and GR_PCLK0_[0|1] have any significance? Should we be using the CLK labeled pins specifically for JTAG or specifically avoid using them for JTAG? Additionally, does the note in the schematic about needing to swap EVEN and ODD pin numbers if using MALE VERTICAL header instead of FEMALE 90° ANGLED header apply to us?
*** Bug 518 has been marked as a duplicate of this bug. ***
commit 07db89fcd0597d852ea28f4787451b840a7e1a2a (HEAD -> master, origin/master) Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net> Date: Thu Oct 15 21:43:22 2020 +0100 add commented-out connection to JTAG in ECP5 litex cole you should have better luck with the ulx3s because those gpio pins are part of the platform IO. connectors... annoyingly... seem not to be accessible.
(In reply to Luke Kenneth Casson Leighton from comment #2) > commit 07db89fcd0597d852ea28f4787451b840a7e1a2a (HEAD -> master, > origin/master) > Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net> > Date: Thu Oct 15 21:43:22 2020 +0100 > > add commented-out connection to JTAG in ECP5 litex > > cole you should have better luck with the ulx3s because those gpio > pins are part of the platform IO. connectors... annoyingly... seem > not to be accessible. Ok, hopefully! I'll start on this tomorrow, sorry, had a bit of an off day/late start today.
Hi Luke, I read through your instructions and looked and the files that are needed and I think I understand how this will be done. However, I'm getting stuck currently on not being able to find a simple pinout diagram on the ulx3s85f. There are schematics for it which I can't quite make sense of, and there's the exact diagram I'm looking for... but it's for the esp32 module not the ulx3s pcb :( https://github.com/emard/ulx3s/blob/master/doc/ESP32_Pinout_a1_3.png Would this info be in the constraints file? https://github.com/emard/ulx3s/blob/master/doc/constraints/ulx3s_v20.lpf And/or the schematic diagrams? https://github.com/emard/ulx3s/blob/master/doc/schematics_v308.pdf There is a pinout csv file but it has about 1000 entries and looks like it's out of date as it's from 2015. I'm entirely out of my depth here. https://github.com/emard/ulx3s/blob/master/doc/ECP5U85Pinout.csv Sorry, I need some significant help here as this is currently melting my brain.
(In reply to Cole Poirier from comment #4) > Hi Luke, > > I read through your instructions and looked and the files that are needed > and I think I understand how this will be done. However, I'm getting stuck > currently on not being able to find a simple pinout diagram on the ulx3s85f. comment #1. vvvvv which means: someone's going to have to to through this file: https://github.com/enjoy-digital/litex/blob/master/litex/boards/platforms/ulx3s.py#L72 (which defines the pin allocations) ^^^^^
(In reply to Luke Kenneth Casson Leighton from comment #5) > > comment #1. > > vvvvv > which means: someone's going to have to to through this file: > https://github.com/enjoy-digital/litex/blob/master/litex/boards/platforms/ > ulx3s.py#L72 > (which defines the pin allocations) > ^^^^^ Already did this. What I don't know how to do is estaplish the relationship between this ("gpio", 0, Subsignal("p", Pins("B11")), Subsignal("n", Pins("C11")), IOStandard("LVCMOS33") ), and the number on the physical board. Which of the pins numbered 0 through 27 is gpio_0 or B11 or C11?
(In reply to Cole Poirier from comment #6) > Already did this. What I don't know how to do is estaplish the relationship > between this > > ("gpio", 0, > Subsignal("p", Pins("B11")), > Subsignal("n", Pins("C11")), > IOStandard("LVCMOS33") > ), ok so when you do platform.request_resource("gpio", 0) it returns a migen Record containing (in this case) a Signal named "p" and a Signal named "n" each of length "count-the-number-of-things-in-the-string-inside-Pins". you can find this kind of thing out with "print dir(x)" inside the code. where x = platform.request_resource(blah blah) or anything else for that matter. the actual pin name is for *your* convenience when plugging in the jumper wire.
(In reply to Luke Kenneth Casson Leighton from comment #7) > ok so when you do platform.request_resource("gpio", 0) it returns a migen > Record containing (in this case) a Signal named "p" and a Signal named "n" > each of length "count-the-number-of-things-in-the-string-inside-Pins". > > you can find this kind of thing out with "print dir(x)" inside the code. > where x = platform.request_resource(blah blah) or anything else for that > matter. > > the actual pin name is for *your* convenience when plugging in the jumper > wire. I don't fully understand. How do I know which physical pin on the fpga pcb to plug the jumper into/onto? Which pin number 0 thorugh 27 corresponds to gpio_0? Or does it actually correspond to B11?
(In reply to Cole Poirier from comment #8) > I don't fully understand. How do I know which physical pin on the fpga pcb > to plug the jumper into/onto? Which pin number 0 thorugh 27 corresponds to > gpio_0? Or does it actually correspond to B11? > Subsignal("p", Pins("B11")), > Subsignal("n", Pins("C11")), gpio 0, p == B11. gpio 0, n == C11.
(In reply to Luke Kenneth Casson Leighton from comment #9) > (In reply to Cole Poirier from comment #8) > > > I don't fully understand. How do I know which physical pin on the fpga pcb > > to plug the jumper into/onto? Which pin number 0 thorugh 27 corresponds to > > gpio_0? Or does it actually correspond to B11? > > > Subsignal("p", Pins("B11")), > > Subsignal("n", Pins("C11")), > > gpio 0, p == B11. > gpio 0, n == C11. Which physical pin is B11? They aren't labelled that way, they are labelled 0 through 27, no letters.
(In reply to Cole Poirier from comment #10) > Which physical pin is B11? They aren't labelled that way, they are labelled > 0 through 27, no letters. then i have no idea. it will be necessary to track down the person who wrote the litex platform file and ask them (not me).
(In reply to Cole Poirier from comment #10) > (In reply to Luke Kenneth Casson Leighton from comment #9) > > (In reply to Cole Poirier from comment #8) > > > > > I don't fully understand. How do I know which physical pin on the fpga pcb > > > to plug the jumper into/onto? Which pin number 0 thorugh 27 corresponds to > > > gpio_0? Or does it actually correspond to B11? > > > > > Subsignal("p", Pins("B11")), > > > Subsignal("n", Pins("C11")), > > > > gpio 0, p == B11. > > gpio 0, n == C11. > > Which physical pin is B11? They aren't labelled that way, they are labelled > 0 through 27, no letters. B11 is the name of one of the FPGA's solder balls directly on the chip's package, (B row/column 11 column/row). look up the datasheet for your board to find out the mapping between solder balls and header pins.
(In reply to Jacob Lifshay from comment #12) > B11 is the name of one of the FPGA's solder balls directly on the chip's > package, (B row/column 11 column/row). look up the datasheet for your board > to find out the mapping between solder balls and header pins. ahh brilliant, that's very helpful jacob, that wouldn't have occurred to me that it was the actual ECP5 pad. ah wait.. yeah of course it is, because nextpnr-ecp5 doesn't know about PCB layouts, it only knows about, well... the ECP5.
(In reply to Luke Kenneth Casson Leighton from comment #13) > (In reply to Jacob Lifshay from comment #12) > > > B11 is the name of one of the FPGA's solder balls directly on the chip's > > package, (B row/column 11 column/row). look up the datasheet for your board > > to find out the mapping between solder balls and header pins. > > ahh brilliant, that's very helpful jacob, that wouldn't have occurred to me > that it was the actual ECP5 pad. > > ah wait.. yeah of course it is, because nextpnr-ecp5 doesn't know about PCB > layouts, it only knows about, well... the ECP5. Awesome thanks so much! That makes sense! Will do tomorrow.
Ok so from the contsraints file: ``` LOCATE COMP "gp[0]" SITE "B11"; # J1_5+ GP0 PCLK LOCATE COMP "gn[0]" SITE "C11"; # J1_5- GN0 PCLK LOCATE COMP "gp[1]" SITE "A10"; # J1_7+ GP1 PCLK LOCATE COMP "gn[1]" SITE "A11"; # J1_7- GN1 PCLK LOCATE COMP "gp[2]" SITE "A9"; # J1_9+ GP2 GR_PCLK LOCATE COMP "gn[2]" SITE "B10"; # J1_9- GN2 GR_PCLK LOCATE COMP "gp[3]" SITE "B9"; # J1_11+ GP3 LOCATE COMP "gn[3]" SITE "C10"; # J1_11- GN3 LOCATE COMP "gp[4]" SITE "A7"; # J1_13+ GP4 LOCATE COMP "gn[4]" SITE "A8"; # J1_13- GN4 LOCATE COMP "gp[5]" SITE "C8"; # J1_15+ GP5 LOCATE COMP "gn[5]" SITE "B8"; # J1_15- GN5 LOCATE COMP "gp[6]" SITE "C6"; # J1_17+ GP6 LOCATE COMP "gn[6]" SITE "C7"; # J1_17- GN6 ``` And the litex platform file: ``` ("gpio", 0, Subsignal("p", Pins("B11")), Subsignal("n", Pins("C11")), IOStandard("LVCMOS33") ), ("gpio", 1, Subsignal("p", Pins("A10")), Subsignal("n", Pins("A11")), IOStandard("LVCMOS33") ), ("gpio", 2, Subsignal("p", Pins("A9")), Subsignal("n", Pins("B10")), IOStandard("LVCMOS33") ), ("gpio", 3, Subsignal("p", Pins("B9")), Subsignal("n", Pins("C10")), IOStandard("LVCMOS33") ), ``` does this imply that another 3 gpio record can be added? like so: ``` ("gpio", 4, Subsignal("p", Pins("A7")), Subsignal("n", Pins("A8")), IOStandard("LVCMOS33") ), ("gpio", 5, Subsignal("p", Pins("C8")), Subsignal("n", Pins("B8")), IOStandard("LVCMOS33") ), ("gpio", 4, Subsignal("p", Pins("C6")), Subsignal("n", Pins("C7")), IOStandard("LVCMOS33") ), ``` And should these newly added gpio pins be the pins we use for the JTAG jumper cables?
(In reply to Cole Poirier from comment #15) > does this imply that another 3 gpio record can be added? probably. however only if the schematic brings them out. > And should these newly added gpio pins be the pins we use for the JTAG > jumper cables? is there anything wrong with the 6 already being brought out? genuine question: only looking at the schematic will answer that.
Additional relevant details taken from https://github.com/emard/ulx3s/blob/master/doc/constraints/ulx3s_v20.lpf#L326-340: ``` # GPIO (default single-ended) "gpio", "ram", "gpdi" sheet # Physical connector pins: # *** when FEMALE ANGLED (90 deg PMOD) soldered *** # Jm_n- = Jm_n, Jm_n+ = Jm_n+1 # example: J1_5- is J1_5 phsyical, J1_5+ is J1_6 physical # *** when MALE VERTICAL soldered *** # Jm_n+ = Jm_n, Jm_n- = Jm_n+1 # example: J1_5+ is J1_5 physical, J1_5- is J1_6 physical # Pins enumerated gp[0-27], gn[0-27]. # With differential mode enabled on Lattice, # gp[] (+) are used, gn[] (-) are ignored from design # as they handle inverted signal by default. # To enable differential, rename LVCMOS33->LVCMOS33D # To enable clock i/o, add this (example): #FREQUENCY PORT "gp[12]" 25.00 MHZ; ``` Photo of the board showing the pins labelled with numbers 0-27. > is there anything wrong with the 6 already being brought out? > genuine question: only looking at the schematic will answer that. I can't read schematics, can you? Or do I contact the ulx3s developer? edit: schematic link https://github.com/emard/ulx3s/blob/master/doc/schematics_v308.pdf I thought it could be answerd using just the schematics file... can you take a look at the gpio section of the constraints file which I have linked at the top of this comment? It seems like 'PCLK', 'GR_PCLK', and the absence of any qualifier at the right most end of each of the lines might be significant.
(In reply to Cole Poirier from comment #17) > I can't read schematics, can you? Or do I contact the ulx3s developer? yeah you can, don't give yourself gip :) hint: follow the wires. or, in the case of KiCAD, follow the labels (boxes with an arrow at the end). really we want the single-ended (non-differential-pair) > I thought it could be answerd using just the schematics file... can you take > a look at the gpio section of the constraints file which I have linked at > the top of this comment? nooo: you can do it :) by tracking the names like "GP-GN 0-7" such as GP0 on page 2 area B1
(In reply to Luke Kenneth Casson Leighton from comment #18) > yeah you can, don't give yourself gip :) hint: follow the wires. or, in > the case of KiCAD, follow the labels (boxes with an arrow at the end). Thanks! I was just nervous because I *can't* mess this up. > really we want the single-ended (non-differential-pair) Noted. Will do. > > I thought it could be answerd using just the schematics file... can you take > > a look at the gpio section of the constraints file which I have linked at > > the top of this comment? > > nooo: you can do it :) by tracking the names like "GP-GN 0-7" such as GP0 on > page 2 area B1 Ok, looking now.
(In reply to Cole Poirier from comment #19) > Thanks! I was just nervous because I *can't* mess this up. well you can: it just has consequences. which cannot occur if you don't plug in any wires to the jumper points. have you connected any? no. so stop frickin panicking!
(In reply to Luke Kenneth Casson Leighton from comment #20) > > well you can: it just has consequences. which cannot occur if you don't > plug in any wires to the jumper points. have you connected any? no. so stop > frickin panicking! Correct. Ok will do :) I think I understand it now. The constraints file, the schematic, and the litex files all fit together in my head. What I'm unsure of now is how I should communicate this here, and what I need to communicate.
(In reply to Cole Poirier from comment #21) > I think I understand it now. The constraints file, the schematic, and the > litex files all fit together in my head. good. it is a series of dots. > What I'm unsure of now is how I > should communicate this here, and what I need to communicate. connect the dots, right back in comment #1. write it out (here, as bulletpoints, editing comment 1 to do so) what is connected to what?
(In reply to Luke Kenneth Casson Leighton from comment #22) > > connect the dots, right back in comment #1. > > write it out (here, as bulletpoints, editing comment 1 to do so) what is > connected to what? Makes sense, will do tomorrow morning.
Starting my dot connecting now, sorry, bit of an odd couple of days, I actually had stuff going on in the physical world which is unusual.
(In reply to Cole Poirier from comment #24) > Starting my dot connecting now, sorry, bit of an odd couple of days, I > actually had stuff going on in the physical world which is unusual. Ok done connecting the dots. I have connected the dots by editing the top comment, please take a look at the updated top comment.
Picture of board https://github.com/emard/ulx3s/blob/master/pic/ulx3sb.jpg
(In reply to Cole Poirier from comment #26) > Picture of board https://github.com/emard/ulx3s/blob/master/pic/ulx3sb.jpg Same orientation as schematic https://github.com/emard/ulx3s/blob/master/pic/ulx3st.jpg
https://www.st.com/resource/en/user_manual/dm00026748-stlinkv2-incircuit-debuggerprogrammer-for-stm8-and-stm32-stmicroelectronics.pdf
```proposed FPGA External Pin to STLINK JTAG pin connecitons pin # | label # | FPGA IO PAD | GPIO # (n/p) | JTAG Pin # (Signal) | 1 | 3.3v | NONE | 3v3 | 1 (MCU VDD) | 2 | 3.3v | NONE | 3v3 | 2 (MCU VDD) | 3 | -|(GND) | NONE | GND | 3 (JNTRST) | 4 | -|(GND) | NONE | GND | 4 (GND) | 5 (J1_5-) | 0 | C11 | gn[0] | 5 (JTDI) | 6 (J1_5+) | 0 | B11 | gp[0] | 7 (JTMS) | 7 (J1_7-) | 1 | A11 | gn[1] | 9 (JTCK) | 8 (J1_7+) | 1 | A10 | gp[1] | 13 (JTDO) | 9 (J1_9-) | 2 | B10 | gn[2] | NONE | 10 (J1_9+) | 2 | A9 | gp[2] | NONE | ``` ```proposed nmigen in litex/florent/versa_ecp5.py gpio0 = self.platform.request("gpio", 0) gpio1 = self.platform.request("gpio", 1) jtag_tdi = gpio0.n jtag_tms = gpio0.p jtag_tck = gpio1.n jtag_tdo = gpio1.p # wire the pins up to CPU JTAG self.comb += self.cpu.jtag_tdi.eq(jtag_tdi) self.comb += self.cpu.jtag_tms.eq(jtag_tms) self.comb += self.cpu.jtag_tdi.eq(jtag_tdi) self.comb += jtag_tdo.eq(self.cpu.jtag_tdo) ``` Hi Luke, here is my plan for the physical connecting of the FPGA gpio pins to the STLINK JTAG pins, and the nmigen code to initialize these selected gpio pins as the 4 necessary JTAG pins. Can you approve this?
(In reply to Cole Poirier from comment #29) > ```proposed FPGA External Pin to STLINK JTAG pin connecitons > pin # | label # | FPGA IO PAD | GPIO # (n/p) | JTAG Pin # (Signal) | > 1 | 3.3v | NONE | 3v3 | 1 (MCU VDD) | > 2 | 3.3v | NONE | 3v3 | 2 (MCU VDD) | good, yes. the power *from* the ulx3s goes *into* the IO side of the STLinkv2 so as to provide the Reference Voltage it needs relative to ulx3s's IO. > 3 | -|(GND) | NONE | GND | 3 (JNTRST) | don't connect up reset, it's a driving pin (output) and it looks like you shorted it to GND. that would damage the STLinkv2. we're running "soft" reset (which is done with 5 ticks of TMS set to 1 i think) > 4 | -|(GND) | NONE | GND | 4 (GND) | > 5 (J1_5-) | 0 | C11 | gn[0] | 5 (JTDI) | > 6 (J1_5+) | 0 | B11 | gp[0] | 7 (JTMS) | > 7 (J1_7-) | 1 | A11 | gn[1] | 9 (JTCK) | > 8 (J1_7+) | 1 | A10 | gp[1] | 13 (JTDO) | these look good i.e. accurate n0 p0 n1 p1 to the platform request below > 9 (J1_9-) | 2 | B10 | gn[2] | NONE | > 10 (J1_9+) | 2 | A9 | gp[2] | NONE | > ``` > > ```proposed nmigen in litex/florent/versa_ecp5.py > gpio0 = self.platform.request("gpio", 0) > gpio1 = self.platform.request("gpio", 1) > > > jtag_tdi = gpio0.n > jtag_tms = gpio0.p > jtag_tck = gpio1.n > jtag_tdo = gpio1.p > > # wire the pins up to CPU JTAG > self.comb += self.cpu.jtag_tdi.eq(jtag_tdi) > self.comb += self.cpu.jtag_tms.eq(jtag_tms) > self.comb += self.cpu.jtag_tdi.eq(jtag_tdi) > self.comb += jtag_tdo.eq(self.cpu.jtag_tdo) > ``` yeah that looks good to me > Hi Luke, here is my plan for the physical connecting of the FPGA gpio pins > to the STLINK JTAG pins, and the nmigen code to initialize these selected > gpio pins as the 4 necessary JTAG pins. Can you approve this? no i cannot. i can help you *review* it however i am not going to "approve" it because it's your hardware, and your responsibility to make sure the connections are right and don't involve any short-circuits. if i "approve" it, you might make the mistake of thinking that *i* am taking that responsibility away from you.
(In reply to Luke Kenneth Casson Leighton from comment #30) > (In reply to Cole Poirier from comment #29) > > ```proposed FPGA External Pin to STLINK JTAG pin connecitons > > pin # | label # | FPGA IO PAD | GPIO # (n/p) | JTAG Pin # (Signal) | > > 1 | 3.3v | NONE | 3v3 | 1 (MCU VDD) | > > 2 | 3.3v | NONE | 3v3 | 2 (MCU VDD) | > > good, yes. the power *from* the ulx3s goes *into* the IO side of the > STLinkv2 > so as to provide the Reference Voltage it needs relative to ulx3s's IO. Understood. > > 3 | -|(GND) | NONE | GND | 3 (JNTRST) | > > don't connect up reset, it's a driving pin (output) and it looks like you > shorted it to GND. that would damage the STLinkv2. Ok. I would not have been able to figure that out on my own. Where can I learn these fundamental principles of electronics? > we're running "soft" reset (which is done with 5 ticks of TMS set to 1 i > think) Ok, understood. > > 4 | -|(GND) | NONE | GND | 4 (GND) | > > 5 (J1_5-) | 0 | C11 | gn[0] | 5 (JTDI) | > > 6 (J1_5+) | 0 | B11 | gp[0] | 7 (JTMS) | > > 7 (J1_7-) | 1 | A11 | gn[1] | 9 (JTCK) | > > 8 (J1_7+) | 1 | A10 | gp[1] | 13 (JTDO) | > > these look good i.e. accurate n0 p0 n1 p1 to the platform request below Great. > > 9 (J1_9-) | 2 | B10 | gn[2] | NONE | > > 10 (J1_9+) | 2 | A9 | gp[2] | NONE | > > ``` > > > > ```proposed nmigen in litex/florent/versa_ecp5.py > > gpio0 = self.platform.request("gpio", 0) > > gpio1 = self.platform.request("gpio", 1) > > > > > > jtag_tdi = gpio0.n > > jtag_tms = gpio0.p > > jtag_tck = gpio1.n > > jtag_tdo = gpio1.p > > > > # wire the pins up to CPU JTAG > > self.comb += self.cpu.jtag_tdi.eq(jtag_tdi) > > self.comb += self.cpu.jtag_tms.eq(jtag_tms) > > self.comb += self.cpu.jtag_tdi.eq(jtag_tdi) > > self.comb += jtag_tdo.eq(self.cpu.jtag_tdo) > > ``` > > yeah that looks good to me > > > Hi Luke, here is my plan for the physical connecting of the FPGA gpio pins > > to the STLINK JTAG pins, and the nmigen code to initialize these selected > > gpio pins as the 4 necessary JTAG pins. Can you approve this? > > no i cannot. i can help you *review* it however i am not going to "approve" > it because it's your hardware, and your responsibility to make sure the > connections are right and don't involve any short-circuits. > > if i "approve" it, you might make the mistake of thinking that *i* am taking > that responsibility away from you. Yes understood. However, see my comment above about the short to ground, I lack even the basic understanding of this in order to be able to make sure connections are right and don't involve any short circuits. So while I want to take responsibility for this, I need help obtaining the knowledge necessary for this to be possible. ```NEW proposed FPGA External Pin to STLINK JTAG pin connecitons pin # | label # | FPGA IO PAD | GPIO # (n/p) | JTAG Pin # (Signal) | 1 | 3.3v | NONE | 3v3 | 1 (MCU VDD) | 2 | 3.3v | NONE | 3v3 | 2 (MCU VDD) | 4 | -|(GND) | NONE | GND | 4 (GND) | 5 (J1_5-) | 0 | C11 | gn[0] | 5 (JTDI) | 6 (J1_5+) | 0 | B11 | gp[0] | 7 (JTMS) | 7 (J1_7-) | 1 | A11 | gn[1] | 9 (JTCK) | 8 (J1_7+) | 1 | A10 | gp[1] | 13 (JTDO) | ``` Can you review the new proposed connection plan?
(In reply to Cole Poirier from comment #31) > > > 3 | -|(GND) | NONE | GND | 3 (JNTRST) | > > > > don't connect up reset, it's a driving pin (output) and it looks like you > > shorted it to GND. that would damage the STLinkv2. > > Ok. I would not have been able to figure that out on my own. Where can I > learn these fundamental principles of electronics? a search "short circuit" gives a good explanation https://en.m.wikipedia.org/wiki/Short_circuit in this case, one of the voltages is "GND" and the other would have been "JNTRST". > Can you review the new proposed connection plan? if it is no different other than removing the RST signal it looks good. btw again, reminder to trim context in replies.
(In reply to Luke Kenneth Casson Leighton from comment #32) > (In reply to Cole Poirier from comment #31) > > a search "short circuit" gives a good explanation > https://en.m.wikipedia.org/wiki/Short_circuit > > in this case, one of the voltages is "GND" and the other would have been > "JNTRST". Oh doy! Thank you. > if it is no different other than removing the RST signal it looks good. > > btw again, reminder to trim context in replies. Yes sorry wasn't thinking (about the reply context, not the connection plan). Is the next step committing the code, soldering the gpio headers, then connecting it all together?
(In reply to Cole Poirier from comment #33) > Is the next step committing the code, should have done that ages ago because it can't do "harm", can it? > soldering the gpio headers, then > connecting it all together? after checking abour another 3 or 4 times yes.
(In reply to Luke Kenneth Casson Leighton from comment #34) > (In reply to Cole Poirier from comment #33) > > > Is the next step committing the code, > > should have done that ages ago because it can't do "harm", can it? Indeed. The code was only done recently as it relied upon the connections being made here. > > soldering the gpio headers, then > > connecting it all together? > > after checking abour another 3 or 4 times yes. Ok I've soldered the header on. Then *WITHOUT* power to the FPGA and *WITHOUT* power to the STLINKV2 (i.e. *NO* power, or any other wires connected to either) have wired up the jumper connections so that it can be checked here, will upload the two necessary images right after this comment.
Created attachment 113 [details] FPGA JTAG wires Luke this is the image of the jumpers connected to the FPGA header pins
Created attachment 114 [details] STLINKV2 JTAG wires Luke, this is the image of the jtag jumper wires from the above FPGA JTAG wires image, connected to the STLINKV2 pins
(In reply to Cole Poirier from comment #37) > Created attachment 114 [details] > STLINKV2 JTAG wires > > Luke, this is the image of the jtag jumper wires from the above FPGA JTAG > wires image, connected to the STLINKV2 pins so now include the colours in the table on comment #0
generally red is for +v and black for -ve (GND)
(In reply to Luke Kenneth Casson Leighton from comment #38) > so now include the colours in the table on comment #0 Will do. (In reply to Luke Kenneth Casson Leighton from comment #39) > generally red is for +v and black for -ve (GND) Should I make the two power cables both red then? Or one red one orange? And change the ground from white to black?
(In reply to Cole Poirier from comment #40) > Should I make the two power cables both red then? Or one red one orange? And > change the ground from white to black? why are there 2 power lines? there is only one to the IORef on the STLinkv2. remember what i said about asking qyestions to which the answer is already deducible? this needs a wiki page i can't keep track of images here. and the table too.
(In reply to Luke Kenneth Casson Leighton from comment #41) > > why are there 2 power lines? there is only one to the IORef on the STLinkv2. > > remember what i said about asking qyestions to which the answer is already > deducible? Because of the your response in comment #30: ``` > > ```proposed FPGA External Pin to STLINK JTAG pin connecitons > > pin # | label # | FPGA IO PAD | GPIO # (n/p) | JTAG Pin # (Signal) | > > 1 | 3.3v | NONE | 3v3 | 1 (MCU VDD) | > > 2 | 3.3v | NONE | 3v3 | 2 (MCU VDD) | > good, yes. the power *from* the ulx3s goes *into* the IO side of the STLinkv2 > so as to provide the Reference Voltage it needs relative to ulx3s's IO. ``` This led me to believe that both wires were needed.If only one wire is needed which one should be connected pin1 or pin2? Does it matter? > this needs a wiki page i can't keep track of images here. and the table too. Ok will do.
(In reply to Cole Poirier from comment #42) > (In reply to Luke Kenneth Casson Leighton from comment #41) > > > > why are there 2 power lines? there is only one to the IORef on the STLinkv2. > > > > remember what i said about asking qyestions to which the answer is already > > deducible? > > Because of the your response in comment #30: err... > ``` > > > ```proposed FPGA External Pin to STLINK JTAG pin connecitons > > > pin # | label # | FPGA IO PAD | GPIO # (n/p) | JTAG Pin # (Signal) | > > > 1 | 3.3v | NONE | 3v3 | 1 (MCU VDD) | > > > 2 | 3.3v | NONE | 3v3 | 2 (MCU VDD) | > > > good, yes. the power *from* the ulx3s goes *into* the IO side of the STLinkv2 > > so as to provide the Reference Voltage it needs relative to ulx3s's IO. > ``` > > This led me to believe that both wires were needed.If only one wire is > needed which one should be connected pin1 or pin2? Does it matter? *click* right. ok. so the answer to that can be deduced from the schematic, and from the net names. you'll see that both pin1 and pin2 of that connector, they're both connected to 3.3v, yes? so the voltage is going to be the same, therefore there's no need to connect 2 wires to that same voltage unless there are two separate locations to put it. given that the STLinkv2 only has the one input MCU-VDD, you can't put the 2nd wire anywhere, can you? the only reason you might want 2 wires is if the current carrying capacity of 1 is too low. and that's not the case here.
(In reply to Luke Kenneth Casson Leighton from comment #43) > > *click* right. ok. so the answer to that can be deduced from the > schematic, and from the net names. you'll see that both pin1 and pin2 of > that connector, they're both connected to 3.3v, yes? so the voltage is > going to be the same, therefore there's no need to connect 2 wires to that > same voltage unless there are two separate locations to put it. > > given that the STLinkv2 only has the one input MCU-VDD, you can't put the > 2nd wire anywhere, can you? Aha!! Yes now it's clicked for me, the pin labels for the stlinkv2 show that pin1 and pin2 are for the same MCU-VDD signal, not two separate ones. > the only reason you might want 2 wires is if the current carrying capacity > of 1 is too low. and that's not the case here. Ahhh, makes sense. Ok, so I'm going to keep pin2 instead of pin1 cause they're next to each other on the stlinkv2 rather than diagonal to each other. It's pretty arbitrary but I think this will be slightly easier in my mind. I'll create the wiki page now.
(In reply to Cole Poirier from comment #44) > > I'll create the wiki page now. Done https://libre-soc.org/HDL_workflow/fpga/
(In reply to Cole Poirier from comment #45) > (In reply to Cole Poirier from comment #44) > > > > I'll create the wiki page now. > > Done https://libre-soc.org/HDL_workflow/fpga/ excellent. remove the questions section. wikis do not have questions: their purpose is to provide information. questions are not information. the typical convention is to have a "discussion" page for questions however we have the bugtracker.
also remove the section which duplicates comment #1 which is yet another duplication of a mailing list post. why would we need 3 separate duplications in 3 separate places of the exact same discussion? reminder: wikis are an informational resource. instructions. howtos. tutorials. note-keeping. record-keeping. as discussion boards they're worse than useless: as bugtrackers the only one i've seen actually be successful is ikiwiki itself. keep each thing to what it does best and do not mix them.
cole check the wires into the STLinkV2 compared to where the "slot" is, you'll find you have the connector rotated 180 degrees https://libre-soc.org/HDL_workflow/ECP5_FPGA/
(In reply to Luke Kenneth Casson Leighton from comment #48) > cole check the wires into the STLinkV2 compared to where the "slot" is, > you'll find you have the connector rotated 180 degrees Fixed. Changed it from one image to two, one in the same orientation as the JTAG pinout documentation, and one the opposite orientation (the same orientation as the "ST" text on the STLINKV2) so that one can make sure the jumper connections are correct if trying to use the STLINKV2 in the easier to use orientation of the "ST" text being right-side-up with the micro usb port at the bottom of the device.
(In reply to Cole Poirier from comment #49) > (In reply to Luke Kenneth Casson Leighton from comment #48) > > cole check the wires into the STLinkV2 compared to where the "slot" is, > > you'll find you have the connector rotated 180 degrees > > Fixed. Changed it from one image to two, one in the same orientation as the > JTAG pinout documentation, and one the opposite orientation (the same > orientation as the "ST" text on the STLINKV2) so that one can make sure the > jumper connections are correct if trying to use the STLINKV2 in the easier > to use orientation of the "ST" text being right-side-up with the micro usb > port at the bottom of the device. utterly confusing. put explicitly "note the tab" and actually mark it using gimp with an arrow pointing to the tab. also action instructions in comment #47.
i'll add a similar arrow pointing on the fig10 tomorrow.
(In reply to Luke Kenneth Casson Leighton from comment #51) > i'll add a similar arrow pointing on the fig10 tomorrow. done here: https://libre-soc.org/HDL_workflow/2020-11-03_14-08.png if you can gimp-edit the images to match it will stop people getting confused about which way up the connector is
(In reply to Luke Kenneth Casson Leighton from comment #50) > > utterly confusing. put explicitly "note the tab" and actually mark it using > gimp with an arrow pointing to the tab. > > also action instructions in comment #47. Ok. So do that with the upside image that has the same orientation as the JTAG pinout and get rid of the right-side-up image? Working on the instructions in #47, didn't want to remove the instructions until I have finished adding the checklist that will replace it. (In reply to Luke Kenneth Casson Leighton from comment #52) > (In reply to Luke Kenneth Casson Leighton from comment #51) > > i'll add a similar arrow pointing on the fig10 tomorrow. > > done here: > https://libre-soc.org/HDL_workflow/2020-11-03_14-08.png > > if you can gimp-edit the images to match it will stop people getting > confused about which way up the connector is Ah I see. So keep both STLINKV2 images, or only the one matching the orientation of fig 10 but coloured?... actually that will require a new photo won't it as the tab is not visible in the current photo of the STLINKV2 with the same orientation as fig 10.
(In reply to Cole Poirier from comment #53) > (In reply to Luke Kenneth Casson Leighton from comment #50) > > > > utterly confusing. put explicitly "note the tab" and actually mark it using > > gimp with an arrow pointing to the tab. > > > > also action instructions in comment #47. > > Ok. So do that with the upside image that has the same orientation as the > JTAG pinout and get rid of the right-side-up image? i thought about that, after going "argh", and it's probably useful to have both. > Working on the instructions in #47, didn't want to remove the instructions > until I have finished adding the checklist that will replace it. there is a duplicated exact copy of those same instructions in comment #0. remove it, replace it with a "TODO reminder" and a link to comment #0. that way you will know to conveniently click on that link when it comes to adding the checklist, yes? > orientation of fig 10 but coloured?... actually that will require a new > photo won't it as the tab is not visible in the current photo of the > STLINKV2 with the same orientation as fig 10. a pink/purple arrow pointing to the same place people will get the message.
(In reply to Luke Kenneth Casson Leighton from comment #54) > > i thought about that, after going "argh", and it's probably useful to have > both. Ok. > there is a duplicated exact copy of those same instructions in comment #0. > remove it, replace it with a "TODO reminder" and a link to comment #0. that > way you will know to conveniently click on that link when it comes to adding > the checklist, yes? Yes. > a pink/purple arrow pointing to the same place people will get the message. Ok.
Hey Luke, tried reaching you on irc yesterday but haven't heard from you there, so I thought I should notify you here, via the bug tracker that I did what you've asked for and now await your review and feedback.
(In reply to Cole Poirier from comment #56) > Hey Luke, tried reaching you on irc yesterday but haven't heard from you > there, so I thought I should notify you here, via the bug tracker that I did > what you've asked for and now await your review and feedback. excellent, yes, sorry, been mostly away from the laptop for... about a week. suggest modifying the checklist to split into three (four): 1) connect male-to-female colour on STLINKv2 2) connect female-to-female on ulx3s 3) same for versa ecp5 4) starting with "ensure power is disconnected" wire up colours, then finally describe power-up sequence. and to remove the "don't" table, downgrade it to conversational statements and advice. we do not want "negative don't take action X statements" in a checklist table, ever.
ok the table's fine, there is however duplicate "zero wires" entries. remove this, replace with individual lines: * ensure power is disconnected from FPGA * ensure STLINKV2 USB is disconnected * ensure FPGA USB is disconnected
(In reply to Luke Kenneth Casson Leighton from comment #58) > ok the table's fine, there is however duplicate "zero wires" entries. > > remove this, replace with individual lines: > > * ensure power is disconnected from FPGA > * ensure STLINKV2 USB is disconnected > * ensure FPGA USB is disconnected Ok done. Do you think it's better to have the FPGA and the corresponding STLINKv2 connections in the same line of the same table or following from this: 1) connect male-to-female colour on STLINKv2 2) connect female-to-female on ulx3s Break it down even further into one table for each fpga wiring, and a shared table for wiring those colours to the STLINKv2?
(In reply to Cole Poirier from comment #59) > Break it down even further into one table for each fpga wiring, and a shared > table for wiring those colours to the STLINKv2? if you review the cabling for the VERSAECP5 you'll find that that is exactly what i have done. do you see a separate STLINKV2 cable picture for the VERSAECP5?
(In reply to Luke Kenneth Casson Leighton from comment #60) > (In reply to Cole Poirier from comment #59) > > > Break it down even further into one table for each fpga wiring, and a shared > > table for wiring those colours to the STLINKv2? > > if you review the cabling for the VERSAECP5 you'll find that that is exactly > what i have done. do you see a separate STLINKV2 cable picture for the > VERSAECP5? No actually I don't see it. I see a picture of the Versa ECP5 with colored circles and numbers, and I see the lattice table 12 with coloured squares representing the wires next to the pin numbers, as well as the "viewed from above PCB" diagram of the STLINKv2, and the corresponding table again with colours representing the wires next to the pin numbers. I don't see anything missing. I'm confused.
Ensure power is disconnected from FPGA Ensure STLINKV2 USB is disconnected Ensure FPGA USB is disconnected i mean, "put those into the checklist table"
Wire the RED jumper cable to (ULX3S pin #2) then wire it to (STLINKv2 pin #2), this will serve as the Voltage Reference signal (VREF) i mean, "select a red male-to-female jumper cable and wire it to ULXS." separate table "select a red male-tomale cable amd wire it to STLINKv2"
https://ftp.libre-soc.org/20201123_232927.jpg one set of cables connected to STLINKv2 one set of cables connected to VERSAECP5/ULX3S therefore *three separate tables* plus, later on, explicit instructions, "connect each coloured male jumper to each coloured female jumper" this way you do not lose the connections when you want to disconnect and store the two devices. the FPGA should have the female-female jumpers so that the wires do not randomly damage the bare PCB due to a short.
(In reply to Luke Kenneth Casson Leighton from comment #64) > https://ftp.libre-soc.org/20201123_232927.jpg > > one set of cables connected to STLINKv2 > > one set of cables connected to VERSAECP5/ULX3S > > therefore *three separate tables* plus, later on, explicit instructions, > "connect each coloured male jumper to each coloured female jumper" > > this way you do not lose the connections when you want to disconnect and > store the two devices. > > the FPGA should have the female-female jumpers so that the wires do not > randomly damage the bare PCB due to a short. Ok made the changes you asked for. Please take a look.
looks great. i would bullet these: Next we will wire up the STLINKv2 and our FPGA in three separate stages. * First a ... ... * Finally. also now i see it laid out, there is just too much wording in the tables. the done column is extraneous space at the front. the repetition "this is something something" is non-aligned. i would suggest: | action | colour | pin | function | done | then cut the extraneous verbose description, "Voltage ref is known as VREF". why is that important to know as an instruction? it's not: it's information - information that will distract someone who is trying to concentrate on doing exactly the right task. | connect F2F RED cable to pin # 5 | RED | 5 | TDO | | no need to say "put female plug on pin" because it won't fit as a male pin :) however if there is the slightest possibility of getting this wrong, leave it in. for the F2F cables however there is going to be no mistake. the M2F ones on the other hand... no, those go on the STLINKv2 and no possibility of a mistake there either. so in both cases the verbiage can go. this may even get the instruction down to about 5-6 words, down from... 30?
(In reply to Luke Kenneth Casson Leighton from comment #66) > the repetition "this is something something" is non-aligned. non-aligned as in: word wrap and word quantity make for overload and confusion.
(In reply to Luke Kenneth Casson Leighton from comment #66) > > i would suggest: > [snip] Luke I completed this... finally :) Time to review and start testing the stlinkv2 to fpga jtag interface?
ok much less words, unfortunately too few. mention of MALE-TO-FEMALE for STLINKV2 was removed. suggest replacing terse word "Attach" with "Attach M2F" or F2F as appropriate and define that in brackets directly above.
(In reply to Luke Kenneth Casson Leighton from comment #69) > ok much less words, unfortunately too few. mention of MALE-TO-FEMALE for > STLINKV2 was removed. > > suggest replacing terse word "Attach" with "Attach M2F" or F2F as > appropriate and define that in brackets directly above. I have made the requested changes. Please review and let me know of any final changes when you eventually have time :)
(In reply to Cole Poirier from comment #70) > > suggest replacing terse word "Attach" with "Attach M2F" or F2F as > > appropriate and define that in brackets directly above. > > I have made the requested changes. looks great.
https://github.com/arduino/OpenOCD/blob/master/tcl/interface/stlink-v2.cfg that's how to tell openocd to use an stlinkv2. trying to use this file: https://git.libre-soc.org/?p=libresoc-litex.git;a=blob;f=openocd.cfg;hb=HEAD clearly isn't going to work, because, obviously, right at the start, it says, "connect to jtagremote" not "connect to stlinkv2".
https://gitlab.com/Chips4Makers/Retro-uC/-/tree/master/boards/XLR8/demo
(In reply to Luke Kenneth Casson Leighton from comment #72) > https://github.com/arduino/OpenOCD/blob/master/tcl/interface/stlink-v2.cfg > > that's how to tell openocd to use an stlinkv2. trying to use this file: > https://git.libre-soc.org/?p=libresoc-litex.git;a=blob;f=openocd.cfg;hb=HEAD > > clearly isn't going to work, because, obviously, right at the start, it > says, "connect to jtagremote" not "connect to stlinkv2". It seems like the stlink-v2 only works with stm8 and stm32 microcontrollers. Apparently there is a way to setup jtag over gpio pins but I do not know what JTAG adapter supports this. Do you know of a jtag usb adapter that supports softcore targets? Can you comment as to what your progress on JTAG is? Is your jtag boundary scan work related to this? I've banged my head against this for weeks and I think I've finally figured out that there's a lot more involved here than setting up the pins (as we did on the wiki) plugging it all in and running the *buspirate (debug adapter) specific* demo from staf's retrouc gitlab repository. Any insight you can provide here would be most helpful.
(In reply to Cole Poirier from comment #74) > (In reply to Luke Kenneth Casson Leighton from comment #72) > > https://github.com/arduino/OpenOCD/blob/master/tcl/interface/stlink-v2.cfg > > > > that's how to tell openocd to use an stlinkv2. trying to use this file: > > https://git.libre-soc.org/?p=libresoc-litex.git;a=blob;f=openocd.cfg;hb=HEAD > > > > clearly isn't going to work, because, obviously, right at the start, it > > says, "connect to jtagremote" not "connect to stlinkv2". > > It seems like the stlink-v2 only works with stm8 and stm32 microcontrollers. that is the smaller device. > Apparently there is a way to setup jtag over gpio pins but I do not know > what JTAG adapter supports this. http://openocd.org/doc-release/README "transport select jtag" > Do you know of a jtag usb adapter that supports softcore targets? i don't > > Can you comment as to what your progress on JTAG is? on the irc logs. if you were on the irc channel you would have seen the discussion of the past week. > Is your jtag boundary scan work related to this? of course. we are getting the simulator into shape so that the hardware will respond in the same way. > I've banged my head against this for weeks why are you only just now telling us this? wr are months behind and you are only just noe asking for help? i don't understand > and I think I've finally figured > out that there's a lot more involved here than setting up the pins (as we > did on the wiki) plugging it all in and running the *buspirate (debug > adapter) specific* demo from staf's retrouc gitlab repository. Any insight > you can provide here would be most helpful. well the most immediate one is that by lraving it several weeks before asking for help it means that you've spent several weeks being ineffective. sorry if that insight shocks you, it is what it is. you do not have to do everything alone, without help, guidance or other people to provide insights, in order to "prove something". the larger stlinkv2 says "JTAG" on the box. therefore there is a way. we need to find it. somewhere online there *will* exist reports on how it is done. if there was a known working JTAG device around the stlonkv2 could be tested against it.
https://github.com/ntfreak/openocd/blob/master/tcl/interface/stlink.cfg this script is what is loaded with a -f option. the vid pid list is the USB id of the stlinkv2 that must be matched. a clone may have different: it should be obvious that to get a match you change the cfg file to include the USB ID. a quick search online "stlinkv2 openocd jtag" one of the first hits had the additional command "transport select jtag". then the JTAG commands need to be sent. this should not be difficult to put together. please respond in 24 hours to indicate what progress you have made. we have eight days. if you wait five weeks to respond there is no point.
http://openocd.org/doc/html/Debug-Adapter-Configuration.html#index-hla_005fstlink_005fbackend section 8.3.1
(In reply to Luke Kenneth Casson Leighton from comment #75) > (In reply to Cole Poirier from comment #74) > > > It seems like the stlink-v2 only works with stm8 and stm32 microcontrollers. > > that is the smaller device. True for the larger one we wrote the wiki docs for as well. > > Apparently there is a way to setup jtag over gpio pins but I do not know > > what JTAG adapter supports this. > > http://openocd.org/doc-release/README > > "transport select jtag" I wish it was that simple, it it not. By jtag adapter I mean the usb dongle like the stlink-v2, not the transport. > > Do you know of a jtag usb adapter that supports softcore targets? > > i don't Isn't that a problem as we are using a softcore and using gpio pins to do jtag instead of the stm module on the fpga? > > Can you comment as to what your progress on JTAG is? > > on the irc logs. if you were on the irc channel you would have seen the > discussion of the past week. irc should not be used as a substitute for the bug tracker. irc is only for short conversations, not critical development discussions. That is the explicit purpose of the bug tracker. > > Is your jtag boundary scan work related to this? > > of course. we are getting the simulator into shape so that the hardware > will respond in the same way. Good to know. > > I've banged my head against this for weeks > > why are you only just now telling us this? wr are months behind and you are > only just noe asking for help? i don't understand > > > > and I think I've finally figured > > out that there's a lot more involved here than setting up the pins (as we > > did on the wiki) plugging it all in and running the *buspirate (debug > > adapter) specific* demo from staf's retrouc gitlab repository. Any insight > > you can provide here would be most helpful. > > well the most immediate one is that by lraving it several weeks before > asking for help it means that you've spent several weeks being ineffective. > sorry if that insight shocks you, it is what it is. > > you do not have to do everything alone, without help, guidance or other > people to provide insights, in order to "prove something". Wasn't trying to prove anything, I was just stuck. > the larger stlinkv2 says "JTAG" on the box. therefore there is a way. we > need to find it. It can talk to the jtag modules of stm family chips, it apparently does not support talking to *arbitrary* chip targets. We need a jtag adapter that supports softcores, i.e. custom defined TAPs for targets running on fpgas. > somewhere online there *will* exist reports on how it is done. I've looked pretty hard with poor results. > if there was a known working JTAG device around the stlonkv2 could be tested > against it. I don't understand what you mean here. Can you please clarify?
(In reply to Luke Kenneth Casson Leighton from comment #76) > https://github.com/ntfreak/openocd/blob/master/tcl/interface/stlink.cfg > > this script is what is loaded with a -f option. > > the vid pid list is the USB id of the stlinkv2 that must be matched. > > a clone may have different: it should be obvious that to get a match you > change the cfg file to include the USB ID. > > a quick search online "stlinkv2 openocd jtag" one of the first hits had the > additional command "transport select jtag". > > then the JTAG commands need to be sent. > > this should not be difficult to put together. > > please respond in 24 hours to indicate what progress you have made. > > we have eight days. > > if you wait five weeks to respond there is no point. I've been over all of this, that's unfortunately not how it works. See the very comprehensive user guide here: http://openocd.org/doc/pdf/openocd.pdf
http://openocd.org/doc/html/OpenOCD-Project-Setup.html#OpenOCD-Project-Setup "5 OpenOCD Project Setup To use OpenOCD with your development projects, you need to do more than just connect the JTAG adapter hardware (dongle) to your development board and start the OpenOCD server. You also need to configure your OpenOCD server so that it knows about your adapter and board, and helps your work. You may also want to connect OpenOCD to GDB, possibly using Eclipse or some other GUI."
http://openocd.org/doc/html/OpenOCD-Project-Setup.html#OpenOCD-Project-Setup "5.4 User Config Files Best case: include just two files, and they handle everything else. The first is an interface config file. The second is board-specific, and it sets up the JTAG TAPs and their GDB targets (by deferring to some target.cfg file), declares all flash memory, and leaves you nothing to do except meet your deadline: source [find interface/olimex-jtag-tiny.cfg] source [find board/csb337.cfg] Boards with a single microcontroller often won’t need more than the target config file, as in the AT91SAM7X256 example. That’s because there is no external memory (flash, DDR RAM), and the board differences are encapsulated by application code. Maybe you don’t know yet what your board looks like to JTAG. Once you know the interface.cfg file to use, you may need help from OpenOCD to discover what’s on the board. Once you find the JTAG TAPs, you can just search for appropriate target and board configuration files ... or write your own, from the bottom up. See Autoprobing. You can often reuse some standard config files but need to write a few new ones, probably a board.cfg file. You will be using commands described later in this User’s Guide, and working with the guidelines in the next chapter. For example, there may be configuration files for your JTAG adapter and target chip, but you need a new board-specific config file giving access to your particular flash chips. Or you might need to write another target chip configuration file for a new chip built around the Cortex-M3 core. Note: When you write new configuration files, please submit them for inclusion in the next OpenOCD release. For example, a board/newboard.cfg file will help the next users of that board, and a target/newcpu.cfg will help support users of any board using that chip. You may need to write some C code. It may be as simple as supporting a new FT2232 or parport based adapter; a bit more involved, like a NAND or NOR flash controller driver; or a big piece of work like supporting a new chip architecture. Reuse the existing config files when you can. Look first in the scripts/boards area, then scripts/targets. You may find a board configuration that’s a good example to follow." It's far more complicated than simply selecting the interface i.e. 'stlink-v2', especially when the board and target aren't already supported by openocd. Apparently openocd is primarily an arm microcontroller debugger, and some riscv cores specifically target the altera toolchain and jtag debugger so that they can reuse the very extensive jtag debug toolchain that had to be written for that platform.
(In reply to Cole Poirier from comment #80) > http://openocd.org/doc/html/OpenOCD-Project-Setup.html#OpenOCD-Project-Setup > > "5 OpenOCD Project Setup > > To use OpenOCD with your development projects, you need to do more than just > connect the JTAG adapter hardware (dongle) to your development board and > start the OpenOCD server. You also need to configure your OpenOCD server so > that it knows about your adapter and board, and helps your work. You may > also want to connect OpenOCD to GDB, possibly using Eclipse or some other > GUI." we are not using gdb, we are not using an openocd server. we are *directly* connecting to the device and performing *direct*, raw JTAG commands. exactly as is done here: https://git.libre-soc.org/?p=libresoc-litex.git;a=blob;f=openocd.cfg;hb=HEAD using the command at line 6, here: https://git.libre-soc.org/?p=libresoc-litex.git;a=blob;f=README.txt;hb=HEAD it's far far simpler than you're making it out to be by reading random online documentation instead of *asking*. how many times have i reminded you so far, "if you do not know the answer *ask immediately*"? so. i'm going to plug in the STLinkV2 that i have here, and i'm going to time how long it takes me to get it recognised.
first step completed: stlinkv2 recognised. https://git.libre-soc.org/?p=libresoc-litex.git;a=commitdiff;h=65d71761c76d5894f5570402bce8d25a38610afa second step is to work out what the equivalent "jtag newtap" command is to send a tap IDCODE and set it up with the right IR length (4) however that's where "actual interaction" takes place to the ECP5 in order to get responses back, and confirm whether this is working. this command however confirms, through debug logs, that it is successfully interacting with the stlinkv2 and that it is doing so in JTAG mode: openocd -d -f openocd_stlinkv2.cfg
https://git.libre-soc.org/?p=libresoc-litex.git;a=commitdiff;h=b685c4cf938fc563eabf5f8d6c02b626907bedcf found the command which initialises jtag tap over hla: it's "hla newtap" rather than "jtag newtap" with the other file which set up openocd remote.
(In reply to Cole Poirier from comment #81) > It's far more complicated than simply selecting the interface i.e. no, it really is not. > 'stlink-v2', especially when the board and target aren't already supported > by openocd. you have jumped far too far ahead, by reading too much documentation that is not in the least bit relevant, instead of asking. you should have said, here on this bugreport, "today i am reading document X, looking for Y". i could have then guided you rather than you wasting hundreds of hours of precious time. > Maybe you don’t know yet what your board looks like to JTAG. Once you > know the interface.cfg file to use, you may need help from OpenOCD to > discover what’s on the board. Once you find the JTAG TAPs, you can just that is ALL that was needed. NOTHING ELSE. what we are doing is so basic and so low level (at the JTAG level ONLY) that everything else is COMPLETELY IRRELEVANT. the task is, was, shall be and remains to be to simply get the stlinkv2 to recognise the JTAG Interface by sending an IDCODE and executing .swf files once that is successful. that is what is in the README and that is all that is, was, and shall be required. if you had asked for clarification it would have been possible to reinforce that and clarify it *weeks* ago
(In reply to Cole Poirier from comment #78) > > > Do you know of a jtag usb adapter that supports softcore targets? > > > > i don't > > Isn't that a problem as we are using a softcore and using gpio pins to do > jtag instead of the stm module on the fpga? you have confused multiple things. * openocd talks to stlinkv2. * stlinkv2 is instructed to enter JTAG MODE at that point it doesn't matter what the hell gets connected, it's just JTAG. * four wires speaking JTAG connect to FPGA * those pins are connected to HDL * that HDL understands JTAG the "softcore" isn't even directly associated with JTAG, they are completely separate subsystems. the "softcore" does not know anything at all about JTAG. the JTAG *protocol* is implemented in HDL by Staf's C4M-JTAG nmigen module. that is its job. what you are referring to, "is there a jtag usb that supports softcore targets" completely confuses about four unrelated things, including assuming that the HIGH LEVEL scripts in openocd are relevant and mandatory. we are doing LOW LEVEL and the rest of openocd is completely and utterly irrelevant at this early phase. the only reason we are using openocd is because it contains a tiny relevant fraction of code necessary to recognise the stlinkv2 and get it into JTAG mode. THAT IS IT. once this utterly simple task which took me 20 minutes to research and implement is completed and confirmed, THEN AND ONLY THEN DO WE MOVE TO DEFINING A PROCESSOR TARGET. > > > Can you comment as to what your progress on JTAG is? > > > > on the irc logs. if you were on the irc channel you would have seen the > > discussion of the past week. > > irc should not be used as a substitute for the bug tracker. irc is only for > short conversations, not critical development discussions. That is the > explicit purpose of the bug tracker. the solution there is to look up the irclog link and enter it into the bugtracker.
(In reply to Luke Kenneth Casson Leighton from comment #86) > (In reply to Cole Poirier from comment #78) > > > > > Do you know of a jtag usb adapter that supports softcore targets? > > > > > > i don't > > > > Isn't that a problem as we are using a softcore and using gpio pins to do > > jtag instead of the stm module on the fpga? > > you have confused multiple things. > > * openocd talks to stlinkv2. > * stlinkv2 is instructed to enter JTAG MODE > > at that point it doesn't matter what the hell gets connected, it's just JTAG. > > * four wires speaking JTAG connect to FPGA > * those pins are connected to HDL > * that HDL understands JTAG > > the "softcore" isn't even directly associated with JTAG, they are completely > separate subsystems. the "softcore" does not know anything at all about > JTAG. > > the JTAG *protocol* is implemented in HDL by Staf's C4M-JTAG nmigen module. > > that is its job. > > what you are referring to, "is there a jtag usb that supports softcore > targets" completely confuses about four unrelated things, including assuming > that the HIGH LEVEL scripts in openocd are relevant and mandatory. > > we are doing LOW LEVEL and the rest of openocd is completely and utterly > irrelevant at this early phase. > > the only reason we are using openocd is because it contains a tiny relevant > fraction of code necessary to recognise the stlinkv2 and get it into JTAG > mode. > > THAT IS IT. Ok, understood. Thanks for your help with openocd and in clearing up my confusion. How do I go about defining a target now that the stlink<->openocd communication is properly set up.
arrrgggh okaaay a *lot* of investigating and messing about: there is a new STLINKv2 transport called stlink_usb.c which is selected by "select transport dapdirect_jtag" i'm adding a new .cfg file, it's passed "voltage" check (finding 3.2) however fails with an unknown error 0x5 on calling stlink_usb_mode_enter https://github.com/ntfreak/openocd/blob/master/src/jtag/drivers/stlink_usb.c#L1664 this is going to require... patience.
(In reply to Luke Kenneth Casson Leighton from comment #88) > arrrgggh okaaay a *lot* of investigating and messing about: there is a new > STLINKv2 transport called stlink_usb.c which is selected by > "select transport dapdirect_jtag" > > i'm adding a new .cfg file, it's passed "voltage" check (finding 3.2) however > fails with an unknown error 0x5 on calling stlink_usb_mode_enter > > > https://github.com/ntfreak/openocd/blob/master/src/jtag/drivers/stlink_usb. > c#L1664 > > this is going to require... patience. Understood. What should I do?
(In reply to Cole Poirier from comment #89) > Understood. What should I do? see if you can get any further or get a different debug error other than 0x4 or 0x5. don't ask me what those undocumented error codes mean.
rrright. i hacked openocd into submission, on the hla transport. anything that assumed a target existed - OUT. anything that caused failures due to assumptions that a target existed - OUT. as a direct result of this i was able to get to the same status as the dapdirect_jtag .cfg file, i.e. reproduce this exact same error: Debug: 83 5 stlink_usb.c:1019 stlink_usb_error_check(): unknown/unexpected STLINK status code 0x5 at which point, the next error line reported was: Error: 84 5 stlink_usb.c:3493 stlink_open(): init mode failed (unable to connect to the target) which tells us that it *might* actually be the case that communication is in fact being attempted with the ECP5 over the JTAG lines. whether that's working or not is a different matter. the speed options here are pretty damn high - 140 khz is the bare minimum and i suspect that's simply too noisy / fast i have ordered a Waveshare USB Blaster and will see if that does any better. the other option is an FT232 of some description and define some arbitrary pin-mappings to bit-bang as JTAG.
Created attachment 128 [details] gets hla_jtag working in bare minimum config (no forced target) openocd force-requires a target to exist on the hla_jtag transport. this is completely unnecessary, especially for a "jtag newtap type=tap" declaration.
(In reply to Luke Kenneth Casson Leighton from comment #92) > Created attachment 128 [details] > gets hla_jtag working in bare minimum config (no forced target) > > openocd force-requires a target to exist on the hla_jtag transport. > this is completely unnecessary, especially for a "jtag newtap type=tap" > declaration. Great. What openocd git revision are you working from?
master ./configure --disable-werror --enable-remote-bitbang
http://openocd.org/doc/html/Debug-Adapter-Configuration.html#index-ftdi
(In reply to Luke Kenneth Casson Leighton from comment #95) > http://openocd.org/doc/html/Debug-Adapter-Configuration.html#index-ftdi ``` from above link List of connections (default physical pin numbers for FT232R in 28-pin SSOP package): - RXD(5) - TDI - TXD(1) - TCK - RTS(3) - TDO - CTS(11) - TMS - DTR(2) - TRST - DCD(10) - SRST ``` ``` from https://github.com/ntfreak/openocd/blob/master/src/jtag/drivers/ft232r.c#L79-L99 /** * FT232R GPIO bit number to RS232 name */ #define FT232R_BIT_COUNT 8 static char *ft232r_bit_name_array[FT232R_BIT_COUNT] = { "TXD", /* 0: pin 1 TCK output */ "RXD", /* 1: pin 5 TDI output */ "RTS", /* 2: pin 3 TDO input */ "CTS", /* 3: pin 11 TMS output */ "DTR", /* 4: pin 2 /TRST output */ "DSR", /* 5: pin 9 unused */ "DCD", /* 6: pin 10 /SYSRST output */ "RI" /* 7: pin 6 unused */ }; static int tck_gpio; /* initialized to 0 by default */ static int tdi_gpio = 1; static int tdo_gpio = 2; static int tms_gpio = 3; static int ntrst_gpio = 4; static int nsysrst_gpio = 6; ``` ```from ft232 usb to 6 pin female header manual _________________________ | Pin # | Name | Colour | |-------|------|----------| | 1 | GND | Black | | 2 | CTS | Brown | | 3 | VCC | Red | | 4 | TXD | Orange | | 5 | RXD | Yellow | | 6 | RTS | Green | |_______|______|__________| ``` ``` ft232 pin and wire colour table converted to jtag signal names _________________________ | Pin # | Name | Colour | |-------|------|----------| | 1 | GND | Black | | 2 | TMS | Brown | | 3 | VCC | Red | | 4 | TCK | Orange | | 5 | TDI | Yellow | | 6 | TDO | Green | |_______|______|__________| ``` Luke, my proposal is to change the wire colours of on the wiki specified for the fpga to the colours present on the ft232 6 pin female header. Is it a problem that the f232r.c openocd file specifies trst and srst but not gnd and vcc? Or are gnd and vcc not specified in the openocd interface 'c' file because they are electrical and managed by power hardware on the ft232 chip? Any other concerns about this migration? Or once I put this on the ECP5_FPGA wiki page under a header titled 'jtag over ft232' will we be good to proceed with connecting the wires to the fpga and trying to get the jtag tap of libre-soc recognized? - after the wiring is triple checked of course.
(In reply to Cole Poirier from comment #96) > Luke, my proposal is to change the wire colours of on the wiki specified for > the fpga to the colours present on the ft232 6 pin female header. great. > Is it a problem that the f232r.c openocd file specifies trst and srst but > not gnd and vcc? Or are gnd and vcc not specified in the openocd interface > 'c' file because they are electrical and managed by power hardware on the > ft232 chip? you answered your own question. > Any other concerns about this migration? Or once I put this on the ECP5_FPGA > wiki page under a header titled 'jtag over ft232' will we be good to proceed > with connecting the wires to the fpga and trying to get the jtag tap of > libre-soc recognized? that would be the obvious thing to do, wouldn't it?
(In reply to Luke Kenneth Casson Leighton from comment #97) > > you answered your own question. > > [snip] > > that would be the obvious thing to do, wouldn't it? Looks like I've sort of figured out what I'm doing eh? ;) Should I leave the voltage and ground pins of the ft232r interface unconnected to prevent voltage fighting with the fpga power connector?
(In reply to Cole Poirier from comment #98) > (In reply to Luke Kenneth Casson Leighton from comment #97) > > > > you answered your own question. > > > > [snip] > > > > that would be the obvious thing to do, wouldn't it? > > Looks like I've sort of figured out what I'm doing eh? ;) > > Should I leave the voltage and ground pins of the ft232r interface > unconnected to prevent voltage fighting with the fpga power connector? Hi luke can you please review the changes I've made to the wiki and confirm that I have done it 100% correctly? I also left questions on the wiki page for you about somethings like the potential for voltage fighting. Also I didn't want to remove the images you uploaded with the colours of the wires for the ECP5 because I can't recreate them/correct them. Do you think we should remove these images until after you can correct them?
(In reply to Cole Poirier from comment #98) > Should I leave the voltage and ground pins of the ft232r interface > unconnected to prevent voltage fighting with the fpga power connector? hmmmm.... on the FT232 that i have here, there is a voltage selector jumper (5.5v -> VREF <- 3.3v). strictly speaking the FPGA VREF should be connected to that middle pin in order to provide VREF.
https://www.sparkfun.com/datasheets/IC/FT232R_v104.pdf page 8 - Table 1 pin 4 - VCCIO - should be supplied *by the FPGA*.
https://images-na.ssl-images-amazon.com/images/I/61wWDd92ZnL._AC_SL1001_.jpg right. this is the one i got. see at the top, there's a jumper with 3.3v VCC 5V and right at the bottom there's: VCC GND TXD RXD RTS CTS that means that the VCC pin is connected directly to VCCIO (pin 4) therefore this is very simple: remove the jumper entirely.
(In reply to Luke Kenneth Casson Leighton from comment #102) > https://images-na.ssl-images-amazon.com/images/I/61wWDd92ZnL._AC_SL1001_.jpg > > right. this is the one i got. see at the top, there's a jumper with > > 3.3v > VCC > 5V > > and right at the bottom there's: > > VCC > GND > TXD > RXD > RTS > CTS > > that means that the VCC pin is connected directly to VCCIO (pin 4) > > therefore this is very simple: remove the jumper entirely. Ok so no VCC but yes GND?
(In reply to Cole Poirier from comment #103) > Ok so no VCC but yes GND? yes. you nearly always need gnd for a return path for the current. if you don't have a return path right near the signal lines, it will totally mess up high speed signals, due to the extra inductance caused by the loop through the signal and off to a ground somewhere.
(In reply to Jacob Lifshay from comment #104) > (In reply to Cole Poirier from comment #103) > > Ok so no VCC but yes GND? > > yes. you nearly always need gnd for a return path for the current. if you > don't have a return path right near the signal lines, it will totally mess > up high speed signals, due to the extra inductance caused by the loop > through the signal and off to a ground somewhere. Right fixed this and updated the wiki page, luke can you please review it again with the new updates?
(In reply to Jacob Lifshay from comment #104) > (In reply to Cole Poirier from comment #103) > > Ok so no VCC but yes GND? > > yes. you nearly always need gnd for a return path for the current. if you > don't have a return path right near the signal lines, it will totally mess > up high speed signals, due to the extra inductance caused by the loop > through the signal and off to a ground somewhere. Thanks for your help Jacob!
"According to Jacob: ..." "discussion" is not appropriate to have on a page containing critical and absolute clear informational and instructional pages. "what someone said" is not in any way appropriate to put on a page of this type. this bigreport is fine. a discussion page is fine. not this page.
(In reply to Cole Poirier from comment #103) > Ok so no VCC how the hell did you manage to conclude that? do you not remember what i spent some considerable time explaining about IO voltages being supplied by the FPGA? it was about an hour long conversation.
(In reply to Luke Kenneth Casson Leighton from comment #108) > (In reply to Cole Poirier from comment #103) > > > Ok so no VCC > > how the hell did you manage to conclude that? > > do you not remember what i spent some considerable time explaining about IO > voltages being supplied by the FPGA? it was about an hour long conversation. (Luke Kenneth Casson Leighton 2021-04-09 22:21:54 BST from comment #102) > therefore this is very simple: remove the jumper entirely. From this^
(In reply to Luke Kenneth Casson Leighton from comment #107) > "According to Jacob: ..." > > "discussion" is not appropriate to have on a page containing critical and > absolute clear informational and instructional pages. > > "what someone said" is not in any way appropriate to put on a page of this > type. this bigreport is fine. a discussion page is fine. not this page. What would you like me to do with it? remove it entirely? or remove the attribution to Jacob?
(In reply to Cole Poirier from comment #110) > What would you like me to do with it? remove it entirely? or remove the > attribution to Jacob? cole, you are asking obvious questions when you should be able to deduce the answers for yourself. if you remove the attribution, it's still violating the page's purpose, isn't it? i am answering in such a way as to train you to make these kinds of deductions for yourself (rather than just "ordering you what to do like a trained monkey") i said, "this page is to be clear instructions". therefore it should be blindingly obvious that waffly random "some person said maybe x" conversations are completely inappropriate to have on the page. therefore, it is equally blindingly obvious that the entire paragraph should be deleted from the page, yes? why am i having to spell these things out?
(In reply to Cole Poirier from comment #109) > From this^ in answering thus, i assumed that you had in your mind the information that i had already given you, a couple of months ago, in an hour-long conversation. can you please write out what i explained to you about why VREF exists (and if you cannot remember, do some research to look it up). whilst it is much quicker for me to simply tell you the answer [like a trained keyboard-typing monkey], i would prefer that you learned to work things out by multi-chained logical deductive reasoning.
(In reply to Luke Kenneth Casson Leighton from comment #112) > (In reply to Cole Poirier from comment #109) > > > From this^ > > in answering thus, i assumed that you had in your mind the information that > i had already given you, a couple of months ago, in an hour-long > conversation. > > can you please write out what i explained to you about why VREF exists > (and if you cannot remember, do some research to look it up). > > whilst it is much quicker for me to simply tell you the answer [like a > trained keyboard-typing monkey], i would prefer that you learned to work > things out by multi-chained logical deductive reasoning. I would contend that my learning should take a back seat to actually getting a working test setup before the tape-out deadline. We can return to teaching me after we meet our *critical* deadline. VREF is an accurate, constant, low-noise output voltage, that is used as the reference for other electrical signals on a device.
(In reply to Cole Poirier from comment #113) > I would contend that my learning should take a back seat to actually getting > a working test setup before the tape-out deadline. We can return to teaching > me after we meet our *critical* deadline. that would appear to be a logical thing to conclude. however if you are not thinking for yourself, and i tell you the wrong thing, the object of the exercise - to double-check each other's work - is completely defeated, isn't it? > VREF is an accurate, constant, low-noise output voltage, that is used as the > reference for other electrical signals on a device. excellent. so if that VREF is disconnected as you ask in comment #98, the FT232 is in no way going to know what that reference is, is it? and if GND is also disconnected, how would there ever be a circuit *at all*? if you put one wire into a plug, or only connect one terminal to a battery, it doesn't work, does it?
(In reply to Luke Kenneth Casson Leighton from comment #114) > > that would appear to be a logical thing to conclude. however if you are not > thinking for yourself, and i tell you the wrong thing, the object of the > exercise - to double-check each other's work - is completely defeated, isn't > it? I see, this only works however if I actually have a proper understanding of electrical engineering, something not possible to do with out imminent deadline. > excellent. so if that VREF is disconnected as you ask in comment #98, the > FT232 is in no way going to know what that reference is, is it? > > and if GND is also disconnected, how would there ever be a circuit *at all*? > if you put one wire into a plug, or only connect one terminal to a battery, > it doesn't work, does it? GND is still connected. You said vref is supplied by the fpga not the ft232r thus, you said to remove the vref jumper cable, and I did as you directed. I'm confused. Can you please just give me the answer that you already know so we can proceed to the much more important and time critical task of testing ls180 over jtag on the fpga? We can return to teaching me after the tapeout. How many wires will be going from the ft232r cable to the fpga, what are they labelled, and what colour are they?
(In reply to Cole Poirier from comment #115) > I see, this only works however if I actually have a proper understanding of > electrical engineering, something not possible to do with out imminent > deadline. slapped wrist! we are all operating at the limit of our knowledge! have confidence that what you do not know can be determined and learned. > GND is still connected. good. > You said vref is supplied by the fpga not the ft232r yes. > thus, you said to remove the vref jumper cable, and I did as you directed. good. this disconnects the power supplied *by* the FT232 onto the VCC pin, doesn't it? look at the PCB, it says 5V on one side, VCC in the middle, and 3.3V on the other. removing the jumper disconnects *both* of those from VCC, doesn't it? if there is no jumper connecting either of those voltages to VCC, then the power supplied to VREF will not fight with the power supplied by the FPGA, will it? just as i explained very clearly to you on an hour long conversation eight weeks ago, and your voice clearly indicated to me that you understood everything that i explained. > I'm confused. yes, we know :) this is why the page contains confusing statements. > How many wires will be going from the ft232r cable to the fpga, what are > they labelled, and what colour are they? this is your task to complete. i am focussing on the simulation.
(In reply to Luke Kenneth Casson Leighton from comment #116) > (In reply to Cole Poirier from comment #115) > > > I see, this only works however if I actually have a proper understanding of > > electrical engineering, something not possible to do with out imminent > > deadline. > > slapped wrist! we are all operating at the limit of our knowledge! have > confidence that what you do not know can be determined and learned. Fumbling around in the dark is difficult *shrugs* :) > > thus, you said to remove the vref jumper cable, and I did as you directed. > > good. this disconnects the power supplied *by* the FT232 onto the VCC pin, > doesn't it? > > look at the PCB, it says 5V on one side, VCC in the middle, and 3.3V on the > other. removing the jumper disconnects *both* of those from VCC, doesn't it? > > if there is no jumper connecting either of those voltages to VCC, then the > power supplied to VREF will not fight with the power supplied by the FPGA, > will it? > > just as i explained very clearly to you on an hour long conversation eight > weeks ago, and your voice clearly indicated to me that you understood > everything that i explained. Right, so given that the current state of the wiki is correct? (I believe it is, but was confused (as you know) and now would like your confirmation). > > I'm confused. > > yes, we know :) this is why the page contains confusing statements. With the statement I included from jacob last night now removed, what are the remaining confusing statements? I believe there are none, but would like your input/confirmation. > > How many wires will be going from the ft232r cable to the fpga, what are > > they labelled, and what colour are they? > > this is your task to complete. i am focussing on the simulation. I think I have completed this correctly, I require your double-checking of my belief.
(In reply to Cole Poirier from comment #117) > Right, so given that the current state of the wiki is correct? why have you removed all mention of VREF? did you not understand your own words in comment #113? "VREF is an accurate, constant, low-noise output voltage, that is used as the reference for other electrical signals on a device." in comment #29 the table is correct. we established this back in october. you have had it explained to you multiple times that VREF is necessary. why when you have had it explained to you multiple times, and you actually looked it up for yourself only yesterday and got an explanation of what VREF is, all of which reinforce that VREF is necessary, would you then *remove* VREF from every single table?
(In reply to Luke Kenneth Casson Leighton from comment #118) > (In reply to Cole Poirier from comment #117) > > > Right, so given that the current state of the wiki is correct? > > why have you removed all mention of VREF? did you not understand > your own words in comment #113? > > "VREF is an accurate, constant, low-noise output voltage, that is used as > the reference for other electrical signals on a device." > > in comment #29 the table is correct. we established this back in october. > you have had it explained to you multiple times that VREF is necessary. > > why when you have had it explained to you multiple times, and you actually > looked it up for yourself only yesterday and got an explanation of what VREF > is, all of which reinforce that VREF is necessary, would you then *remove* > VREF from every single table? Because you said to remove the VREF jumper cable, because VREF is supplied by the FPGA, therefore there is not a pin connected for VREF, because it is supplied by the FPGA? I'm confused still.
(In reply to Cole Poirier from comment #119) > Because you said to remove the VREF jumper cable no, i did not. read comment #102 agsin. jumper != the wire. jumper == a 5 x 8mm black connector between two pins. read comment #102 again. look at the photo. where does it say the word CABLE? you are not paying attention and are adding random words. this is the source of the confusion. > because VREF is supplied > by the FPGA, therefore there is not a pin connected for VREF, because it is > supplied by the FPGA? if the cable is removed there is not a way for the power from the FPGA to get to VREF on the FT232, is there? power cannot magically travel through the air, can it?
(In reply to Luke Kenneth Casson Leighton from comment #120) > (In reply to Cole Poirier from comment #119) > > > Because you said to remove the VREF jumper cable > > no, i did not. read comment #102 agsin. > > jumper != the wire. jumper == a 5 x 8mm black connector between two pins. > > read comment #102 again. look at the photo. where does it say the word > CABLE? > > you are not paying attention and are adding random words. > > this is the source of the confusion. > > > > because VREF is supplied > > by the FPGA, therefore there is not a pin connected for VREF, because it is > > supplied by the FPGA? > > if the cable is removed there is not a way for the power from the FPGA to > get to VREF on the FT232, is there? > > power cannot magically travel through the air, can it? Ah confusion resolved. I figured out the last known good state of the page's markdown and the two relevant images and have restored them. Can you please review the wiki page now?
## Images of wires on FPGA and on ft232r which FPGA?
does not contain the names of the signals on the FT232 PCB. different FT232 PCBs will have different orders. this will result in confusion and destruction of hardware. ft232 pin and wire colour table converted to jtag signal names: _________________________ | Pin # | Name | Colour | |-------|------|----------| | 1 | GND | Black | | 2 | TMS | Brown | | 3 | VCC | Red | | 4 | TCK | Orange | | 5 | TDI | Yellow | | 6 | TDO | Green | |_______|______|__________|
(In reply to Luke Kenneth Casson Leighton from comment #122) > ## Images of wires on FPGA and on ft232r > > which FPGA? Fixed and added a note that there will be new images for the versa ecp5, once you are able to do them.
(In reply to Luke Kenneth Casson Leighton from comment #123) > does not contain the names of the signals on the FT232 PCB. different FT232 > PCBs will have different orders. this will result in confusion and > destruction of hardware. > > > ft232 pin and wire colour table converted to jtag signal names: > > _________________________ > | Pin # | Name | Colour | > |-------|------|----------| > | 1 | GND | Black | > | 2 | TMS | Brown | > | 3 | VCC | Red | > | 4 | TCK | Orange | > | 5 | TDI | Yellow | > | 6 | TDO | Green | > |_______|______|__________| Fixed by adding the full context from https://bugs.libre-soc.org/show_bug.cgi?id=517#c96. Please review.
_________________________ | Pin # | Name | Colour | |-------|------|----------| | 1 | GND | Black | | 2 | CTS | Brown | | 3 | VCC | Red | | 4 | TXD | Orange | | 5 | RXD | Yellow | | 6 | RTS | Green | |_______|______|__________| ft232 pin and wire colour table converted to jtag signal names: _________________________ | Pin # | Name | Colour | |-------|------|----------| | 1 | GND | Black | | 2 | TMS | Brown | | 3 | VCC | Red | | 4 | TCK | Orange | | 5 | TDI | Yellow | | 6 | TDO | Green | |_______|______|__________| how are people supposed to read these and understand that they are related? eyes flick ftom one table to the other and miss a row. also you missed the point that the numbering is completely different. look at the DCD FT232 photo. does the numbering match? this is how mistakes are made.
also: why have you removed the VERSA ECP5 images and tables? what is the purpose of removing perfectly good information that does not need modification?
(In reply to Luke Kenneth Casson Leighton from comment #127) > also: why have you removed the VERSA ECP5 images and tables? > what is the purpose of removing perfectly good information > that does not need modification? Because it is not good information, you need to update it to conform to the ft232 wiring colours.
(In reply to Luke Kenneth Casson Leighton from comment #126) > _________________________ > | Pin # | Name | Colour | > |-------|------|----------| > | 1 | GND | Black | > | 2 | CTS | Brown | > | 3 | VCC | Red | > | 4 | TXD | Orange | > | 5 | RXD | Yellow | > | 6 | RTS | Green | > |_______|______|__________| > ft232 pin and wire colour table converted to jtag signal names: > > _________________________ > | Pin # | Name | Colour | > |-------|------|----------| > | 1 | GND | Black | > | 2 | TMS | Brown | > | 3 | VCC | Red | > | 4 | TCK | Orange | > | 5 | TDI | Yellow | > | 6 | TDO | Green | > |_______|______|__________| > > > how are people supposed to read these and understand that they are related? > > eyes flick ftom one table to the other and miss a row. > > also you missed the point that the numbering is completely different. > > look at the DCD FT232 photo. does the numbering match? > > > this is how mistakes are made. It’s all there. If you do not like how it has been done please help and modify it to suit your needs. Given that we have mere days until the deadline why don’t you contribute to this instead of unhelpfully pointing out things you would do differently and saying they are wrong but doing nothing to rectify this and actually helping.
(In reply to Cole Poirier from comment #129) > > look at the DCD FT232 photo. does the numbering match? > > > > > > this is how mistakes are made. > > It’s all there. If you do not like how it has been done please help and > modify it to suit your needs. i am focussing mentally on bug #620. i reveiewed what you did, and concluded: 1) you missed the point that all FT232 PCBs are different 2) you missed the point that clarity is critical 3) if you are the one that makes the changes it trains you through "lrarning by doing" if i do the task, you do not learn. and, more thsn that, it stops me from completing other critical tasks. > Given that we have mere days until the > deadline why don’t you contribute to this instead of unhelpfully pointing > out things you would do differently and saying they are wrong but doing > nothing to rectify this and actually helping. if i stop what i am doing and complete the task that you are responsible for how does that help you or the project? (In reply to Cole Poirier from comment #128) > (In reply to Luke Kenneth Casson Leighton from comment #127) > > also: why have you removed the VERSA ECP5 images and tables? > > what is the purpose of removing perfectly good information > > that does not need modification? > > Because it is not good information, you need to update it to conform to the > ft232 wiring colours. the colours are according to the functions, and have not changed. i already checked. you did not change the colours on the ulx3s therefore because they represent the exact same functions on the ulx3s they represent the exact same functions on the VERSAECP5. if they were different i would have said something. also if you had changed them, i would have instructed you to restore them because the change is not only unnecessary it also causes far more work (including causing me to have to re-edit the image tables) please put the diagrams back exactly as they were. you are doing a lot of fighting, struggling, and stressing here, all of which is quite unnecessary, and is causing you to stop thinking rationally about this quite straightforward task.
(In reply to Luke Kenneth Casson Leighton from comment #130) > (In reply to Cole Poirier from comment #129) > > > > > look at the DCD FT232 photo. does the numbering match? > > > > > > > > > this is how mistakes are made. > > > > It’s all there. If you do not like how it has been done please help and > > modify it to suit your needs. > > i am focussing mentally on bug #620. i reveiewed what you did, and > concluded: > > 1) you missed the point that all FT232 PCBs are different How about we focus on supporting the ft232 I have here to actually work with instead of every one of the variants. > 2) you missed the point that clarity is critical > 3) if you are the one that makes the changes it trains you through "lrarning > by doing" So you’re saying to me that my learning is more important than us meeting the tapeout deadline? Because by making me ‘learn’ you have wasted days of time that could have been spent testing the ls180 over jtag on the FPGA. > > if i do the task, you do not learn. and, more thsn that, it stops me from > completing other critical tasks. Critical waste of time see above. > > Given that we have mere days until the > > deadline why don’t you contribute to this instead of unhelpfully pointing > > out things you would do differently and saying they are wrong but doing > > nothing to rectify this and actually helping. > > if i stop what i am doing and complete the task that you are responsible for > how does that help you or the project? A week to make me ‘learn’, is ridiculously inappropriate given the circumstances. You could do this in half an hour and we could make our tapeout deadline. For some reason the tapeout deadline seems utterly irrelevant to you here? > (In reply to Cole Poirier from comment #128) > > (In reply to Luke Kenneth Casson Leighton from comment #127) > > > also: why have you removed the VERSA ECP5 images and tables? > > > what is the purpose of removing perfectly good information > > > that does not need modification? > > > > Because it is not good information, you need to update it to conform to the > > ft232 wiring colours. > > the colours are according to the functions, and have not changed. i already > checked. You checked but are in fact incorrect, the colours have changed. I triple checked the wiki. They have changed. > you did not change the colours on the ulx3s therefore because they represent > the exact same functions on the ulx3s they represent the exact same > functions on the VERSAECP5. They have changed. Check again. > if they were different i would have said something. > > also if you had changed them, i would have instructed you to restore them > because the change is not only unnecessary it also causes far more work > (including causing me to have to re-edit the image tables) The. You would have been incorrect. > please put the diagrams back exactly as they were. That will result in incorrect information on the wiki page. > you are doing a lot of fighting, struggling, and stressing here, all of > which is quite unnecessary, and is causing you to stop thinking rationally > about this quite straightforward task. It would be more straightforward if you would just do it instead of wasting literally 4 days of the week we had to make the tapeout deadline. This is a wildly inappropriate trade off in terms of what this has cost the project.
(In reply to Cole Poirier from comment #131) > (In reply to Luke Kenneth Casson Leighton from comment #130) > > (In reply to Cole Poirier from comment #129) > > > > > > > > look at the DCD FT232 photo. does the numbering match? > > > > > > > > > > > > this is how mistakes are made. > > > > > > It’s all there. If you do not like how it has been done please help and > > > modify it to suit your needs. > > > > i am focussing mentally on bug #620. i reveiewed what you did, and > > concluded: > > > > 1) you missed the point that all FT232 PCBs are different > > How about we focus on supporting the ft232 I have here to actually work with > instead of every one of the variants. > > > 2) you missed the point that clarity is critical > > 3) if you are the one that makes the changes it trains you through "lrarning > > by doing" > > So you’re saying to me that my learning is more important than us meeting > the tapeout deadline? Because by making me ‘learn’ you have wasted days of > time that could have been spent testing the ls180 over jtag on the FPGA. > > > > > > if i do the task, you do not learn. and, more thsn that, it stops me from > > completing other critical tasks. > > Critical waste of time see above. > > > > > Given that we have mere days until the > > > deadline why don’t you contribute to this instead of unhelpfully pointing > > > out things you would do differently and saying they are wrong but doing > > > nothing to rectify this and actually helping. > > > > if i stop what i am doing and complete the task that you are responsible for > > how does that help you or the project? > > A week to make me ‘learn’, is ridiculously inappropriate given the > circumstances. You could do this in half an hour i could indeed spend that time, in addition to the critical tasks that i am currently doing of keeping both Jean-Paul and Staf occupied. if i took away the responsibility for the task, how would that make you feel? i am already doing massive amounts here. do you wish to add to that list? > You checked but are in fact incorrect, the colours have changed. I triple > checked the wiki. They have changed. why did you change them? why did you not indicate an intent to change them? because you did not inform me of an intent to change the colours, you are directly responsible for increasing the amount of work needed. please put them back to how they were. please restore the VERSA_ECP5 images on the page. changing the colours massively increases the tasks that have to be done. > > please put the diagrams back exactly as they were. > > That will result in incorrect information on the wiki page. then that is your responsibility to correct it. > It would be more straightforward if you would just do it instead of wasting > literally 4 days of the week we had to make the tapeout deadline. This is a > wildly inappropriate trade off in terms of what this has cost the project. i simply do not have the time. i am ensuring that both Jean-Paul and Staf are supported and are never delayed by being without critical information. please stop fighting and dodging responsibility for the task: dodging that responsibility is what is taking up the time.
(In reply to Cole Poirier from comment #128) > (In reply to Luke Kenneth Casson Leighton from comment #127) > > also: why have you removed the VERSA ECP5 images and tables? > > what is the purpose of removing perfectly good information > > that does not need modification? > > Because it is not good information, you need to update it to conform to the > ft232 wiring colours. this forces me to switch tasks, risking leaving Jean-Paul and Staf without support. please for god's sake understand that your continued desire to dodge responsibility for this task is having consequences. please urgently take steps to minimise the amount of work that i am required to do. please restore the VERSA_ECP5 images please restore the colours to match the VERSA_ECP5. please ensure that the page states that people may have different FT232 devices please edit the DCD FT232 image (which is the device that i have here) has the correct colours. please ensure that the pin numbering tables match the two FT232 devices, one that you have, and one that i have. please add a note stating that many people wishing to connect FT232 devices will need to check the pin ordering and go by the colours. and please do this promptly, without fuss, *and without trying to do dodge responsibility*, and without burdening me with additional tasks.
(In reply to Luke Kenneth Casson Leighton from comment #132) > (In reply to Cole Poirier from comment #131) > > (In reply to Luke Kenneth Casson Leighton from comment #130) > > > (In reply to Cole Poirier from comment #129) > > > > > > > > > > > look at the DCD FT232 photo. does the numbering match? > > > > > > > > > > > > > > > this is how mistakes are made. > > > > > > > > It’s all there. If you do not like how it has been done please help and > > > > modify it to suit your needs. > > > > > > i am focussing mentally on bug #620. i reveiewed what you did, and > > > concluded: > > > > > > 1) you missed the point that all FT232 PCBs are different > > > > How about we focus on supporting the ft232 I have here to actually work with > > instead of every one of the variants. > > > > > 2) you missed the point that clarity is critical > > > 3) if you are the one that makes the changes it trains you through "lrarning > > > by doing" > > > > So you’re saying to me that my learning is more important than us meeting > > the tapeout deadline? Because by making me ‘learn’ you have wasted days of > > time that could have been spent testing the ls180 over jtag on the FPGA. > > > > > > > > > > if i do the task, you do not learn. and, more thsn that, it stops me from > > > completing other critical tasks. > > > > Critical waste of time see above. > > > > > > > > Given that we have mere days until the > > > > deadline why don’t you contribute to this instead of unhelpfully pointing > > > > out things you would do differently and saying they are wrong but doing > > > > nothing to rectify this and actually helping. > > > > > > if i stop what i am doing and complete the task that you are responsible for > > > how does that help you or the project? > > > > A week to make me ‘learn’, is ridiculously inappropriate given the > > circumstances. You could do this in half an hour > > i could indeed spend that time, in addition to the critical tasks that i am > currently doing of keeping both Jean-Paul and Staf occupied. > > if i took away the responsibility for the task, how would that make you feel? > > i am already doing massive amounts here. do you wish to add to that list? > > > You checked but are in fact incorrect, the colours have changed. I triple > > checked the wiki. They have changed. > > why did you change them? > > why did you not indicate an intent to change them? > > because you did not inform me of an intent to change the colours, you > are directly responsible for increasing the amount of work needed. > > please put them back to how they were. > > please restore the VERSA_ECP5 images on the page. > > > changing the colours massively increases the tasks that have to be done. > > > > please put the diagrams back exactly as they were. > > > > That will result in incorrect information on the wiki page. > > then that is your responsibility to correct it. > > > It would be more straightforward if you would just do it instead of wasting > > literally 4 days of the week we had to make the tapeout deadline. This is a > > wildly inappropriate trade off in terms of what this has cost the project. > > i simply do not have the time. i am ensuring that both Jean-Paul and Staf > are supported and are never delayed by being without critical information. > > please stop fighting and dodging responsibility for the task: dodging that > responsibility is what is taking up the time. I am not the one who is dodging responsibility here. You are. You have wasted 4 of our 7 available days with your antics here. Intent to change the colours was given here by me, and approved here by you. ``` https://bugs.libre-soc.org/show_bug.cgi?id=517#c97 Luke Kenneth Casson Leighton 2021-04-09 10:07:13 BST (In reply to Cole Poirier from comment #96) > Luke, my proposal is to change the wire colours of on the wiki specified for > the fpga to the colours present on the ft232 6 pin female header. great. ```
(In reply to Luke Kenneth Casson Leighton from comment #133) > (In reply to Cole Poirier from comment #128) > > (In reply to Luke Kenneth Casson Leighton from comment #127) > > > also: why have you removed the VERSA ECP5 images and tables? > > > what is the purpose of removing perfectly good information > > > that does not need modification? > > > > Because it is not good information, you need to update it to conform to the > > ft232 wiring colours. > > this forces me to switch tasks, risking leaving Jean-Paul and Staf without > support. > > please for god's sake understand that your continued desire to dodge > responsibility for this task is having consequences. I am not desiring to, nor attempting to dodge responsibility, you are projecting. Your choices here have wasted 4 of the 7 days we had to meet the tapeout deadline. Please understand that. Please have some humility. Please be helpful instead of the opposite. > please urgently take steps to minimise the amount of work that i am required > to > do. > > please restore the VERSA_ECP5 images > > please restore the colours to match the VERSA_ECP5. > > please ensure that the page states that people may have different FT232 > devices > > please edit the DCD FT232 image (which is the device that i have here) has > the correct colours. > > please ensure that the pin numbering tables match the two FT232 devices, one > that you have, and one that i have. > > please add a note stating that many people wishing to connect FT232 devices > will need to check the pin ordering and go by the colours. > > and please do this promptly, without fuss, *and without trying to do dodge > responsibility*, and without burdening me with additional tasks.
Cole: because you did not inform me that you had changed the colours, or consult me before doing so, i have now wasted time today both on drawing an incorrect FT232 diagram, as well as wiring up the FT232 that i have here, incorrectly. that could have destroyed the VERSA_ECP5 that i have here and if that happens it severely risks jeapordising the project. please get your head together, realise that there are other critical tasks that i have to focus on, that i have other people to manage, and realise that every time you dodge responsibility it takes up even more time.
(In reply to Luke Kenneth Casson Leighton from comment #136) > Cole: because you did not inform me that you had changed the colours, or > consult me before doing so, i have now wasted time today both on drawing an > incorrect FT232 diagram, as well as wiring up the FT232 that i have here, > incorrectly. I did inform you, see direct quote above from comment 97. > that could have destroyed the VERSA_ECP5 that i have here and if that > happens it severely risks jeapordising the project. > > please get your head together, realise that there are other critical tasks > that i have to focus on, that i have other people to manage, and realise > that every time you dodge responsibility it takes up even more time. Stop projecting, stop trying to accuse me of what you have done.
(In reply to Cole Poirier from comment #135) > I am not desiring to, nor attempting to dodge responsibility, you are > projecting. no: asking me to do the task instead of yourself completing it is - fact - you dodging that responsibility. > Your choices here have wasted 4 of the 7 days we had to meet the > tapeout deadline. no: your continued fighting and dodging of responsibility, by asking me to complete the task and make corrections, then complaining instead of doing as i've asked, is wasting time. i have *far more tasks than just dealing with this one*. you *know* this, so why are you making things more difficult for *me*? if i am the one that is the central critical point, why are you asking *me* to accommodate *you*? if you were the one running this project i would not hesitate to accommodate your needs because i understand what it is like to be the one who is the critical central point. *you clearly do not*. > Please understand that. Please have some humility. Please > be helpful instead of the opposite. when we communicate here it is late to extremely late, at the end of an already long day having had to respond immediately to both Jean-Paul and Staf. every day i am already tired at the point at which i am trying to get you to complete a very simple and straightforward task (so that i do not have to be burdened with yet another task). please understand and respect that i am already overloaded and that you are massively adding to the burden.
Clearly I am unable to do the task the way you want it done. I am stepping away to avoid any further conflict. You can do this as you want it done. I will see you and the others on the call on Tuesday. Good luck making the tapeout deadline.
(In reply to Cole Poirier from comment #137) > I did inform you, see direct quote above from comment 97. damnit, that was some time at 4am. i missed it. if i had realised that you intended to change the colours, given that it would mean about 1 hour editing of images and making unnecessary changes i would have said "under no circumstances do that". so please, follow the instructions, stop fighting and resisting, and burdening the person who is UNDER PRESSURE AND THE CENTRAL CRITICAL COORDINATOR OF THE PROJECT, with unnecessary time-consuming tasks. this is not "me being egoistic" or being a fucking idiot, or not respecting your needs, or "projecting": it is simply the reality that i am the one who has the job to coordinate everything.
(In reply to Cole Poirier from comment #139) > Clearly I am unable to do the task the way you want it done. I am stepping > away to avoid any further conflict. You can do this as you want it done. I > will see you and the others on the call on Tuesday. Good luck making the > tapeout deadline. you've just increased the burden of tasks that i am now responsible for. in a few days, i guarantee that you will feel considerable regret at having made this decision. you will feel empty at the fact that you did not meet the challenge and "gave up".
i have now corrected the page and restored the images. it is 00:30 am in the morning and i have critical meetings to attend in the morning. for these critical meetings between Jean-Paul and Staf, i am now likely to be extremely tired, and may make mistakes or not be able to properly pay attention. this is a direct consequence of you not appreciating the reality of the situation, that i am the one that has to have the workload minimised, not you.