<cr1901_modern>
Is this the stock firmware? Or did you flash something previously to it?
<whitequark>
i only ever connected this devkit to glasgow
<whitequark>
and glasgow can't flash yet so...stock
<whitequark>
i don't think i've actually plugged it into USB "properly" yet
<cr1901_modern>
haha
<cr1901_modern>
IIRC, the stock firmware for G2 blinks the two LEDs and emits a msg over the UART
<whitequark>
yes
<whitequark>
i can load it in binja
<whitequark>
it's... well, it's msp430 code.
<cr1901_modern>
Aka "Binja is okay w/ the input" :D
<whitequark>
it looks like sensible firmware code
<whitequark>
i have nfc what the register writes do
<cr1901_modern>
0x200 on is RAM, 0x00 - 0xff is 8-bit peripherals, 0x100-0x1ff is 16-bit peripherals (except for USB)
<whitequark>
so like, i can write to FCTLn
<whitequark>
i presume i can
<cr1901_modern>
I don't think any of the peripherals get locked during flash programming
<cr1901_modern>
I don't have any experience with the flash controller- it's been on my TODO list, but never found an application where I needed to touch it.
<whitequark>
lemme try writing
<cr1901_modern>
Do you have the family manual open/the clock freq set up correctly?
<whitequark>
former yes, latter not sure
<cr1901_modern>
7.3.1 Flash Memory Timing Generator- it wants a 257 to 476 khz clk
<whitequark>
so i don't care about that yet
<whitequark>
when i write to FCTL3 it tells me that the key is wrong
bvernoux has quit [Quit: Leaving]
<cr1901_modern>
Just to eliminate this: Are you writing the top 8 bits of as 0xA5?
<whitequark>
yeah
<cr1901_modern>
I can't remember if _every_ write has to be qualified w/ the key or just the first write
<whitequark>
actually. let me check if i can read/write RAM first
<whitequark>
i absolutely can not
<whitequark>
wait
<whitequark>
RAM is at 0x200, not 0x0
<whitequark>
ok well it doesn't work there either
<cr1901_modern>
Wonder if something needs to be unlocked
<whitequark>
no, i mean
<whitequark>
i write 0xabcd
<whitequark>
i get 0x43d2
<cr1901_modern>
It's backwards
<whitequark>
huh?
<cr1901_modern>
abcd = 1010101111001101
<cr1901_modern>
reverse the last 8 bits
<whitequark>
... the fuck?
<cr1901_modern>
wait, no it's not
<cr1901_modern>
10110011 == 0xd3
<cr1901_modern>
not d2
<whitequark>
hm
<whitequark>
all writes become 0x43d2.
<whitequark>
literally i can write anything to any point in memory and 0x43d2 gets written
<cr1901_modern>
Sorry to get your hopes up :P
<whitequark>
google "msp430 0x43d2"
<cr1901_modern>
Well, there's a forum post about it... and a few chinese articles
Foxyloxy has quit [Ping timeout: 260 seconds]
<whitequark>
that's the CLR instruction
<whitequark>
wait
<whitequark>
that's the mov.b instruction.
<whitequark>
mov.b 1 specifically
<cr1901_modern>
0x4343 is a NOP pattern that is used by debuggers for software breakpoints
<d1b2>
<Darius> I do like the MSP430 breakpoint hack
<cr1901_modern>
I have not seen this behavior before. In your position, I would do "mspdebug rf2500 'prog blinky.elf'" or some other )(I can provide one for you) and capture the traffic on the SBW pins
<whitequark>
hm
<cr1901_modern>
I can provide blinky.elf* for you
<d1b2>
<Darius> (where the debugger configures the micro to break on a certain data pattern)
<cr1901_modern>
If you want a point of comparison, you may wish to read the memory contents of the flash first to a file
<cr1901_modern>
so you can swap back and forth
<whitequark>
hm
<whitequark>
sounds reasonable so i won't do that
<whitequark>
is SR memory mapped?
<cr1901_modern>
SR? Status register? No it's R1 IIRC
<whitequark>
hm. how do i read R1 via JTAG
<cr1901_modern>
I don't know; THAT might require the EEM. mspdebug can clearly do it tho
<cr1901_modern>
So lemme take a dive into mspdebug and find the relevant code
Foxyloxy has joined #glasgow
<whitequark>
i think i know how
<whitequark>
but it's horrible
<cr1901_modern>
Oh?
* whitequark
wonders where to get the MSP430 doc required for the applet
* whitequark
remembers she literally has a doc archive for this specific case
<d1b2>
<Darius> past you was thinking ahead
smkz has quit [Quit: smkz]
smkz has joined #glasgow
<whitequark>
cr1901_modern: ok ugh i remember now
<whitequark>
the way you read/write CPU registers is by intercepting the memory data bus and stuffing the CPU with instructions "fetched" from JTAG
<whitequark>
so you basically have to make it execute uh
<whitequark>
... i have no idea how msp430 assembly works
<cr1901_modern>
in other words, via the EEM
<whitequark>
EEM?
<whitequark>
wait, you call *that* EEM? that's the hard part?
<cr1901_modern>
Embedded Emulation Module
<whitequark>
... ok this is way easier than what i anticipated
<whitequark>
i know exactly how to drive this crap
<whitequark>
it is a horrible, fragile pain in the ass, but after MIPS EJTAG nothing scares me
<whitequark>
i have seen silicon bugs you probably cannot even contemplate (and keep it that way)
<cr1901_modern>
It's hard in the sense that "I don't want to RE it, and I don't want to write several drivers to talk to a FET that talks Spy-Bi-Wire to EEM"
<whitequark>
ohhhh did you think you need the EEM to run arbitrary instructions?
<cr1901_modern>
yes
<whitequark>
you don't
<whitequark>
ok well
<cr1901_modern>
The "intercepting 0x4343 as a software breakpoint" on the data bus is done via the EEM. So I thought sniffing the databus for reg contents would be done the same way
<whitequark>
nope
<whitequark>
i see why you'd think that
<whitequark>
but it's not how it works at all
<cr1901_modern>
If you can run arbitary insns w/o the EEM, then it's a moot point :)
<whitequark>
correct
<whitequark>
hm.
<whitequark>
i need some cool instructions to run.
<cr1901_modern>
bis/bic gets you an atomic bool. I think that's pretty cool :P
<whitequark>
yeah but like
<whitequark>
something i can see
<cr1901_modern>
(Before I forget: when you're doing debugging, if you're dumping the regs via JTAG, is there like a scratch space to store reg contents so you're not interfering w/ mem contents of your program)
<cr1901_modern>
?*
<whitequark>
don't need that
<whitequark>
lemme just uh... implement that
<whitequark>
god i hate this style of debug peripheral
<whitequark>
it's not as bad as the one MIPS EJTAG has but it's close
<cr1901_modern>
Is it worse than MIP- ahh
<whitequark>
basically what they did is cut every control signal into and out of the core and into and out of the memory
<whitequark>
and stuffed JTAG registers in between
<whitequark>
and that's it
<whitequark>
so you're basically driving the CPU on manual
<whitequark>
you have to do a zillion operations to do the simplest thing, and getting the waveforms slightly wrong means nothing works and you have no idea why
<whitequark>
and that's *before* we get to silicon bugs.
<cr1901_modern>
Oh JESUS. And I'm guessing the EEM leverages this already-existing functionality to do more cursed shit?
<whitequark>
no idea wtf EEM does
<whitequark>
don't care about it for now
* cr1901_modern
nods
<whitequark>
my favorite thing is that the clock to the CPU is provided by JTAG TDI
<whitequark>
so you have like... extra race conditions
<whitequark>
*and* your JTAG probe must be able to toggle TDI without toggling TCK
<whitequark>
obviously this means msp430 can be the only device in the chain.
<whitequark>
so it's not even *really* JTAG
<cr1901_modern>
All this to save two signals
<whitequark>
no
<whitequark>
this is with full sized JTAG
<whitequark>
with SBW you uh... you have another layer of indirection
<whitequark>
but you *still* toggle TDI, it's just now encapsulated in SBW triplets
<d1b2>
<Darius> 🤢
<whitequark>
msp430 has the worst perversion of the JTAG physical layer i've seen yet
<whitequark>
not SBW, SBW is okay. the TDI thing.
* cr1901_modern
wonders if this is b/c msp430 is old and they- oh who am I kidding, I'm an msp430 apologist
<whitequark>
they also really can't decide which endianness they want
<whitequark>
so you constantly have to flip values around
<whitequark>
i checked the logs and apparently msp430 is responsible for bits.reverse() existing in the glasgow codebase
<cr1901_modern>
It's like you read my mind... I was looking through the archive for that right now (but forgot the number :P)
<whitequark>
well i don't, i read TI's docs
<whitequark>
okay, found the bug that broke memory writes
<whitequark>
hm, no, i didn't
<whitequark>
just confusing docs
<cr1901_modern>
whitequark: Hmm on page 22, there's a list of 4-wire JTAG pins mapped to the relevant Port 1 I/Os. If I'm reading correctly, they do NOT overlap with the Spy-Bi-Wire pins
<whitequark>
cr1901_modern: found the bug
<cr1901_modern>
nice :D
<cr1901_modern>
You have to use Spy-Bi-Wire to enable 4-pin JTAG, but once you do that, you get 4 dedicated pins for JTAG _separate_ from Spy-Bi-Wire
<whitequark>
fun fact: if you follow slau320ag exactly, it will also be broken
<whitequark>
just in different, more subtle way
<whitequark>
you should be able to see the bug in listing 2.3.3.2
<cr1901_modern>
IR_CNTRL_SIG_16BIT is missing from yours
<cr1901_modern>
present in slau320ag
<whitequark>
that happens before the loop
<whitequark>
it's ok, no need to resend that command every time
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to wip-applet.debug.msp430 [+1/-0/±3] https://git.io/JTooV
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark 5968055 - applet.debug.msp430.sbw: new applet.
<whitequark>
cr1901_modern: ok well, let's write some registers
<whitequark>
how do i poke the LEDs?
<whitequark>
P1.0?
<cr1901_modern>
Red is attached to Port 1.0, Green is Port 1.6
<whitequark>
ok how do i write there
<cr1901_modern>
set P1DIR equal to output (I don't remember which dir is which offhand) and then write 0b01000001 to P1OUT
<whitequark>
aha, P1OUT
<cr1901_modern>
Addrs 0x22 and 0x21 respectively
<whitequark>
can you explain word/byte access?
<whitequark>
what are the exact restrictions
<cr1901_modern>
Set bits is output dir
<cr1901_modern>
Addrs below 0x100 are byte accessed registers, addrs below 0x200 but above 0x100 are word-accessed registers. You can access word regs as bytes. Dunno if you can access byte regs as words and expect it to "do the right thing"
<cr1901_modern>
I don't know, as in "I've never tried" or "I've never thought to try" :)
<whitequark>
ack
<cr1901_modern>
Okay, 16-bit regs must be even-byte aligned; an 8-bit access will be interpreted as "zero extend to high byte". 8-bit regs _can_ be written using a word; top byte is ignored.
<cr1901_modern>
And Special Function Registers are in the first 16-bytes of the addr space; they must be written w/ byte accesses.
<whitequark>
mkay
<cr1901_modern>
Btw, is the bug the DR_SHIFT16(0x2408) :D?
<cr1901_modern>
Well the only other line that looks suspect to me is DR_SHIFT16 "Address", but it doesn't tell you to increment the address
<cr1901_modern>
it's only implied by "DESIRED address"
<whitequark>
much more obvious than that
<cr1901_modern>
Oh, the loop forgets to ClrTCLK. As portrayed in the diagram, it clears TCLK only once before looping
<whitequark>
yep
<cr1901_modern>
That diagram is really kinda shit and shouldn't be split into two pages IMO
<whitequark>
yep
<whitequark>
that entire document is really kinda shit
<whitequark>
like
<whitequark>
you can only really implement a working debugger if you are a HDL coder imo
<whitequark>
using this document
<whitequark>
cuz it makes no sense otherwise and there are too many places where it's subtly wrong
<whitequark>
cr1901_modern: okay, i have SFR writes
<cr1901_modern>
awesome :D
<cr1901_modern>
whitequark: The diagram is crap. However, I can think of a reason ClrTCLK is at the top- you'll need to to that if you need to swap to/from 8/16 bit writes?
<whitequark>
it's at the top because you need to have TCLK low when you write CNTRL_SIG
<whitequark>
this is why my code sets it twice
<whitequark>
except my code is also bad
<cr1901_modern>
but how do you write a trailing 8-bits of data (note: I'm still looking at the patch)?
<whitequark>
cr1901_modern: okay i think i need some sleep. i think we can make a working msp430 gdbserver based on glasgow tomorrow
<whitequark>
oh, i don't, there's an assert that makes sure this crashes
<whitequark>
if you try that is
<whitequark>
the doc doesn't explain it but i know how to do it, you set BYTE=1 in CNTRL_SIG
<cr1901_modern>
haha... sleep well. gdbserver should be interesting :o.
<cr1901_modern>
Ack.
<cr1901_modern>
I have to mux what I'm currently working on, but I'll also take a look at e.g. rf2500 transport and FET firmware, and compare the latter to what Glasgow is doing
<whitequark>
i think i probably don't need your assistance to finish the gdbserver
<whitequark>
except *possibly* for breakpoints
<whitequark>
since that actually needs EEM
<awygle>
wow some work went down here huh
Getorix_ has joined #glasgow
Getorix has quit [Ping timeout: 265 seconds]
<cr1901_modern>
awygle: See #rust-embedded chat from about 4:00PM EDT today onward for the context. Someone else asked for probe-rs msp430 support, and I said "it was too much work b/c the EEM isn't documented and there's about 10 million different ways to talk JTAG in msp430 lang". >>
<cr1901_modern>
Well the second problem still exists, but as has become clear over the past day, I misunderstood how msp430 JTAG works for flashing/erasing etc. And wq used it as an opportunity to finish msp430 applets.
<cr1901_modern>
(well the "EEM isn't documented" is still true. But for MVP it probably doesn't matter.)
<kc8apf>
that's ignoring that probe-rs has effectively no support for anything other than ARM DAP
electronic_eel_ has joined #glasgow
<cr1901_modern>
I've been trying to limit my bitching about how ARM is the only thing really supported well, but... yes.
electronic_eel has quit [Ping timeout: 272 seconds]
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
<kc8apf>
I've been pulled in to probe-rs for work. In some ways it is much better than openocd and pyocd but it is myopically focused on ARM so far
<kc8apf>
yatekii was shocked by how different something like MIPS is
<awygle>
is yatekii working on embedded now?
<awygle>
last i talked to them was in a totally different context
<awygle>
"myopically focused on ARM" is a good description of rust-embedded generally
<awygle>
and a good explanation of why i got turned off of contributing pretty quickly
<kc8apf>
yatekii is the BFDL for probe-rs
<awygle>
ah
<awygle>
good for them
<kc8apf>
despite the focus on ARM, embedded Rust doesn't know how to handle things like ROPI/RWPI
<awygle>
can you please expand those acronyms so i can be sure i am on the same page
samlittlewood has quit [Ping timeout: 240 seconds]
samlittlewood_ is now known as samlittlewood
Stephanie has quit [Quit: Fuck this shit, I'm out!]
Stephie has joined #glasgow
Getorix has joined #glasgow
Getorix_ has quit [Ping timeout: 260 seconds]
Stormwind_mobile has quit [Remote host closed the connection]
Stormwind_mobile has joined #glasgow
samlittlewood has quit [Read error: Connection reset by peer]
samlittlewood has joined #glasgow
<lukego>
Okay, I'm having a go at replacing the FPGA on my Glasgow, but I'm not optimistic :-| I lost most of the solder mask under the BGA while cleaning it up so there's much less margin of error now before bridging between a pad and an exposed trace
<lukego>
seems like 350C iron is good for lead-free soldering but terrible overkill for cleaning up pads
<tnt>
lost solder mask ?!?!
<lukego>
yep, stripped straight off while trying to clean up with desoldering braid
<tnt>
Those must have been really crappy PCBs, I've never removed any soldermask with a desolder braid.
<tnt>
(and my iron is at 350C, that's my normal temp)
<tnt>
or your iron is deeply miscalibrated
<lukego>
These PCBs are from JLCPCB (i.e. cheapest available...) and I've had this problem before using multiple irons at 350C
<d1b2>
<Attie> @lukego ... what sort of force were you using? removing solder mask is typically something you have to work at
<d1b2>
<DX-MON> to be fair, when using a particularly good flux and braid, I've taken mask off even my OSHPark PCBs
<d1b2>
<DX-MON> but that's after scrubbing hard with a lot of preasure
<d1b2>
<Attie> yeah... i use a xacto knife and scrape sideways to remove solder mask
<russss>
hmm I've found JLC's boards to be fairly solid, at least in 4-layer
<tnt>
Attie: yeah same here, I usually have trouble removing it when I want to.
<russss>
(I find preheat helps a lot with reducing damage to the board when desoldering)
<tnt>
I have lifted _pads_ when cleaning them (those not used/connected to traces ...) but never the mask.
<d1b2>
<DX-MON> yeah, the JLC boards I've had made are very hard to damage, but they're also not the default green w/ HASL process
<d1b2>
<DX-MON> so maybe it's because I'm already asking them to make a nicer board that I never get duds
<d1b2>
<Attie> hmm, maybe
<d1b2>
<Attie> @lukego - would be interesting to see (good) pics when you get the bga off
<tnt>
+1
<tnt>
(well I assume the bga is off now if he cleaned the pads :p)
<lukego>
I've replaced the chip now. did the best that I can, not too much flux so it doesn't "float" around spreading solder spheres across all the traces, remains to be seen if the positioning was good enough. have had the camera running so I can capture some pics of the solder mask massacre :)
electronic_eel_ is now known as electronic_eel
<lukego>
oops U1 went sliding a good half-centimeter while I was replacing the BGA, going to have to put that back and do a serious inspection to check for other problems
<lukego>
I think the air flow was extremely gentle so likely I bumped it with the nozzle while getting in close to the FPGA
<lukego>
the resoldering job looks about as good as I can hope given the circumstances. chip didn't move during reflow, I put in plenty of heat, and alignment looks good from the sides where I can get a decent oblique view of the result. fingers crossed. swapping out U2 with the right part before testing.
<lukego>
done (and even noticed that I'd flipped its orientation in time to fix that before the board had cooled down...)
<lukego>
okay here's me butchering soldermask and cooking FPGAs. The board is moving not because I'm pushing on it hard but because it's held loosely by one PCBite. https://twitter.com/lukego/status/1320707651483901952
<lukego>
No luck. 5V reads 5V, 3V3 reads 3V3, but 1V2 reads 0.48V
<d1b2>
<Attie> interesting... i'd highly recommend securing your work better - will make things quite a bit less frustrating
<d1b2>
<Attie> and you seem to be using already-saturated braid?
<d1b2>
<Attie> I wonder what the flux you're using is, and if it's particularly agressive
<d1b2>
<Attie> " no luck " - oh, shame...
<lukego>
Yeah, it was sloppy not to secure better, I'm experimenting a lot with different setups for holding/panning/rotating the PCB and today's was a bit lame.
<lukego>
I used fresh braid but guess it took up solder during cut out parts of the video. two kinds of amtech tacky flux, both RMA, should be medium aggressive I suppose
<lukego>
drawing 16mA now
<d1b2>
<daveshah> Did you measure 1.2V without the FPGA in place?
Chips4Makers has quit [Remote host closed the connection]
<lukego>
oops, no
<lukego>
that would have been good to do :)
Chips4Makers has joined #glasgow
<lukego>
I guess the options now are (a) find a problem other than the FPGA or (b) transplant all the parts onto a fresh PCB
<d1b2>
<Attie> i can't remember where we got to, but verifying the 1.2v supply is worth going (even again) - check for 5v on pins 4,5,6
<d1b2>
<Attie> visually inspect passives (e.g: C27) for shorts
Chips4Makers has quit [Remote host closed the connection]
Chips4Makers has joined #glasgow
<d1b2>
<Attie> 16mA isn't a lot, which makes me wonder if it's a short... is U36 hot? (it should be able to deliver ~300mA according to the schematic)
<lukego>
I'd say the FPGA is the warmest part of the board, but it's not "hot"
<tnt>
lukego: I assumed you tried replacing the LDO ?
<tnt>
what you can try is use a PSU and inject 1v2 into the 1v2 rail with a 50 mA OCP or something.
<lukego>
lemme find the power cable for my other bench supply...
<lukego>
or maybe I'll try these suggestions in order :)
<lukego>
I have tweezer tips for my multimeter so checking for shorts seems like a good opportunity to put them to use
<lukego>
the passives seem to be ok
<lukego>
I'll try injecting 1V2 and see what happens eh
<lukego>
(I mostly just tested capacitors for continuity, didn't check all the resistors, is that being too lazy?)
<lukego>
(okay now I did a sweep testing resistors too, lowest I saw was 47ohm and I'm assuming that's correct)
<lukego>
injecting 1V2 from a bench supply to the test point lights up U2/U3/U4/U5 LEDs
<lukego>
(but not U1)
<d1b2>
<Attie> note that testing resistors/capacitors in-situ will often give you incrrect results...
<d1b2>
<Attie> re U1 (D6), check it's orientation - e.g: with a multimeter in diode test
<d1b2>
<Attie> good to know that the 1v2 rail isn't shorted!... check U36, pin 4 is ~5v, and if it is, then now might be the time to replace U36
<d1b2>
<Attie> uh... did you remove that disable wire we put in last week?
<d1b2>
<Attie> might be sensible before you start rework actually
<d1b2>
<Attie> @lukego beep!
<lukego>
beep?
<d1b2>
<Attie> ^ just wanted to interrupt before you got the hot air going
<lukego>
oh that kind of beep :) yes, just waiting for the board to cool down after pressing pause on rework :)
<lukego>
preheater was fired up but not yet air gun :)
<d1b2>
<Attie> apologies - i'm a little distracted with work for fully joined-up thinking!
<lukego>
please don't apologise, much appreciate this fantastic help!
<lukego>
probably will take a break for the day soon too
<d1b2>
<Attie> ok
<lukego>
I need to learn how to use my scope... just saying Acquiring and not seeming to show me any signal no matter where I poke it
<lukego>
(okay, pressing the "Auto Setup" button is making it behave more like I expect)
Getorix has quit [Ping timeout: 256 seconds]
<lukego>
So there's major risk of user error here but it really looks to me like 1V2EN from U7 is spiking briefly up by ~1V at ~1kHz
Getorix has joined #glasgow
<lukego>
I'm feeling a bit trigger-happy some I'm gonna try replacing U36 now
Stormwind_mobile has quit [Ping timeout: 260 seconds]
<d1b2>
<Attie> hmm "up by 1v" from what to what?
<lukego>
The new U36 is putting out 0.5V on 1v2
<lukego>
I think that was "up" from ~1V5
<lukego>
So U36 is getting 5V on 5V and getting 1V7 on 1V2EN and it's kicking out 0V5 instead of 1V2 which is weird, rihgt?
<d1b2>
<Attie> certainly not correct
<lukego>
can we say that this is a local fault in that part? what else can it be?
<d1b2>
<Attie> you soldered the pad underneath too?
<d1b2>
<Attie> would be interesting to see some screenshots from the scope
<lukego>
soldered the pad too
<d1b2>
<Attie> you measured 1V2EN -> GND which was okay
<d1b2>
<Attie> did you measure +1V2 -> GND as well? / could you?
<lukego>
I'm using multimeter here rather than scope.... maybe need to fish around for a more ergonomic scope probe
<lukego>
hm I'm seeing 0.15V on +1V2 now but I could swear that was 0.5V just now
<lukego>
Maybe I'll take a break for now and come back tomorrow with the PCBites setup so that I can more easily and reliably take measurements, I think that I have scope probes to suit that
<lukego>
and some magnification which I'm currently only using for soldering...
<d1b2>
<Attie> ok
<lukego>
thanks again for all this help!
<d1b2>
<Attie> np!
<lukego>
but can we summarize out suspects here?
<lukego>
U36 is behaving weirdly, and maybe I'm not fully characterizing its behavior due to using DMM instead of scope e.g. maybe 1V2EN is unstable?
<tnt>
short en to 5v and check output then.
<lukego>
tnt: thanks! noted for tomorrow
<d1b2>
<Attie> 1V2EN should be coming to 5v, but it isn't / +1V2 isn't up (or stable)... need to verify it's behaviour
<d1b2>
<Attie> I can't really see why 1V2EN wouldn't go to 5v properly, even if U36 enters OCP / Thermal shutdown
<d1b2>
<Attie> also, I wonder if we should move future discussion out of #glasgow - it is indeed a glasgow that you're working with, but the current problem solving feels a little off-topic for this channel
<d1b2>
<Attie> if we find something design-related we can feedback here
<tnt>
EN threshold should be 0.9v so a stable 1.7v should turn it on.
<d1b2>
<Attie> happy to meet in the 1BitSquared discord, or if people here are happy we can stay
<tnt>
so either EN is not stable, or the regulator isn't doing its job.
<d1b2>
<Attie> @tnt yeah - i checked that earlier... we need a scope on the two signals I think
<Lofty>
Honestly I don't mind it being in #glasgow
<Lofty>
For better or worse, this kind of debugging stuff that we're osmosing should be useful for other people who come along with a hand-soldered board
<d1b2>
<Attie> 🙂
<d1b2>
<DX-MON> yeah, this discussion is interesting reading and also, feels definitely on-topic
<d1b2>
<DX-MON> it might even help shape the next revisions to help improve debugability of hand-builds
<d1b2>
<DX-MON> if it's determined that needs improvement
<Yatekii>
kc8apf: sorry, who are you in the rust world? :/ can't associate you :/ brain bork maybe too ... I don't recall the MIPS discussion :/
<Yatekii>
also, I have to correct you, probe-rs supports Risc-V :) The thing is this: my time is limited, since I am not paid for this and thus I am focusing on what I use daily :) AVR & Mips is defacto dead to me. Not saying it is in the industry ;) I'd love to have support for it, it just requires time ...
<Yatekii>
awygle: o/ I am doing all sorts of misc Rust stuff, but the last year I have been focusing on probe-rs with a sad decline last 3 months :/
<Yatekii>
how you doin?
<Yatekii>
kc8apf: wow TIL what BFDL means ^^ hmm idk, I try to not be a dictator :/
<kc8apf>
Yatekii: I use my work account on Matrix: @rick:oxide.computer
<kc8apf>
BFDL isn't a value judgement. Merely a description of a governance model.
<Yatekii>
kc8apf: ahhhh now I see :D
<Yatekii>
kc8apf: yeah, no worries, I didn't take this the wrong way :D
<Yatekii>
kc8apf: now I also recall what you mean with the MIPS discussion :) But that was kind of a fat CPU tho :D
<Yatekii>
wasn't it?
<kc8apf>
Nexus and eJTAG are used in a variety of devices. There are tiny MIPS devices out there.
<whitequark>
i'm not a huge fan of a project positioning itself as *the* probe driver that also claims that certain architectures which still exist are "dead"
<whitequark>
should've been called arm-probe-rs
<Yatekii>
whitequark: I specificially said *to me* and that this would not reflect what's actually the case ;)
<whitequark>
yes but... you're the project leader with the ability to say the last word on a topic
<Yatekii>
I also said that I would love to include those architectures :)
<whitequark>
fair
<Yatekii>
whitequark: I hope that is not the impression I leave :/ I really do not like to decide things myself because it's 100% a community effort.
<Yatekii>
but that also means I cannot implement everything myself.
<Yatekii>
Lots of folks have encouraged me to set up a sponsoring; we'll see where that leads. could maybe enable me to dedicate more time to it.
<whitequark>
the thing about non-ARM support is that most devices are not like ARM
<whitequark>
ARM has (compared to others) very large and complicated CoreSight debug infra
<whitequark>
MIPS and MSP430 for example don't
<kc8apf>
being BFDL means walking an awkward line in being careful of what you say. Your preferences accidentally become self-fulfilling prophecies
<whitequark>
^ also that
<whitequark>
if you don't actively work against supporting only ARM you'll accidentally silo yourself into being able to only do ARM through architectural choices
<Yatekii>
whitequark: yeah, the problem here is that I have never worked with devices other than AVR/ARM :) sure I learned MIPS assembler at ETH ... but yeah. So that's naturally what I aim to support for starters. but that doesn't mean more support should be added :)
<whitequark>
there's "adding support" and then there's "refactoring the entire thing so MIPS is even possible to add"
<Yatekii>
whitequark: yes, that's also why we added Risc-V :) also, Tiwalun is really weary to not go down this route :)
<whitequark>
i'm not familiar with RISC-V debugging, hmm
<Yatekii>
whitequark: ofc. but then again, architectures are so different, I do not claim to be able to get it right the first try ;)
<Yatekii>
we had 3 huge overhauls of the API. I am ok with the current one but could still improve a lot internally :)
<Yatekii>
I absolutely see your concern tho!
<Yatekii>
I feel the same way, but I also feel like I cannot really do anything else than trying my best :)
<whitequark>
glasgow debug applets share nothing but a gdb server plugin
<whitequark>
thta's... one way to do it
<whitequark>
probably doesn't work for probe-rs
<Yatekii>
kc8apf: I agree :) Also the hardest part for me. I speak very black/white. Hard to overcome this habit. Lots of folks that know me know how to deal with it. folks that don't know me will get offended ... guess all I can do is work on it :)
<Yatekii>
whitequark: well the drivers in probe-rs share a common API surface too, which then is used by the GDB stub/vscode-plugin/cargo-embed etc on top :)
<kc8apf>
See Linus Torvalds and mailing list excerpts being news articles
<Yatekii>
kc8apf: heh :D well I sure hope I am not that extreme; hard to judge oneselve tho because the perception is always skewed
<Yatekii>
s/the/that
electronic_eel has quit [Ping timeout: 264 seconds]
electronic_eel has joined #glasgow
<Yatekii>
btw whitequark why is it called scottish army knive? are you scottish or do they actually have a multitool as an army knive? because the swiss don't really :D
<whitequark>
Yatekii: it's just a pun
<Yatekii>
yeah but why scottish?
<whitequark>
because glasgow is in scotland
<Yatekii>
ah I am freakin stupid
<Yatekii>
why glosgo tho then :D
<Yatekii>
*glasgow
<whitequark>
the project started as a drop-in replacement for ftdi chips
<whitequark>
(we still don't have that functionality and might never have by this point lol)
<Yatekii>
ah nooow I see :D
<Yatekii>
thanks
<electronic_eel>
whitequark: the main reason why we can't do ftdi drop-in is the limited control over the usb endpoints and how many we can support on the fx2, right?
<whitequark>
electronic_eel: sorta yes
<whitequark>
I think most OSes don't hardcode EP numbers for FTDI chips
<whitequark>
so I believe we can have descriptors somewhat different from genuine FTDI ICs and it'll still work
<whitequark>
it's just... what's the point? glasgow's variety of low-level protocols are way better than MPSSE
<electronic_eel>
yeah, glagows protocols and possibilities are way better than MPSSE. downside is that there is tons of software out there that has support for MPSSE integrated.
<electronic_eel>
you don't have the capacity to review all the PRs implementing all the features of these other programs into glasgow
<electronic_eel>
so MPSSE would allow you to use the other programs with your glasgow hw, you'd profit at least from the level shifters and protection compared to true ftdi boards
<whitequark>
this is true. the problem is that I'm not yet ready to offer the glasgow USB interface to other software
<whitequark>
since it would create a stable interface where things are not really stable yet
<whitequark>
we could potentially offer a separate repo that hard-flashes Glasgow to become an FTDI
<whitequark>
VID, PID, descriptors, a single bitstream
<electronic_eel>
with glasgow usb interface you mean direct access from other sw to the fx2, not some emulated virtual thing, right?
<whitequark>
yes
<electronic_eel>
the ftdi emulator would not suffer from the stability problem
<electronic_eel>
how would you go back to glasgow? some magic control transfer?
<whitequark>
yes, but it's not something I have to implement
<whitequark>
just the cypress A0 request
<electronic_eel>
ah, right
<whitequark>
this is also how we can safely determine that a given arbitrary vid:pid is actually a glasgow
<whitequark>
just read its EEPROM
<electronic_eel>
I had an idea today how we could implement usb on revE. let's say ktemkins luna efforts pay off and you'll be able to get reasonable usb3 speed with an ecp5 in the future
<whitequark>
two ecp5?
<electronic_eel>
so we could do the actual usb data transfers completely on an fpga, including of course full emulation of ftdi, with correct control eps and whatever
<whitequark>
uh
<whitequark>
revE doesn't even try to pretend to be FTDI
<whitequark>
the idea was that revE coexists with revsCD and is a different class of device
<whitequark>
basically, revE starts to creep up on what azonenberg does, though still much lower-cost of course
<whitequark>
pluggable frontends via SYZYGY and all that
<whitequark>
not quite the same thing as "plug some jumper wires and it goes off" with revCD
<hl>
is there some reason the FX2/FX3 can't be programmed to emulate FTDI if someone wants that? (not familiar with them)
<whitequark>
pretty sure it can be
<electronic_eel>
yeah, but you could either have a traditional glasgow port addin on one SYZYGY, or revE has one additional regular port for something like this
<whitequark>
the reason FX3 is on revE's design is because it's what makes it unbrickable
<whitequark>
oh sure
<whitequark>
rephrasing: i think whether revE has an FTDI mode is orthogonal to whether it uses LUNA or FX3
<electronic_eel>
now, back to my idea. the problem is to control the fpga and make it unbrickable
<electronic_eel>
we could put a usb3 hub ic on it. I found a cheap one for ~ 1.30 US$. one port of the hub goes to the ecp5, the other to a slower mcu
<electronic_eel>
could be an fx2, but also some other mcu with just fullspeed support or something
<whitequark>
hm
<electronic_eel>
needs to have some usb bootloader of course to make it unbrickable
<whitequark>
how does this make things unbrickable via Ethernet?
<electronic_eel>
you could still do your magic packet trick over ethernet
<electronic_eel>
it would just trigger the mcu
<electronic_eel>
the mcu then resets the fpga and loads some special bitstream
<electronic_eel>
this would mean there wouldn't need to be a libfx3
<whitequark>
I acknowledge that this would work but I'm not convinced it's actually less complex
<whitequark>
cheaper, yes, almost certainly
<electronic_eel>
but rely on luna instead. all work needed to improve luna would go back upstream, instead of invested into reversing cypress docs and workarounding their bugs
<whitequark>
is FX3 buggy?
<electronic_eel>
i don't know. but i'm sure there are some quirks hidden somewhere
<whitequark>
because FX2 has extraordinarily few bugs and I'm really happy with their peripherals
<electronic_eel>
this is usb after all
<whitequark>
this would also mean every single time you build a bitstream you have to build the entirety of LUNA
<whitequark>
which impacts your Fmax and takes up LUTs in an already small FPGA
<whitequark>
that's another significant reason I go with FXn
<electronic_eel>
true, it would take up space on the fpga
<whitequark>
space, clocking resources, and so on
<whitequark>
FOSS tools are good but if you use SERDES they are very finicky still
<electronic_eel>
yeah, also probably serdes lines
<whitequark>
also that
<whitequark>
makes it harder to eg interpose PCIe
<electronic_eel>
another way to do it would be to use 2 ecp5, one dedicated to usb, the other for applets
<whitequark>
yes
<whitequark>
that would be... basically equivalent to the FX3 plan in terms of reliability and board level complexity
<electronic_eel>
don't know how large an ecp5 would have to be to have enough space for luna
<hl>
I will randomly note you could use a USB2 hub IC and USB2 FS MCU AFAIK, no need for a USB3 hub IC I think (it's common for the USB2 fallback lines in a USB3 port to be routed indirectly through a hub even though the USB3 lines aren't)
<whitequark>
I like it a lot more, relatively speaking, than the plan with the hub and HS MCU
<whitequark>
but software/firmware-wise I expect it to have a lot more bugs than using an FX3, and the cost of ECP5-5G is *very* high
<whitequark>
you're basically looking at the same cost as FX3 unless you go for the 25F variant
<whitequark>
same or higher
<hl>
honestly it feels to me like it would make more sense to go with the FX3 for at least one revision and then decide whether there are compelling reasons to move beyond it, because on balance it seems like the FX3 is likely to be a lot less trouble
<whitequark>
^ this summarizes my thoughts
<electronic_eel>
hl: you mean just have a usb 2.0 hub, one downstream goes to the small mcu, the other downstream to a ulpi phy on the ecp5, and the ss lines directly, without hub to the ecp5? doesn't that confuse the host?
<whitequark>
I like the fx3 and I think the obstacle of having an fx3 BSP done is insignificant
<whitequark>
we would need to run a 32-bit CPU somewhere in there anyway for smoltcp
<hl>
electronic_eel: I believe that is valid but don't quote me on that
<whitequark>
I'd much rather go with the dated ARM9 in FX3 than to build a fairly sizable SoC in an ECP5 ourselves, with 5G SERDES to boot
<whitequark>
I want to build debug tools, not to debug my tools
<electronic_eel>
hl: interesting. this would have to be verified against all major os host stacks though...
<whitequark>
er, youcan't do what hl suggests
<whitequark>
what happens when you plug revE into a 2.0 only host?
<whitequark>
(yet another thing FX3 handles nicely)
<whitequark>
er, sorry, i misread
<whitequark>
nevermind what i said
<hl>
electronic_eel: as far as I'm aware this is a very common configuration on host motherboards: USB HCI chip has SS lines connected directly to SS ports; HS lines connected to hubs which are connected to those same SS ports (and some USB2 ports); USB3 was designed to be flexible in this regard
<hl>
electronic_eel: not heard of it being done on the design side, but in principle...
<hl>
*device side
<hl>
whitequark: how does USB2 get disabled on USB3 devices? Is it the device's (and not the host's) responsibility to just turn off D+/D-?
<electronic_eel>
hl: ok, didn't know that this was common. I thought you'd have to keep the d+/d- together with the ss lines
<whitequark>
hl: good question, iirc it's on the device but don't quote me on it
<hl>
whitequark: that's what I'd guess, since the hub flexibility above means it would be hard to reliably correlate USB2 and USB3 interfaces cohabiting a physical connector.
<hl>
(if this is true, it means if a USB3 device neglects to do this, it would appear as two devices... heh)
<electronic_eel>
hl: on the other hand, the usb 3 hubs aren't that much cheaper than usb 2 ones, the 2.0 ones are like 0.60 US$, the 3ers are 1.30$
<hl>
ah
<electronic_eel>
(lcsc prices, genesys logic)
<whitequark>
i care about keeping revE price down much less than i care about keeping revCD price down
<whitequark>
revCD is a device with popular appeal and specifically designed as such. revE is a much more specialist device, so saving ten bucks by not using an FX3 is not something i care about
<whitequark>
especially given, as experience shows, i have significantly underestimated how much people would pay for revCD too
<whitequark>
if there were reports of FX3 having significant bugs i would start seriously looking into alternatives that have fewer bugs
<electronic_eel>
yeah, but we wouldn't want to increase it without reason. so if we need two big fpga with tons of serdes and could just use an fx3 instead...
<whitequark>
the conditions are absurdly hard to hit anyway
<electronic_eel>
i'm not opposed to using the fx3. i just wanted to explore different ways to implement revE and thought the hub solution was a nice way to do it if we don't want an fx3
<hl>
yeah, it's good to brainstorm stuff like this
<whitequark>
gotcha, i misunderstood then
<whitequark>
thanks for looking into alternatives!
<whitequark>
cr1901_modern: i think i'm going to look into the msp430 debugger now
<whitequark>
do you happen to know GDB register names btw?
<whitequark>
*register numbers
sambristow_nz[m] has quit [*.net *.split]
ender| has quit [*.net *.split]
jschievink has quit [*.net *.split]
alanvgreen has quit [*.net *.split]
ktemkin has quit [*.net *.split]
RaYmAn has quit [*.net *.split]
Nephirus has quit [*.net *.split]
yorick has quit [*.net *.split]
TD-Linux has quit [*.net *.split]
Nephirus has joined #glasgow
RaYmAn has joined #glasgow
alanvgreen has joined #glasgow
ktemkin has joined #glasgow
yorick1 has joined #glasgow
ender| has joined #glasgow
TD-Linux has joined #glasgow
sambristow_nz[m] has joined #glasgow
jschievink has joined #glasgow
<cr1901_modern>
whitequark: I don't know the numbers
<cr1901_modern>
Would that info be specific to a gdb server impl or hardcoded into binutils backend?
<d1b2>
<Attie> @whitequark / @hl ... to recap, this is a valid topology? (and it would also be valid to remove USB 2 signals entirely?)
<d1b2>
<Attie> I've wondered about this for years , but never dug into it
<d1b2>
<Attie> ... I sort of presumed that the signals were fairly separate, but didn't know how separate
<whitequark>
attie: USB 3 doesn't have TTs, so a USB 3 hub is basically two hubs inside: LS/FS/HS hub and a separate SS hub
<whitequark>
which also means that if you have a USB 3 hub and you plug USB 2 devices into it, they all share 480 Mbps of bandwidth
<whitequark>
cr1901_modern: hardcoded into binutils
<d1b2>
<Attie> nice, that alighs with my expectations... and SS hub datasheets typically draw them as two blocks, but i'm not sure i'd trust that as "good info"
<d1b2>
<Attie> thanks!
<d1b2>
<Attie> *aligns
<d1b2>
<daveshah> Wasn't there some company doing an unofficial USB 3 TT chip for some particular purpose
<whitequark>
yes
<whitequark>
for VirtualLink
<whitequark>
because they spent the USB 2 diffpairs on 8K DP or something like that
<d1b2>
<DX-MON> there's always got to be one company doing something that explicitly violates and breaks the spec sighs and looks frustrated at VirtualLink
<cr1901_modern>
from pc? Dunno. to pc is how subroutines are impl'd
<cr1901_modern>
>The PC can be addressed with all instructions and addressing modes.
<whitequark>
sweet
<cr1901_modern>
And looks like I got the SR wrong. SR is R2, not R1. I regret the error.
<cr1901_modern>
And TIL you can write to the N, Z, C, V fields of SR. Cool!
yorick1 is now known as yorick
samlittlewood has quit [Ping timeout: 256 seconds]
samlittlewood_ has joined #glasgow
<d1b2>
<esden> That took longer than I expected (as per usual) but now I have a PnP program and can change over the machine... I hope I can at least assemble the backs of the prototypes today.
<whitequark>
esden: so the plan is that you'll assemble revC2s yourself after all, right? (I recall outsourcing was discussed at one point)
<puck>
is there an easy way to debug why the glasgow (revB) jtag probe applet doesn't work with a certain device? or well, i don't have any other jtag-capable devices to test out if it is the glasgow or not