<whitequa1k>
did some adjustments and now glasgow can program versa!!
<whitequa1k>
marcan: i've refactored most code to not use the awful bitarray() interface that requires you to reverse all the bits compared to the datasheet and watch for endianness to avoid obscure bugs
<whitequa1k>
can you recheck XC9500 if it still works?
<marcan>
(and now you know the *first* reason I wrote that WS2812 driver, the second one being that CTF level for euskal last week)
<whitequark>
i never actually figured out what's the deal with the CTF there
<whitequark>
like what's the flag
<whitequark>
tnt: I'm curious about this "icePick" thing
<marcan>
the "flag" is just the password that lets you prove you solved the challengef
<marcan>
*challenge
<marcan>
(in a jeopardy style or related CTF)
<whitequark>
electronic_eel: poke
<electronic_eel>
whitequark: you want to know about the progress of the test jig?
<electronic_eel>
I think I can start working on it next week
<electronic_eel>
but I think the critical path re the test jig will be esden, as he'll have to make a glasgow for me to test the jig pcb and also order the jig fixture from china
<whitequark>
electronic_eel: I asked Greg to do that. I can pay for it as well if you would like me to.
<whitequark>
regarding the jig fixture, that is not required for you to do layout, or is it?
<electronic_eel>
ah, ok, when I get one from Greg that will be much faster than waiting for esden
<electronic_eel>
Greg is using exactly the specified parts, like leds, while esden is using some other parts from his bin, correct?
<whitequark>
yes.
<electronic_eel>
could make a difference regarding the current draw. But I think that is something we can adjust in software later on
<whitequark>
certainly
<electronic_eel>
esden said he plans to use the same fixture model as xobs
<electronic_eel>
he posted a photo of it
<electronic_eel>
I think that is enough for me to make a layout that would fit it
<whitequark>
ok
<electronic_eel>
must not be a perfect fit, he can always use some self tapping screws and washers to screw it in
<electronic_eel>
In this moment the fedex courier delivered the samples from TI for the test jig...
<electronic_eel>
does Greg know that one of the Glasgows is for me?
<whitequark>
talking with him
<electronic_eel>
ok, then I can contact him for the shipping address and so on
<whitequark>
yep
<electronic_eel>
re payment - I have no problem to pay a reasonable price for it
<whitequark>
ack
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fj9Pz
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] marcan c1c8316 - cli: Make interaction work with run-prebuilt
<tnt>
whitequark: it's pretty much just an ice40 and using the fpga IOs directly. 95% of what I do is really <= 3v3 and doesn't need huge speed, so I can live with FS.
<whitequark>
interesting
<whitequark>
what about software?
<tnt>
Most of it remains to be written :) so TBD. I have a few ideas, but nothing fleshed out yet. I definitely want to have something like FTDI emulation, just to gain support for a lot of software 'out-of-the-box'.
<electronic_eel>
tnt: serial or the mpsse and bitbang stuff?
<tnt>
mpsse
<whitequark>
so, you've basically made "Glasgow rev0" (what it was supposed to be before scope creep)
<whitequark>
there is even MPSSE gateware you can reuse.
<tnt>
whitequark: ah well, I discovered glasgow at revB :) It's actually while I was talking with someone about making this thing that he pointed me to glasgow, like a 1/1.5y ago or so ...
<whitequark>
tnt: none of this was especially public, it was basically all in my head
<whitequark>
you see, Glasgow was originally meant to be a cheap drop-in replacement for FTDI silicon
<whitequark>
no level shifters, no FX2...
<tnt>
Ah well yeah, then it's basically it :p
<whitequark>
I guess I'm glad someone actually made it :D
<tnt>
It's not as small as I would have liked in the end, but I wanted to keep with 'easy' pcb rules so people can also easily make it. It has like 15 BOM lines or so, and nothing really crazy.
<whitequark>
yes
<electronic_eel>
bga or not, that's the question if it can be easily made by a lot of people or not
<electronic_eel>
whitequark: thanks for the scope creep, I like the concept of Glasgow as it is now :)
<whitequark>
well same
<tnt>
Yeah definitely, I mean, I've been using my revB and now revC for a bunch of stuff as well.
<whitequark>
tnt: I pushed my WIP on the MSP430 debug applet...
<_whitenotifier-3>
[Glasgow] whitequark created branch wip-applet.debug.msp430 - https://git.io/fhhGp
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to wip-applet.debug.msp430 [+1/-0/±2] https://git.io/fj9Xl
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark 8d9ce19 - applet.debug.msp430.{jtag,sbw}: new applets.
<whitequark>
it doesn't look like MSP430 attach succeeds.
<whitequark>
I am not sure why.
<whitequark>
I suspect it might be because of TDI toggling where it should not
<whitequark>
think you can take a look at it?
<whitequark>
if you fix that, I might be willing to write the rest of the debugger.
<tnt>
whitequark: yup, digging out my FR2433 board.
<whitequark>
miiiiight want to write a SBW decoder for pulseview... not sure... but decoding them manually gets old.
<whitequark>
however. you might also be able to hook up the applet analyzer directly to the JTAG lines.
<whitequark>
(before SBW encoding.)
<tnt>
I had a quick look yesterday trying to understand mspdebug see if I could easily plug into it, but at first glance it was relying on the FET fw to do all the work :/
<whitequark>
indeed. SBW is timing critical so that's probably why
<whitequark>
both individual bit cells and overall programming
<whitequark>
tnt: re your microwire patches
<whitequark>
I think the microwire applet would be better structured after the JTAG applet, since both are bit oriented
<tnt>
Ok I can have a look. I actually just ordered a new microwire eeprom so I could test with ... (the original one I worked with was from an instrument and has been since mounted back into that instrument :p)
<whitequark>
I have a few.
<whitequark>
I might just write the new interface now
<whitequark>
was going to do it for a while
<tnt>
I need to make myself a printout of the glasgow pinout .... looking it up each time is becoming anying.
<whitequark>
revC should have it on the back
<tnt>
yeah, but mine is in a case that's not transparent :p
<whitequark>
ah of course
<whitequark>
I always feel like Glasgow needs to have some sort of "SERDES" class
<whitequark>
perhaps to drive JTAG at very high clock speeds or somesuch
<whitequark>
but making it work with things like non word wide transfers is not quite trivial
<whitequark>
right now JTAG breaks above 6 MHz for example, which is silly
<whitequark>
it should work just fine at least up to 12-16
<tnt>
I: g.applet.interface.sbw_probe: found MSP430 core with JTAG ID 0x19
<tnt>
that's a good start.
<whitequark>
actually, that's completely wrong
<tnt>
?
<whitequark>
there's no core with JTAG ID 0x19
<whitequark>
FR2433 should have JTAG ID 0x98
<whitequark>
wait
<whitequark>
is... is that bit-reversed?
<tnt>
yeah
<whitequark>
that seems related to my recent refactoring, and would explain why i can't get it to work
<tnt>
oh wait, why do they have TDI going high between TMS and TDI slots for ClrTCK
<whitequark>
yes. I don't get it.
<tnt>
Mmm, I think they want the "edge" (rising or falling) to be generated purposefully within the high period of the TDI slot. So when in RUN/IDLE mode, half way through the low cycle of TMS they restore the previously captured state of, then midway through the high period of the TDI slot they force the edge (rising/falling/none) they want.
<tnt>
I'm guess that the TDI slot act as a "clock enable" signal. And so you need the edge to happen with proper setup/hold time wrt to it.
<whitequark>
right, this is my conclusion as well
<whitequark>
that's... nasty
<whitequark>
tnt: what do the middle two rows on Figure 10 even mean?
<whitequark>
that if you call ClrTCLK when it's already low, nothing happens?
<tnt>
yeah
<tnt>
(i.e. no edge and not generating another falling edge that didn't have a matching rising edge)
<whitequark>
right
<whitequark>
mhhh how do i even add this?
<whitequark>
maybe add first class support for "sideband" pins to JTAG?
<tnt>
I guess the easiest way to handle this would be for the 'adapter' to know from the 'driver' if it's in RUN/IDLE. Then it can have it's own 'memory' of the TDI value at the last cycle and properly restore it during TMS cycle and apply the new one at the right spot in TDI cycle.
<whitequark>
I guess
<whitequark>
mhmm
<tnt>
Alternatively have the 'driver' allow to push specific commands to the 'adapter' so instead of just take tdi,tms, it knows that this cycle it needs to generate 1 rising edge, or 1 falling edge ... or 50 pulses ....
<whitequark>
you can't do 50 pulses..
<tnt>
why ?
<whitequark>
won't fit... oh wait
<whitequark>
that's during the high part
<tnt>
Oh, yeah, I didn't actually count .. I know they send 35 at some place, didn't check for 50 :p
<whitequark>
bleh
<whitequark>
custom commands seem like a lot of pain
<tnt>
whitequark: mspdebug actually has lowlevel jtag code. Including how to set breakpoints and stuff like that.
<whitequark>
yes, I was expecting to see that there.
<whitequark>
so that's where one can look it up.
<tnt>
Oh ... the FET firmware sources are actually available duh ...
<whitequark>
tnt: btw. I must admit you probably had the right idea. the SPI master applet should expose sideband signals within the signal stream.
<whitequark>
then there is no need in synchronize()...
<whitequark>
the command stream*
<tnt>
whitequark: Ah yeah. Well for the reset control, added complexity was a bit overkill. Did you find a case where you need tighter control ?
<whitequark>
tnt: there is a tradeoff: a little complexity in every applet (register management) or a bit more in one applet
<whitequark>
so for JTAG... give me a sec
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±6] https://git.io/fj9Hg
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark 5c27fe4 - applet.interface.jtag_probe: add explicit support for sideband signals.
<whitequark>
tnt: take a look at that commit
<whitequark>
i'm looking at jtag-probe and spi-master and the command set is super similar
<whitequark>
except spi-master is a bit more ad-hoc and dirty
<whitequark>
so maybe they could be unified... not in code but in structure at least
<tnt>
whitequark: yup I see. And the microwire will end up with a very similar command set as well.
<whitequark>
yes.
<whitequark>
I am not sure if it makes sense unifying SPI and microwire.
<whitequark>
it... might
<whitequark>
or might not
<whitequark>
I think, when in doubt, I will err on side of duplicating code.
<whitequark>
because then you can change one copy and not have to re-test every other configuration too.
<whitequark>
tnt: oh re sideband
<whitequark>
take a look at display-pdi.
<whitequark>
it uses sidebands too.
<whitequark>
and it actually needs good synchronization
<whitequark>
tnt: for that matter... CS# can be just another sideband?
<whitequark>
because there are devices with multiple CS# for example
<whitequark>
I like how every major interface ends up as "SERDES plus sideband".
<tnt>
yup, cs# is totally a side-band.
<whitequark>
this should really future-proof the SPI master applet.
<tnt>
Covering a maximum of base protocol using a single flexible applet (like which edge used for what) is something I wanted to look at deeper for the icepick because I don't want to reflash the flash (only way to change gateware) for each proto, so I need 1 core that handles a bunch of stuff.
<tnt>
Sort of an advanced mpsse ...
<whitequark>
actually, i think glasgow applets could use more gateware configurability too.
<whitequark>
for example rebuilding each time you change the clock is silly
<whitequark>
but, re: that advanced gateware: I think I know what can work.
<whitequark>
I want to make the "OSERDES" and "ISERDES" blocks that are good for building pipelined serial interfaces.
<whitequark>
they would always drive SB_IO in DDR mode and such.
<whitequark>
I think since you only have 4 (I think?) pins you can put a pair on each pin.
<tnt>
What do you mean 4 pins ?
<whitequark>
how many pins does icepick have?
<tnt>
10 IOs. 6 in one bank, 4 in another.
<whitequark>
ahh hm
<whitequark>
that would be "an interesting problem"
<whitequark>
I think I know how to solve it.
<whitequark>
have all OSERDES and ISERDES share a bus. say 4 address + 8 data pins
<whitequark>
lines*
<whitequark>
the command FIFO would have a command to set up the crossbar interleave sequence. for example you want to output on pins 0 and 1 and input on pins 2, maybe for JTAG
<whitequark>
then, each time when all the SERDES become ready, it feeds the next 2 bytes into OSERDES 0 and 1, and takes 1 byte from ISERDES 2
<whitequark>
repeat for count words, count fractional words.
<tnt>
Mmm, yeah, this shared bus to control the io is interesting.
<whitequark>
this could potentially be very compact.
<tnt>
Yeah and I'm not looking for very high speed (I have nowhere to get/send the data to all that fast anyway), so time interleaving the bus access isn't a big penalty.
<whitequark>
it would actually work at system clock rate as long as you have 8 SDR pins.
<tnt>
ack
<whitequark>
I might even be interested in implementing this
<whitequark>
it would be in nmigen of course :)
<whitequark>
but I really need these OSERDES/ISERDES blocks for Glasgow.
<whitequark>
and the entire thing can be prototyped inside Glasgow
<tnt>
how would you handle bidir IO ? (that change direction in the middle of the 'word') Just have a serdes for the OE I guess.
<whitequark>
yeah.
<whitequark>
or:
<whitequark>
don't have that and instead use partial words
<whitequark>
eg. 3 bit word, OE change, 5 bit word
<whitequark>
this saves you a lot of resources and is not a large perf penalty anyway.
<tnt>
I have to let that idea stew in my brain for a bit to see how it would all fit. But if you implement it for glasgow, I'll definitely have a good look at it :p
<whitequark>
tnt: I have other things to do, but if this will help you, I might prioritize it a bit
<whitequark>
well, I always have a lot of things to do.
<tnt>
whitequark: atm, it's a bit early to say, so don't shuffle your schedule just yet.
<whitequark>
ok.
<tnt>
whitequark: coming back to sbw, did you decide how you'll deal with tclk ? Make it an aux signal and have the sbw generate the edge at the right place when it detects you changed it ?
<whitequark>
tnt: exactly
<whitequark>
or not like detects I changed it
<whitequark>
I will give it "TCLK before" and "TCLK after" in 2 separate bits
<tnt>
Ah yeah, even simpler.
<whitequark>
yes. very simple. completely stateless.
<whitequark>
in fact instead of ClrTCLK and SetTCLK i could provide something like PosTCLK and NegTCLK (edge)
<whitequark>
but maybe that does not work so well with ordinary JTAG...
<whitequark>
come to think of it. TEST and RESET should be sidebands for the MSP430 to enter 4 wire JTAG mode.
<tnt>
One signal to turn them to 'bit bang mode' where they are manually controlled and 2 bits to set them ?
<whitequark>
no, just connect to aux. since they are not shared with actual JTAG pins.
<whitequark>
but if they did, yes, that would be what i do.
<tnt>
Oh, nm ... I ... missed the " enter 4 wire JTAG mode" part duh ...
<tnt>
I thought it was to enter the SBW mode
<whitequark>
haha no, that would be too easy
<tnt>
I can't really find much technical documentation about the EEM (debug module). The family manuals have a few pages of general architecture on it. And then the FET source code has some registers/etc... but not a PDF explaining it all AFAICT.
<whitequark>
typical
<tnt>
I think I'll try to make myself useful and write a SBW PD for sigrok
<whitequark>
:D
<whitequark>
yes, I was thinking about it...
<whitequark>
but i do not like sigrok's workflow very much, it feels a bit too obstacle-y for me.
<whitequark>
you know. the kind of thing i aggressively eliminate anywhere in glasgow
<tnt>
I dumped the flash both with glasgow and mspdebug
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to wip-applet.debug.msp430 [+1/-0/±4] https://git.io/fj95G
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark b161d23 - applet.debug.msp430.{jtag,sbw}: new applets.
<whitequark>
ahhh
<whitequark>
:D
<tnt>
Very cool !
<tnt>
And now that the lower level macros/functions work, the other high level functions should prettymuch be copied from the doc, calling the right macros.
<tnt>
Mmm I did a quick attempt at ReadMemor for the Xv2 but there are read errors, I must have missed something. But it's getting late, I'll get back to it tomorrow. In anycase, whitequark big thanks ! :)
<whitequark>
sure
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to wip-applet.debug.msp430 [+1/-0/±4] https://git.io/fj9dt
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark 0c38d8a - applet.debug.msp430.sbw: new applet.