<kristianpaul>
lekernel: the sys_rst signal in mm1 soc, i just one clock cycle pulse right?
<aw>
rc3 good that rendering through night is still working...this C238 i used is 10nF, still seems work ...and the cable is 15 cm long.
<jpbonn>
Does anyone know if flterm works on OSX?  I saw IRC comments indicating it doesn't.
<aw>
just used 2 * 100pF capacitors to close the 220pF we want in the end and clean well, the cable(15 cm) now goes between USB sockets to bottom's R157.
<aw>
let's boot up again to see rendering couple times firstly. ;-)
<aw>
aha~can't boot that is really surprising me. must be somewhere wrong again. :(
<aw>
i hope this is just caused by many times soldering to cause it. :( I don't want to get such surprising things again, no make sense.
<wpwrak_>
aw: how are you cleaning away the flux ?
<aw>
the upper left tools is cleaner I used to, that's very normal in electronic shop.
<aw>
liquid one
<wpwrak_>
okay, looks good
<aw>
btw, can you add a 15 cm with small resistances between R157 and program_b in your simulation tool?
<aw>
said that as 0.1 ohm?
<aw>
and used 200pF for C238?
<aw>
that's currently I have.
<aw>
sorry that the 0.1 ohm between init_b and diode's anode?
<wpwrak_>
a 15 cm transmission line ? :)
<aw>
well...used a 30AWG well so i have no spec about the wire wrapping wire
<wpwrak_>
let's see. usually, transmission lines of that kind just make the simulation slow and fragile
<aw>
must be have an equivalent model for wire: not sure that tool have what to identify like inductive or else
<aw>
yeah
<wolfspraul>
let's try to get the board booting again, or it will quickly end like the rc2...
<wpwrak_>
fragile, because the line could in theory produce enormous bounces. in practice, it's limited by all sorts of parasitic effects. so i had to add a 4 pF cap on R157 to get rid of those superbounces
<wpwrak_>
the transmission line just adds a tiny bit of ripple. too small to show on a scope. the cap causes more confusion :)
<wpwrak_>
adding a 0.1 R instead ... drop should be around 2.4 V. well within the safe zone
<wpwrak_>
wolfspraul: yeah. death by rework sucks. that rc3 board is already above what i'd consider a safe number of reworks in a single area :-(
<wolfspraul>
also I think we are doing an excessive number of reworks, no need at all
<wolfspraul>
we don't have to test 150pf, 200pf, 220pf, 12cm wire, 15 cm wire, 17.5 cm wire, and all combinations of those
<wolfspraul>
I mean we can, but we will just waste time, damage boards, and learn nothing.
<aw>
after reconfiguration , the init_b is 1.4V which is it okay?
<aw>
program_b still 3.3V
<wpwrak_>
if i remember correctly, that looks a bit as if the FPGA was trying to tell us it saw a CRC error. strange voltage, though.
<aw>
i am not trying to do experiments or reworks though.. just want to get all values to be like in the end. surely this period could be damaged by many soldering. :(
<aw>
wpwrak_, hmm..okay.
<aw>
so should be my init_b is not correct.
<wolfspraul>
there was no need to run it on 10nF overnight, imo. but ok, now we did it and now we see whether we can recover :-)
<wolfspraul>
at least the 10nF overnight test showed that.... :-) there is no problem!
<aw>
that 1.4 V surely defenitely stays unknow level to init_b
<wpwrak_>
wolfspraul: i doubt the 10 nF did any damage
<wolfspraul>
another rework, my understanding is that after trying to go back to 200pF now, it won't work anymore
<wolfspraul>
the reason the 10nF overnight test is not worth much, imo, is that whatever the outcome would have been, we woudl still have followed our old plan
<wolfspraul>
if it worked (like it did), we say - OK - let's use 220 pF
<wolfspraul>
and if it would not have worked, after some consideration, we would have decided to ignore the result and still go with 220 pF :-)
<wpwrak_>
wolfspraul: if you have a board you don't like, try driving 2-3 adjacent pins permanently high with maximum drive strength, then short them to ground. let the board burn like this overnight. chances are everything will still work in the morning ;-) (and if i'm wrong, well, you didn't like the board in the first place ;-)
<wolfspraul>
but it doesn't matter now, we got this test result (10nF overnight works), and we move on, back to the actual 220pF plan...
<wpwrak_>
wolfspraul: (10 nF result) yeah, most likely ;-)
<wolfspraul>
it's 50 times above what we believe is a good design, so the value of the test result is very limited already
<wolfspraul>
anyway
<wolfspraul>
hindsight...
<wolfspraul>
let's hope rc3 comes bac
<wolfspraul>
back
<aw>
hmmm..i do nothing on h/w, and reflashing again ....no is boot...
<aw>
rendering....now
<aw>
s/no/now
<aw>
interesting...well....test boot-to-rendering...ten times again...
<wpwrak_>
INIT_B is strange. what's the exact level on PROGRAM_B_2 ?
<aw>
3.3V
<aw>
in rendering mode & after reconfiguration
<aw>
3
<wpwrak_>
*hmm*. doesn't quite make sense, with the information i have. you'd need to compare this with a "known to be good" board.
<aw>
this should ask Lekernel , i quite don't know what actual level init_b from fpga it should be.
<wpwrak_>
you'll get more rc3 board tomorrow, right ?
<aw>
now I have only one board.
<aw>
need to call them again
<aw>
4
<aw>
since yesterday did reworks on their site. second...call now
<aw>
5
<aw>
boards in factory haven't been arranged though hole parts process,
<aw>
said now is bad that friday to go for through hole part works, so I have to go there to bring 1 ~ 2 boards with handly soldering through hole myself.
<wpwrak_>
factories don't seem to like through hole :)
<aw>
well...seems that i have to go there. :( and also bring 220pF back
<aw>
the reworks they said are done.
<aw>
6
<aw>
let's finished 10 times, then I go there. not wait
<wpwrak_>
(go here) probably the best approach. get some more boards, finish the rework, then you can check things with relatively "clean" boards
<wolfspraul>
wpwrak_: do we need to investigate the 1.4V issue further?
<aw>
and keeps rc3 mysite rendering
<aw>
yes
<wpwrak_>
wolfspraul: maybe. at least if it happens on other boards as well. if it's just the rc3 #1, i'd rather forget about it :)
<aw>
the best way now is let Lekernel to measure his rc2 board then we get answer
<aw>
later i bring rc3 boards back then i confirm again.
<wpwrak_>
wolfspraul: or if lekernel has a suitable explanation for the voltage. i all i know about the pin is 2nd hand information from him anyway
<wpwrak_>
hmm, that seems to contradict what lekernel found in the xilinx documentation. well, he can puzzle that one out :)
<aw>
surely now rc3, one diode added.
<aw>
yes, hope he can describe more details.
<aw>
8
<wpwrak_>
but it's reassuring that INIT_B was sort of floating before. so this isn't anything new. even if it seems strange (because INIT_B cannot float :)
<aw>
yes,
<wpwrak_>
this suggests that the weird voltage on INIT_B is not connected to the boot failure you had before.
<aw>
seems that they are not the same story(boot failure) i have.
<aw>
9
<wpwrak_>
that boot failure is a bit unsettling, though. how many times did you try to power cycle before reflashing ?
<wolfspraul>
and where in the boot did it fail? before reconfig? after reconfig?
<aw>
after i cleaned, then I power on, then reconfiguration then boot failure....
<wolfspraul>
so reconfiguration finished, D2 went off, but after pressing the middle button - what happened?
<aw>
which pciture I let rc2 finished configuration mode then I tried to trigger a falling edge (thus power off) to get its level with 3V3 plt.
<aw>
wolfspraul, after pressing middle button, then D2 light then OFF
<aw>
cant keep ON...so no boot up more.
<aw>
then i powered off to measure init_b & program_b to check  then do nothings
<wolfspraul>
I would ignore this for now.
<aw>
so I reflashed s/w again under configuration mode (thus D2 is OFF stage)
<aw>
then after reflashing done. boot status goes back. ;-)
<wolfspraul>
we can look at the 1.4V a little if we want to, but I really think we need to focus on the one design we believe is good now, and produce boards with the least amount of reworks
<wolfspraul>
sure, understand
<aw>
do nothing...
<wolfspraul>
for a user that would be fatal, because he cannot easily access jtag
<aw>
yeah
<wolfspraul>
but again - we need to be careful to not go in circles
<aw>
yes i know
<wolfspraul>
enough circling now, let's assume our design and ideas are correct, and move forward
<wolfspraul>
if we find suspicious things during testing, we have time to think more
<wolfspraul>
that's a bit risky, but everything is risky and we need to take risks
<wolfspraul>
so I'm not worried about the risks. going in circle forever is also a risk :-)
<wolfspraul>
death risk
<aw>
after bought cleaner liquid just wanted to back to fix2 circuit ten just discovered this failure.
<aw>
s/ten/then
<wolfspraul>
yes, read what I say about circling. enough circles now. forward.
<wolfspraul>
if someone wants to look into 1.4V, fine
<wolfspraul>
but let's focus on the way forward now, we take the risk that there are more mysteries
<wpwrak_>
maybe the cleaner just wasn't entirely dry yet ;-)
<wolfspraul>
that's the price we pay when we mix production and design
<aw>
NO
<aw>
wpwrak_, NO
<wpwrak_>
;-)))
<wolfspraul>
aw: you are right - please watch any more incorrect behavior, and report it. even if you see something only once.
<aw>
i am very carefully on dry clean thing...i let it dried by blow by fan
<wolfspraul>
because our users will not be able to reflash with jtag...
<wolfspraul>
so the report is good, but it's only 1 data point now - too little to be worth further investigation
<wolfspraul>
aw: you pickup some more rc3 boards now? are they fully soldered?
<wpwrak_>
wolfspraul: would also be good to try to recover with conventional means after a supposed flash corruption. there may be failure patterns that aren't easily reproduced.
<aw>
all today;s happened is becuase I knew i'll use 1 new 15 cm cable and goes back to use 2* 100pF capacitors so I am very serious to settle them down then try to test 10 times then go to assemble it with my case. ;-)
<wolfspraul>
get the 220pf from the factory, and start using that, and no more other caps :-)
<aw>
wolfspraul, now i can go there. ;-)
<aw>
10
<wolfspraul>
we focus on the production now, enough design
<aw>
yeah
<wpwrak_>
yeah, it's good to test things step by step. makes it easier to tell where things went wrong if you're at step #100 and it doesn't work ;-)
<aw>
yes...thank you guys.
<aw>
keep rendering...
<wolfspraul>
plus we need to move forward in boards, not get stuck. we will just make more and more discoveries like the bad probe...
<wpwrak_>
ah, so the zero is just well below the screen. okay.
<aw>
sorry that CH1 - 3V3, CH2 - init_b
<wpwrak_>
aha !
<wolfspraul>
aw: you pickup more rc3 boards?
<aw>
man..i always typed too fast. :(
<wolfspraul>
how many? fully soldered?
<wpwrak_>
so INIT_B is 2.2 V. interesting.
<aw>
wolfspraul, only one
<aw>
factory now all SMD parts assembled and rework done but haven't go through through hole reflow machine
<wolfspraul>
so you do throw-hole on that board yourself?
<wolfspraul>
through-hole
<aw>
so now I go there to bring 2 boards back then solder my self on through hole parts. ;-)
<aw>
yeah...time to go
<aw>
seems they are ignore us doing other customers. bad~ :(
<wolfspraul>
start to kick them, it's normal
<wolfspraul>
I'm not worried
<wolfspraul>
if you get another board or two, we can use the time very well for more testing
<aw>
wpwrak_, 2.2V - 0.8V = 1.4VÂ Â ;-) it real interesting...the drops must be the diode Vf. although it's not precisely. ;-)
<aw>
cu
<wpwrak_>
or speand a day to learn qucs ;-)
<wpwrak_>
nice theory, but the diode's Vf should be around 0.4-0.5 V ;-)
<wpwrak_>
(and if it's 0.5 V, it should be quite hot, burning something like >= 0.5 W ;-) actually, 0.3-0.5 V.
<GitHub57>
[extras-m1] shiyele pushed 1 new commit to master: http://bit.ly/o0a5bo
<GitHub57>
[extras-m1/master] updated leaflet panels, logo - Wolfgang Spraul
<lekernel>
jpbonn, flterm doesn't work on OSX because of Apple's crappy poll() implementation which doesn't work with devices
<wolfspraul>
lekernel: I updated the leaflet a little, you can check if you like. just the panels and logo
<lekernel>
jpbonn, you can use the old select()
<wolfspraul>
I'm having some trouble with the brochure, first Scribus complained about a number of Pakistani and Thai fonts missing. After I installed them the warnings went away but the fonts are quite wrong
<wolfspraul>
are you using those Pakistani and Thai fonts? one quick solution is to just ignore my problems and you upload a 300dpi version of the latest brochure (right now there's only a 100dpi version)
<wolfspraul>
or we find out why I can't open the file in scribus, which is probably better if there are printing problems.
<wolfspraul>
if you make a pdf, export all characters to outlines, no embedded fonts at all. that's probably better.
<lekernel>
wolfspraul, those fonts have some "pakistani" in their name, yes
<lekernel>
also the colors do not look right on your pdf export
<wolfspraul>
look at my brochure.pdf, that's what it looks like when I open the file in Scribus
<wolfspraul>
even though I installed all missing fonts
<wolfspraul>
is that something worrisome or in needs of investigation?
<wolfspraul>
cool, thanks! I will still try to get it to work with my Scribus, but that's a fallback
<lekernel>
no, let's see how it goes on the other boards
<wolfspraul>
k
<aw>
brought back 2pcs * rc3, need soldering through hole parts now.
<wolfspraul>
nice
<aw>
but bad is i saw their through hole reflow line is busy on IPC products. :( painful
<wolfspraul>
don't worry:
<wolfspraul>
a) we cannot change it
<wolfspraul>
b) we cannot reasonably expect them to treat a 2000-3000 USD customer with high priority
<wolfspraul>
c) we have good uses for the few days of delay, and eventually they will do good on their delivery
<wolfspraul>
true?
<wolfspraul>
they even 'owe us' a bit now because we let them satisfy some urgent 'VIP' customers first :-)
<aw>
surely true...trust is trust...well I cant change them. :(
<wolfspraul>
I think it's ok, really. I can only expect reasonable things.
<wolfspraul>
the world will not stop to finish the Milkymist One RC3 run
<wolfspraul>
so...
<wolfspraul>
let's make good use of the time
<aw>
let's make tests on those two I brought tonight.
<wolfspraul>
yes
<wolfspraul>
maybe more surprises await us :-)
<aw>
while soldering I saw couples seconds freeze on one of patch, then rendering again. is it normal? Do I need to know which one it is? or forget it.
<aw>
i keep soldering...
<wolfspraul>
yes I've seen such short freezes too sometimes
<aw>
hmm...good
<aw>
i am not alone. i forget it now.
<wolfspraul>
I think no big deal right now, but keep an eye on it. it's exactly right: watch the product like a user would. So 'freeze', short or long, is not right.
<aw>
yeah~ok
<errordeveloper_>
lekernel: so ..hm, if you had a mega-huge fpga, would you use opensparc ?
<errordeveloper_>
some imaginary huge and cheap one :)
<wolfspraul>
errordeveloper_: let me answer too (even though I barely can read Verilog): no, I would not
<wolfspraul>
but I was at the exact same point of thinking maybe 2-3 years ago, so I can totally understand
<wolfspraul>
the question is: what do you want to do with the result you are building?
<wolfspraul>
HDL sources are not as easily portable or reusable as a C library, that's one thing to keep in mind
<wolfspraul>
you really have to define your goal first, then pick the tools
<wolfspraul>
opensparc being big means it's hard to modify/improve
<lekernel>
HDL sources aren't too hard to port, but the point is simply that huge and fast FPGAs are expensive
<wolfspraul>
I looked at opensparc for a while before I found Milkymist, and concluded there is not much one can realistically do with it.
<wolfspraul>
of course you tell me I'm wrong, and make it part of Milkymist :-)
<wolfspraul>
I'm sold on Milkymist now :-)
<lekernel>
and if by some magic I'd had a cheap one, I'd still use one or many LM32's to make an even faster SoC :)
<wolfspraul>
yep
<errordeveloper_>
ok
<errordeveloper_>
I got more questions, but need to read the paper in full :)
<GitHub171>
[extras-m1] shiyele pushed 1 new commit to master: http://bit.ly/nDdV03
<GitHub171>
[extras-m1/master] added milkymist-sticker using new logo - Wolfgang Spraul
<aw>
finished two rc3 through hole part soldering but not fix2 patches...keeping.
<errordeveloper_>
which header should I better stick it into
<errordeveloper_>
?
<errordeveloper_>
include/config.h.in ?
<errordeveloper_>
or add something like include/incompat.h.in or similar ?
<errordeveloper_>
basically the issue is that on getline() is fgetln() on bsd
<wpwrak_>
they should work the name a little more. it's already impressively close to "fhtagn", though
<errordeveloper_>
damn, in fact getline and fgetln work very differently ;(
<aw>
pheu~the clean job is tough more than if I solder a small board. ;-)
<aw>
realized that why they use a auto grinder with hairbrush machine to clean!
<wpwrak_>
aw: for small boards, ultrasound cleaning is also a nice option. but of course, M1 is too big for that ... (well, for the cheap ultrasound cleaners)
<errordeveloper_>
well, by chance I found a fix which is somewhat hosted on qi-hw.com:
<aw>
what does mean "Unknown stepping! (0011) (/usr/local/share/urjtag/xilinx/xc6slx45/STEPPINGS)" ?
<wolfspraul>
seems a newer fpga, we can probably just add that stepping
<wolfspraul>
aw: this doesn't look like it flashed anything, right?
<wolfspraul>
lekernel: what do you propose for stepping 0011 ?
<lekernel>
just add the stepping in the urjtag database
<lekernel>
send the patch to the urjtag mailing list
<wolfspraul>
aw: I would just try to edit the STEPPINGS file, and add a line to it :-) 0011 xc6slx45 3 (not sure what this '1' '2' means, but maybe just make it '3')
<lekernel>
yes do that
<lekernel>
and send the diff to urjtag
<aw>
wait...a moment . i quite don't know  what you said. let me paste reflash_m1.sh. ;-)
<lekernel>
I hope this stepping does not introduce new silicon bugs
<wolfspraul>
no, not reflash_m1.sh
<wolfspraul>
you neet to edit /usr/local/share/urjtag/xilinx/xc6slx45/STEPPINGS
<wolfspraul>
it's a text file
<aw>
alright...
<aw>
wait
<wolfspraul>
add a third line to it: "0011<tab>xc6slx45<tab>3"
<wolfspraul>
of course instead of <tab> you press the <tab> key...
<wolfspraul>
then we try again, and if we are lucky it will flash
<wolfspraul>
and if we are even more lucky, it will boot
<wolfspraul>
yeah the 0.7A doesn't look so good, oh well.
<wolfspraul>
lekernel: so let's hope they have their regression management under control... :-)
<aw>
0x30...great....reflashing...
<lekernel>
have you reworked those two boards for the reset problem already?
<wolfspraul>
I'm sure he did
<aw>
temporarily forget 0x31 now. ;-) I'll need do self hard quality check my self though. ;-)
<aw>
lekernel, yes, 0x30 and 0x31 with fix2 patches.
<wolfspraul>
lekernel: now he will try to bring them up, but 0x31 already shows a suspiciously high current 0.7A. so he will do 0x30 first.
<aw>
reflashed done
<aw>
boot....
<aw>
cause I knew m1 without s/w, it only surge under 0.6A. so I set my lab power supply at 0.7A limited
<wolfspraul>
oh, then 0x31 may have a really big problem
<aw>
I'll take an eye on surface check again. ;-)
<aw>
rendering...
<wolfspraul>
aw: did you run the test software on 0x30 yet?
<aw>
not yet...
<aw>
now power off to connect all.
<wolfspraul>
ok yes, let's run the whole test thing first
<lekernel>
errordeveloper_, not off the top of my head
<aw>
seems not that same before.. wait a bit..i saw the soldering pretty good. ;-)
<lekernel>
also, you should expect issues more serious than that if you want to do anything with llhdl today
<errordeveloper_>
lekernel: I would imagine :|)
<errordeveloper_>
well .. parsers had been one thing I wanted to learn for a while
<wolfspraul>
lekernel: with the .ttf files you sent me my Scribus now crashes when opening the .sla :-) I will put this aside and use the PDF you made for now...
<kristianpaul>
just for curiosity try to compile llhdl in his mipsel laptop again..
<aw>
aha...i saw that D4's negative is poor soldering. good! got you.
<aw>
second...
<wolfspraul>
I want my own AOI :-) wpwrak_ - you need to write a tool that we can feed some random jpegs, taken from any cheap cellphone cam, in any angle, any lighting condition, and it will magically point out all the things it sees wrong!
<aw>
this boot.bin is newest one from xiangfu
<aw>
wolfspraul, this time I bought a microscope, so I may take a lot such "surprising".
<aw>
so later let's compare 0x30's init_b's voltage. shall we? I'd like to. ;-)
<GitHub92>
[scripts] sbourdeauducq pushed 1 new commit to master: http://bit.ly/re9OZK
<wolfspraul>
and of course we first need to confirm that MIDI now works, but it should... (as with rc2, please record all test logs, not just the final one that passes)
<aw>
okay
<wolfspraul>
lost connection
<aw>
hmm...after soldered D4, still fail...interesting.
<kristianpaul>
bah, cmake sucks..
<wolfspraul>
aw: measure signals?
<aw>
measure R54~R57 is correct. forwarding voltage is 536mV.
<wolfspraul>
(or - it's late - maybe continue tomorrow?)
<aw>
yeah...but let me try last one..since the midi connection were soldered by me ...ha ;-)
<wolfspraul>
what will you do?
<aw>
well...(late)..;-) let's do tomorrow. checked U6's body is the same 0x2F's one.
<aw>
report tomorrow morning...pheu...
<aw>
oah~ wiat
<aw>
maesure init_b .;-)
<wolfspraul>
ok, so we stop today with this status: 0x30 = midi, 0x31 = 0.7A. correct?
<aw>
yes
<aw>
0x30, after configuration and boot @1.3V rough
<wolfspraul>
not surprising, but it seems we don't think this is significant or worth further investigation
<wolfspraul>
that's my understanding at least
<aw>
yes...no need to do more about this.
<wolfspraul>
alright, so tomorrow midi & 0.7A :-)
<aw>
tonight use 0x30 overnight
<wolfspraul>
ah good idea, yes
<roh>
sigh
<aw>
cu everyone.
<wolfspraul>
cu
<roh>
glued 20 buttons now.
<aw>
roh, nice
<roh>
well.. half of them.. the 3mm part iss still missing (waiting for the laserstuff to return)
<roh>
that chemical (solvent) is sick to work with
<aw>
;-)
<wolfspraul>
why?
<wolfspraul>
what happens?
<roh>
its extremely time consuming
<roh>
i need to glue them one by one. the stuff vapourizes too fast to do more buttons in a row
<wolfspraul>
for the future - if there is thicker acrylic, is it possible to laser the buttons out of the acrylic in one piece?
<roh>
also i need to prepare them by peeling off the tape etc
<wolfspraul>
yes, that's nasty. I hope you have a tweezer.
<wolfspraul>
these things are small and hard to handle
<wolfspraul>
maybe you need to pin them down somehow, well, you will know best
<roh>
wolfspraul: then i need to make the buttons from another sheet. sure its possible somehow, but that again adds complexity to the process
<wolfspraul>
the laser shop will deliver the lasered parts tomorrow?
<roh>
sure.. i am working with tweezers. will not touch the stuff with hands.. i use 2 gloves per hand and tools, and also enable the exhaust air system
<roh>
not sure. i hope so
<roh>
but at the current speed i dont know how long i will need to glue the buttons yet anyhow
<aw>
wow..gloves
<roh>
and goggles
<roh>
and these arent even the right ones. the gloves i should use cost 100E a pair