<kristianpaul>
lekernel: mm1 bios is aware of endianess aligment right?
<aw>
morning ;-)
<kristianpaul>
hey there
<aw>
rc3 keeps rendering until this morning 9:00, so totally is 8 hours passed. ;-) It's stop once my laptop's usb is ON. (this sounds a bug still there heard before though)
<aw>
if I am wrong, correct me. ;-)
<kristianpaul>
ah,you mean you let the jtag cable connected to your laptop, and once the laptop turned on, the  m1 it..
<kristianpaul>
but stop mean no crash? just render stop?
<aw>
kristianpaul, yes, just rendering stop. is it to be acted that?
<aw>
if I remembered correctly, Jon had have this discovery before. Hope i am not the first one. ;-)
<kristianpaul>
dunno, sorry had not test m1 in redering too much in my side, but my seems a easy bug to be solve later
<kristianpaul>
ah,well. so you not alone, thats good
<aw>
kristianpaul, no problem. I wrote firstly, later may get an answer. ;-)
<kristianpaul>
but is good read from you the 8 hrs render went okay
<aw>
yes, i am going to keep do test of boot-to-rendering for 70 times. Before this I need to discuss with factory. ;-)
<aw>
xiangfu, morning, i have a question.
<xiangfu>
aw, morning
<aw>
have you known that rendering will be stop if my jtag cable connected to my laptop then once I turn on laptop?
<aw>
is it a well-known bug already?
<xiangfu>
aw, hmm.. it is not recommand do that. you better connect hose table when m1 shutdown.
<kristianpaul>
hahah
<kristianpaul>
is that a yes? :)
<xiangfu>
it's not design that connect while poweron. so the error is random
<kristianpaul>
oh
<xiangfu>
yes. :)
<aw>
what's "hose table"?
<xiangfu>
I connect them while m1 poweron. make m1 freeze.
<xiangfu>
s/hose/this
<xiangfu>
aw, this cable , I mean
<aw>
xiangfu, hmm..so this is well-known for few people already?
<kristianpaul>
i must said i was unknow of this, well, may be because rarelly i connect m1 to laptop
<xiangfu>
aw, we can write down this message to jtag board wiki page. no needs to create a issue I think. it's not a bug, it just not design to do that.
<aw>
kristianpaul, yes, me either.
<xiangfu>
aw, write down to wiki page, with highlight.
<aw>
xiangfu, i see.
<kristianpaul>
so the theory is that mm1 serial port if perturbed with ramdom data, bad thing happens? or may be jtag as well?.. well could make sense..
<kristianpaul>
well, gpsd is not crap, but make sense now
<aw>
hi NO, my status is not you met before. ;-) I didn't plug or replug my jtag board.
<xiangfu>
aw, you are doing that while m1 poweron right? that kind of same :)
<aw>
my condition was: 1. m1's jtag board connected to my  laptop and let m1 to keep rendering 2. then i turned off my laptop. 3, I turn on my laptop again then m1 stops rendering.
<aw>
so you meant my case is the same behavior as you just posted that irc link?
<xiangfu>
I think it's kind of same. it only stop rendering not freeze?
<aw>
yes, just stop rendering, but I forgot to check if freeze, then I power off m1. ;-)
<xiangfu>
I think we don't need look into detail. just do not connect  JTAG while m1 poweron. and do not reboot your pc while connect a poweron m1 :)
<kristianpaul>
but power on/off laptop do same with jtag pod, and at the end generated magic garbage ;)
<xiangfu>
yes.
<aw>
xiangfu, hi sorry , i correct my last sentences: screen freeze! not stop rendering.
<aw>
hmm..got it. stop looking at this.
<xiangfu>
yes. just as kristianpaul said. "at the end generated magic garbage ;)"
<aw>
okay..confused you..done. ;-)
<kristianpaul>
also i think altought jtag pod is included with mm1, is not acesible easilly, so this is not going to happen at all
<aw>
only can accept a rework with easy adding parts, changing parts or taking apart in solder paste existed. thus R60(remove), R30(change), R157(change), C238(add)
<kristianpaul>
yeah, less troubles, imagine just trouhwing that wire from one side to the board to another ;)
<kristianpaul>
well for they..
<kristianpaul>
btw, you have pics from the rework in both rc2 and rc3 boards?
<aw>
will be noticed soon if factory wants to do easy jobs after evaluating current internal loads.
<kristianpaul>
larsc: new lm32 branch, nice !!
<aw>
kristianpaul, second. I'll take pictures and give another fix2 with parts reference. before this , i need to finish some else and remaining 70 times tests.
<kristianpaul>
ah, yes i forgot 70 times tests..
<larsc>
kristianpaul: hm, that was not on prpose
<larsc>
now it's correct
<kristianpaul>
ah
<kristianpaul>
larsc: so, what is you plan?
<larsc>
world domination ;)
<larsc>
kristianpaul: my plan regarding to what?
<kristianpaul>
larsc: he,to the branch you created on tmatsuya/linux repo
<kristianpaul>
ahh, was deleted..
<kristianpaul>
okay nothing else to ask you then :)
<larsc>
i wanted to push to master, just forgot to mention it on the cmdline
<aw>
rc3 power up -> boot -> rendering 15 secs -> power off: 35 times
<kristianpaul>
btw, now i can ask you quickly, there is a place in wich i can find a uclinux updated with all the patches you and mwalle were working on?
<larsc>
kristianpaul: mwalle's patches are in the milkymist wiki
<kristianpaul>
larsc: but those patches are agains wich linux repo?
<kristianpaul>
also do i need mwalle ulibc isnt?
<kristianpaul>
sorry, i never compiled or ran linux on mm1, just asking to be aware  of current status
<larsc>
all the linux patches are in the repo at github
<larsc>
if you want to build your own userland you'll need mwalles uclibc patches
<kristianpaul>
you mean, are already aplied in repo at github?
<aw>
40 times
<kristianpaul>
ah, okay just uclibc patches, not linux specific patches, i think i undertand that
<aw>
45 times
<wpwrak_>
(jtag while laptop power on) probably it froze. in my experience, the ft2232 likes to act up. not much you can do.
<wpwrak_>
(aw) the scope traces would be useful to have. we'll need them to confirm the value of C238.
<aw>
wpwrak_, yes, i think so.
<aw>
50 times
<aw>
wpwrak_, so program_b vs RP#, and program_b vs init_b, two scopes, else?
<wpwrak_>
aw: the test would be: connect scope (probes set ti 1:10) to TP36 (PROGRAM_B_2) and TP37 (FLASH_RESET_N). set to 100 ns/div, falling edge trigger on FLASH_RESET_N, trigger level ~1.65 V.
<aw>
so my prober get touched again with program_b , not sure this influence to add more equivalent capacitors on C238.
<wpwrak_>
aw: then power up. wait until FLASH_RESET_N is at ~3.3 V. then touch FLASH_RESET_N with a resistor 47-100 Ohm to ground. that will pull FLASH_RESET_N down.
<wpwrak_>
aw: of course it will change the capacitance a little :)
<aw>
alright, yesterday i tired to use 1:10 to get but not success, I'll try.
<wpwrak_>
aw: i just need to know how much contamination is there from FLASH_RESET_N to PROGRAM_B_2. i can then make an estimate of how much it would be without the scope.
<aw>
um..yes, then you know the difference it is.
<aw>
got it.
<aw>
s/tired/tried
<aw>
wpwrak_, this means if C238 value changed, i should do 100 times again I think, no need?
<aw>
55 times
<wpwrak_>
i think we'd need to do more testing if we have to change C238, because it could cause other, yet unknown problems
<aw>
so i think that maybe i just stop tests? and probe first to you?
<wpwrak_>
i.e., there's a lower and an upper bound for C238. so far, we're mainly looking for the lower bound.
<aw>
yeah
<wpwrak_>
it may make sense to change C238 to, say, 1 nF or such at some point in time, to see if we're well clear of any upper bound. but let's first confirm the lower bound.
<wpwrak_>
(tests vs. scope) dunno. you're almost finished with the tests anyway :)
<aw>
well...so now i think i stop tests, seems this not make sense to keep tests.
<wpwrak_>
hehe. they're boring anyway ;-)
<aw>
at least I have 55 times already as a base. i stop. the design for checking lower bound is much than collecting an unknown data.
<aw>
waht time it is your side?
<wpwrak_>
about 00:37 (am)
<aw>
man...
<aw>
give me 10 ~ 20 minutes.
<wpwrak_>
just had a nap after dinner :)
<aw>
if u feel asleep, go ahead . I'll upload though. ;-)
<wpwrak_>
yeah, i'll be up for a little while. but not the whole night :)
<wpwrak_>
well, maybe, but not online. busy reading a book :)
<kristianpaul>
you need buy ebooks more often :)
<wpwrak_>
kristianpaul: i actually have found an electronic copy :) but it's still much nicer to read on paper
<kristianpaul>
paper is nice i must confess i still printing stuff to read later, also using it right now to take notes,may be epaper will change this, but not for  me soon
<aw>
wpwrak_, now m1 is sitting in standby mode (thus the stage after reconfiguration) to ready capture falling edge.
<aw>
wpwrak_, i remembered those two test points are normal high
<wpwrak_>
aw: they should be, yes
<wpwrak_>
after you pull FLASH_RESET_N towards ground, the M1 will be in an unknown state. maybe it'll crash/freeze. i don
<wpwrak_>
't know it well enough to predict.
<aw>
wpwrak_, the falling edge is captured @2.5 ms/div not 100 ns/div, be noticed
<aw>
is this that your supposedly thoughts? hmm..let me confirmed: two probers set X1, oscilliscope also set X1
<wpwrak_>
that seems too slow. the contamination should recover within a few us
<wpwrak_>
probes set to X10
<aw>
if I set my probers at X10, I can't trigger and capture.
<aw>
set again.
<wpwrak_>
eh ? why can't you trigger with X10 ? is the scope broken ? scope should be set to X10 too, of course
<aw>
yeah..checking
<wpwrak_>
i think you also need to set the trigger after changing X1 -> X10. it may become 16.5 V or such after the change, not 1.65 V
<kristianpaul>
yes, well, with the scope i have here is that way wpwrak_ points
<roh>
morning
<kristianpaul>
early morning roh
<roh>
wtf? your scopes dont calculate the displayed trigger themselves?
<kristianpaul>
yes, but that s tricky
<kristianpaul>
for this situation, at leat
<roh>
no. the scope either knows (by contacts on the probe plug) which mode you set (x1/x10) or probe you use. so it can just display it correctly.
<aw>
hey..sorry that I got it. ;-)
<roh>
if it doesnt know it, you can set it in the input section of the scope usually
<aw>
confused you again. ;-)
<wpwrak_>
kristianpaul: (scope) you mean that the trigger changes when you change X1 <-> X10 ?
<kristianpaul>
ah, well, one i have dont, i have to set mode manually
<kristianpaul>
no i dont wpwrak_
<kristianpaul>
manual
<kristianpaul>
s/i/it
<kristianpaul>
i remenber
<aw>
wpwrak_, but 10 ms/div got it
<wpwrak_>
roh: they do. but they may not adjust it when you change the probe. so your previous x V may become 10x V, or 0.1x V. but when you set to 1.65 V again, it'll be 1.65 V
<wpwrak_>
aw: 10 ms/div is meaningless ;-)
<roh>
wpwrak_: thats why you need to tell your scope which probe you use (if it cant detect it)
<wpwrak_>
aw: maybe you have too much filtering on the trigger
<wpwrak_>
roh: correct :)
<roh>
maybe there is some 'denoise' or 'low pass' enabled on the input
<wpwrak_>
roh: adam has his probes set to X1. i have no idea why ;-) i'm telling him that this measurement is better done with X10. that's all
<aw>
wpwrak_, no, I scales both channel again, also my two probers are set @ X10 now. ;-)
<roh>
yeah. else they will influence the measured device much more
<wpwrak_>
roh: (mess up the measurement) yup
<wpwrak_>
aw: your scope shouldn't have any problem at all capturing this at 100 ns/div. i have a TDS1002. it has even less trigger problems than the rigol i normally use ;-)
<kristianpaul>
aw: are you sampling at full sampling rate?
<kristianpaul>
i had problems with triggering because of that sometimes..
<aw>
moments. let me upload picture firstly
<wpwrak_>
kristianpaul: i'm not sure if the trigger should even depend on the sampling rate ...
<kristianpaul>
yeah, neither me, but is what i tell from my short scope oepration experience
<kristianpaul>
at least if you want a correct visualization i think
<kristianpaul>
but i may wrong
<wpwrak_>
kristianpaul: is your acquisition set to "normal" or "peak" ?
<kristianpaul>
usually normal, but i dint noticed any different with peak to be honest
<kristianpaul>
not yet, i havent catched pesly signals a Adam now :)
<aw>
wpwrak_, i set 'Normal', the duration of falling is longer that you expected. ;-)
<aw>
keep calm a bit...the sharp curve is done by reset iC
<wpwrak_>
the FLASH_RESET_N you touch with 47-100 Ohm should drop sharply
<aw>
let's check its reset IC's behaviour, then you won't be surprised at all.
<wpwrak_>
ah, wait ... how did you trigger all this ?
<wpwrak_>
you have to have the M1 powered up, then force FLASH_RESET_N down
<wpwrak_>
since i don't know how to do this via software and lekernel isn't around, i suggest to use a 47-100 Ohm resistor connected to ground
<aw>
hmm...you wanted me to manually pull low with touching with 47 - 100 Ohm???
<wpwrak_>
if you don't have one, a direct connection to ground would do as well. but via a resistor is a little safer
<wpwrak_>
yup :)
<aw>
hmm..i see now.
<aw>
but can you realize what i said that FLASH_RESET_N normal behavior though. ;-)
<wpwrak_>
you can set the trigger to "SINGLE". the M1 may reset or do other weird things afterwards, so it may trigger again. but that would all be meaningless.
<aw>
well...i need to find a 100 O ohm now. :(
<aw>
yes, i used "SINGLE".
<wpwrak_>
(normal behaviour) hmm. not quite sure what this actually shows ;-)
<wpwrak_>
i see that the two are about 200 mV apart. so the diode's Vf isn't too bad. good to known.
<aw>
yes, the diode's low is good though
<wpwrak_>
yup. diode works as a diode should :)
<kristianpaul>
detectflash 0 in urjtag may be a software alternative, but i dont think it will pull down that flash reset signal for ever
<wpwrak_>
you have a little glitch on FLASH_RESET_N. cute :) doesn't matter here, though.
<wpwrak_>
if you set acquisition to "Peak Detect" (instead of "Sample"), you'd see those glitches more clearly
<wpwrak_>
the TDS1xxx series has very good peak detect. it's worth using it. on my rigol, it's much less useful. but then, it has about 400-800 times the memory :)
<aw>
page 10 of reset ic shows when our 3V3 reachs "Release Voltage" so that we can realize this normal falling edge it is. ;-)
<wpwrak_>
aw: i mean the glitch around -8.0 ms, on CH2
<aw>
and the slow slope may somewhere discharges.
<kristianpaul>
ok, so whare are you going to measure init_b ?? or is not needed anymore?
<wpwrak_>
the glitch may actually exist on both channels. we just don't see it on CH1 due to the slow setting and not using peak detect
<kristianpaul>
s/wahre/when
<wpwrak_>
kristianpaul: we're after FLASH_RESET_N -> PROGRAM_B_2 contamination
<wpwrak_>
kristianpaul: INIT_B is still used, but not nearly as critical as PROGRAM_B_2
<kristianpaul>
ah, okay, i tought PROGRAM_B_2 wasnt aware of contamination, yes thats important
<wpwrak_>
kristianpaul: anything that would be even a small problem on INIT_B would be apocalyptic on PROGRAM_B_2 ;-)
<aw>
our reset ic's Release Voltage is rough at 2.63V which we can see that waveform acts alike.
<kristianpaul>
ok
<wpwrak_>
aw: (reset ic) thinking of it, it seems a little strange that it doesn't pull more. but then, i don't quite know what your setting was.
<aw>
i set ACQUIRE at "Sample" not "Peak Detect", you wanted me set to "Peak Detect" again?
<wpwrak_>
aw: ah yes, you may want to set the scope to "peak detect" in general. it helps to find things :) and you don't seem to have much trouble with interference, so it won't add much noise
<aw>
capture again now.wait...
<aw>
to see if difference there. ;-)
<wpwrak_>
aw: "peak detect" should work very well on your scope. and, given that you have almost no memory, it helps a lot with finding glitches and such
<wpwrak_>
kristianpaul: i think yours has a bit more memory, but also not a lot (maybe 10x). so you may want to experiment with "peak detect", too
<wpwrak_>
aw: the difference should be quite significant ;-)
<aw>
no, seems it's not. wait..uploading
<kristianpaul>
is same?
<wpwrak_>
kristianpaul: can't be :) unless he's not doing what i have in mind
<kristianpaul>
aw: your scope have a single freq button or mode ?
<aw>
Peak Detect this time. ;-) without manually touching 100 ohm.
<wpwrak_>
aw: ;-) peak detect is nice. now we know that the glitch doesn't go deep
<kristianpaul>
i had similar experience when testing that peak mode on the scope i have..
<wpwrak_>
aw: BUT .. what the heck is this showing ? ;-)
<wpwrak_>
aw: what you should do is this:
<aw>
wpwrak_, go on: listening...
<wpwrak_>
1) power the M1 up. let it boot, etc. until it's stable
<wpwrak_>
2) then arm your scope
<aw>
hmm..i didn't let it boot
<wpwrak_>
3) then pull FLASH_RESET_N low
<wpwrak_>
i think you have to let it boot or it will pull FLASH_RESET_N something like 0.5 s after powering up. you could also measure this, but it may be difficult to catch
<aw>
wpwrak_, i quite no sure if I manually pull FLASH_RESET_N low, what will be happened? since I only have rc3 one now...my last rc2 is temporarily sleeps now. ;-)
<wpwrak_>
i don't know what will happen if you manually pull FLASH_RESET_N. the m1 may simply crash/freeze. or maybe it doesn't even notice. doesn't matter. all we need to see is how PROGRAM_B_2 reacts
<aw>
yes,...should be rough 0.2s~0.5s I think thus is reset IC's delay time + else after powering up.
<wpwrak_>
the transition on PROGRAM_B_2 will be short. a few microseconds. and the part that's actually interesting is < 1 us.
<aw>
bad...so now i still can't answer to let you know a lower bound evaluate. :(
<wpwrak_>
(the rest of the PROGRAM_B_2 transition will be C238 charging, which should take about 1-2 us. not very interesting to watch.)
<wpwrak_>
aw: naw, you really need to force FLASH_RESET_N down :)
<wpwrak_>
if you want to, you can also try to find the point where the firmware forces FLASH_RESET_N down. but that's more work.
<wpwrak_>
you would do this with a pulse trigger, maybe < 1 ms. but i don't know the correct value. lekernel would :)
<aw>
good reminder
<aw>
seems gui have an icon can let it reboot which may let FLASH_RESET_N to low to activate.
<aw>
let me try now..;-)
<aw>
good . when i press middle btn, i see low pulse on RESET_N pin
<wpwrak_>
excellent
<wpwrak_>
now let's see that falling edge :)
<aw>
just very tiny duration... ;-)
<wpwrak_>
at 100 ns/div :)
<wpwrak_>
(tiny duration) very good :)
<aw>
yes, the "reboot" also make that pin have a low duration
<wpwrak_>
okay. we're in the "yellow" range. the drop is down to 1.9 V. without the scope, it would be a little lower.
<wpwrak_>
can you set the scope to a faster setting, maybe 100 or even 50 ns/div ?
<aw>
yes, also up to 4.5V roughly
<wpwrak_>
4.5 V ? oh. that's weird.
<aw>
so you only want to see the program_b's falling edge with a super tiny setting?
<wpwrak_>
yup :)
<wpwrak_>
4.5 V is very very strange.
<aw>
wpwrak_, it can be happened, we added C238 and no protection on both polarity clamping.
<wpwrak_>
naw, the little overshoot at the end is okay. what's weird is that you seem to drop to -1.0 V when CH2 is being reset
<wpwrak_>
that doesn't make sense at all. lekernel will have fun with it ;-)
<aw>
then we need to see if flash spec can face it as a full low though even having a negative pulse. just to see its maxmum value. ;-)
<wpwrak_>
your channels are DC coupled, correct ?
<aw>
sure sure
<aw>
yes, DC coupled.
<aw>
moments. i go to capture a new one.
<aw>
got
<wpwrak_>
-1.0 V is quite unexplainable to me. note that it looks quite stable over 1.5 us. it's not just overshoot. as i said, lekernel will have fun with this :)
<wpwrak_>
okay, we have 1.9 V. that's almost good. and much better than my simulation predicted, which is also good.
<aw>
yeah
<aw>
I already talked to factory about this C238 @ 100pF, but haven't got their reply if accept to rework. ;-)
<wpwrak_>
to err on the safe side, it may be better to use something like 120 pF. that should add roughly 150 mV.
<wpwrak_>
right now, you have about 250 mV before the forbidden zone. without the scope, this may shrink to 100-200 mV. i don't know what component tolerances will do.
<wpwrak_>
(or temperature variations, etc.)
<wpwrak_>
do you have air conditioning ?
<aw>
yes..go on
<wpwrak_>
okay, so your M1 has about 25 C then ?
<roh>
wpwrak_: there will be ambient testing on the ccc-camp ;)
<roh>
we can put it in a dataloo (up to 60deg C in there)
<aw>
then captured again..so you can compare curve with datasheet and calculate @ 25 degree, right?
<wpwrak_>
roh: *grin*
<kristianpaul>
60, wow
<wpwrak_>
aw: the data sheet doesn't tell us anything about the effect of temperature on the capacitance :)
<roh>
kristianpaul: 8 years ago we learnt that cisco has only monitoring up to 96deg C via snmp/whatever. from there on the value stays stuck
<aw>
wpwrak_, must be somewhere we can know. ;-)
<wpwrak_>
aw: but i think qucs can. lemme see :) my guess would be that lower temp = larger capacitance
<roh>
still switches packets then.
<aw>
wpwrak_, let's focus a bit, you are trying to know a lower bound..
<roh>
s/cisco/some cisco devices/g (also may have changed in the meantime)
<wpwrak_>
ah no. higher temp increases the effect.
<aw>
then if using 25 degree by air conditioning..then I can use heat air and measure to 60 degree to capture scopes then you can know the suitable capacitor we should be have.
<kristianpaul>
roh: haha
<wpwrak_>
yes, a hot test would be good. also in general, to see if there's anything else the M1 doesn't like.
<roh>
aw: sure.. if you have a heatgun which you can set so low, try it out. 60 dec C should to no harm to any components
<roh>
irgh. should NOT do any harm
<aw>
seems that I have to make some decision to make this C238 value done before factory tell me they can do.
<aw>
roh, yeah..sure
<wpwrak_>
aw: you could replace it with a 1 nF or add a 1 nF in parallel, whatever is easier, to see if we're close to the upper bound
<aw>
but like I said wpwrak_ need to let me know what exactly step i have to provide him..then we can a better value of C238 we need. ;-)
<wpwrak_>
aw: if the M1 boots and works normally with 1 nF or 1.1 nF, then we're safe with 100 pF, 120 pF, etc.
<roh>
hm. 7:23 and already worked 2 hours. this will be a bad monday.. shower now.
<wpwrak_>
roh: if you have time for a shower already at 7:23 am, you're having a relaxed day ;-)
<aw>
wpwrak_, oaky...now i go to add 1nF on 0.1nF to see if works well. ;-)
<roh>
when i am up at 5am on a monday it means something is wrong. usually i stay in bed on mondays till 1500
<wpwrak_>
aw: temperature should only have a relatively small effect on C238. i simulated at 125 C and the difference if maybe 10-20 pF.
<roh>
or make that 5pm if it was a good sunday
<kristianpaul>
will take shower in 4 hrs
<aw>
wpwrak_, but I remembered that i used fix2 + rc2 then got a C238 1nF then rendering a couple seconds then screen OFF yesterday.
<aw>
before at that time, my rc2 with C238 (47nF) and worked(rendering) well.
<aw>
btw, now soldering.
<wpwrak_>
aw: 47 nF or 47 pF ?
<aw>
47pF
<aw>
47pF // 1M ohm ;-) I tried to simulate prober then. ;-)
<wpwrak_>
so the 47 pF result only means that the real lower bound may be even a bit lower than 100 pF. this is to be expected. the 1.65 V limit is according to the data sheet, the point at which the chip is still guaranteed to work properly. the real limit will be lower, because they want a safety margin too. maybe 1.5 V or such.
<wpwrak_>
yeah :)
<aw>
from xilinx spec?
<wpwrak_>
yes
<aw>
good
<wpwrak_>
hmm. checking a different data sheet (also from xilinx), i see less friendly values.
<wpwrak_>
the one i picked said "50%" (= 1.65 V). this one says 2.0 V.
<wpwrak_>
this would put us already deep into the forbidden zone
<aw>
now..C238 1.1nF..time to capture @ 10ns/div again
<wpwrak_>
so going from 100 pF to at least 150 pF may be a good idea. but let's see how things go with 1(.1) nF
<wpwrak_>
simulation predicts about 3.1-3.2 V
<wpwrak_>
with a veeeery slow recovery ;-) (not that we'd actually care)
<wpwrak_>
aw: does the M1 boot okay with +1nF ?
<aw>
booting up... ;-)
<aw>
but with my probers..wait..discconnect it to check again
<wpwrak_>
afaik, the FPGA doesn't have any negative voltage. not sure if it can generate any inside. so something looks extremely wrong about those -1.1 V
<aw>
actually is -1.5V
<wpwrak_>
nice :) the drop is now down to only 3.1 V, like the simulation predicted
<aw>
not sure this is came from other circuits area and pfga can still work normally
<aw>
so you had have simulation tool?
<wpwrak_>
(-1.5 V) okay, with overshoot. some of this also comes from the scope. it's not the overshoot i'd be worried about :)
<aw>
okay...so we should use a 150pF~120pF?
<aw>
yeah...probably some came from my scopes.
<wpwrak_>
aw: i think 150 pF would be better than 100 pF, yes. with 1.9 V, we're probably already in the "forbidden zone"
<wpwrak_>
aw: and the scope adds a few pF, so the unobserved M1 will be worse
<aw>
so now I need to find a maybe 470pF (easiler) to test 100 times again.
<wpwrak_>
;-))
<wpwrak_>
i would wait with those 100 tests until we have an explanation for those -1.1 V
<aw>
yeah...btw, very much thanks about today's lessons. ;-)
<wpwrak_>
i think C238 is solved now and using 150 pF instead of 100 pF won't cause new problems
<aw>
the remaining is my jobs now. ;-)
<aw>
yes, but a 470pF is easier to source. ;-)
<wpwrak_>
thanks for doing all the measurements ! :)
<aw>
no problems I ought to.
<wpwrak_>
(470 pF) are you thinking of putting a 470 pF into all the M1 rc3 ? or just for the test ?
<aw>
wait...so you said yo uwould wait a 100 times until?
<aw>
i prefer to use few capacitor value catogories. ;-)
<aw>
hmm...wait..checking  bom now
<aw>
rc3 bom has 120pF and 220pF already.
<aw>
well...this is important function
<aw>
let's stick on 470pF though
<wpwrak_>
(100 tests) i think you don't need extra testing for going from 100 pF to 150 pF. the test with 1 nF already proves that you can survive with 10x the capacitance.
<wpwrak_>
hmm. i think 470 pF is very large.
<wpwrak_>
lekernel had concerns about rise/fall times, and a large C238 makes them worse.
<aw>
yes, theory it is. but you said a 150 pF...
<aw>
hmm..okay..I need to source a 150pF immediately. ;-) done?
<wpwrak_>
with 470 pF, the drop would be to ~2.7 V. with 220 pF, about 2.45 V. so if we can't have 150 pF, we may consider 220 pF
<aw>
yo just done with your simulated tool again?
<wpwrak_>
120 pF would also be an improvement over 100 pF. but it would leave no safety margin
<wpwrak_>
of course :)
<aw>
great.
<wpwrak_>
edit value, click on "Simulate", 2 s later, i have the new values :)
<aw>
so seems that now I go back to factory to bring few 120pF then try m1 again.
<aw>
always smart you are AUTO man.
<wpwrak_>
if you don't know qucs yet, you should have a look at it. it's very friendly to use.
<wpwrak_>
you mean to bring 150 pF ? :)
<aw>
120pF
<wpwrak_>
i thought they already have 120 pF ?
<aw>
i don't have 150pF now.
<wpwrak_>
"<aw> rc3 bom has 120pF and 220pF already."
<aw>
rc3 bom have 120pF parts but they are now at factory side.
<aw>
not on my hand here. :(
<wpwrak_>
aah, you want to go to the factory to take some 120 pF from them !
<aw>
yes.
<wpwrak_>
well, we can already predict how 120 pF will perform :)
<aw>
and also may see how current 89pcs going on...
<wpwrak_>
you've tested with 100 pF, so we know that 100 pF "works". we also know, from the measurements, that the signal still violates xilinx's specification with 100 pF
<aw>
yes.
<aw>
if that's said that a way..we think 150pF is better then I directly order on Digkey right way.
<wpwrak_>
i'm confident that my simulation correctly predicts that the signal will not violate the specification with 150 pF (and we'd have a little safety margin as well. so you could heat the board to 70 C and you'd still not violate the spec)
<aw>
alright...from few scopes we had have and simulations, I think I need to order a 150pF right now...this is some sort of delay a bit.
<aw>
but it seems much worthy though definitely.
<wpwrak_>
i would recommend 150 pF. i would consider 120 pF a little risky, but probably okay. 220 pF would probably be okay. it would definitely produce a very good signal as far as the drop is concerned, but we may then have to worry about rise/fall time. lekernel would know more about that issue.
<aw>
wolfspraul, hi good afternoon
<wpwrak_>
aw: (order 150 pF now) i don't think you need to rush this. it would be too late for the fab anyway, no ? so just tell them to leave C238 unpopulated
<aw>
wpwrak_, maybe we wait a bit until how lekernel think this rise/fall time
<wpwrak_>
and i want to see how he likes those -1.1 V. too bad we don't have videochat ;-)
<aw>
wpwrak_, yeah..
<wpwrak_>
let's hope it's something normal and benign. i would suspect your scope setup, but all the other levels look okay, so i can't think of a scenario where your scope would cause this
<aw>
i can pretty sure my scope on  settings...but this shouldn't have caused that negative level.
<wpwrak_>
well, bad ground or such. but again, that would also upset other results
<aw>
yeah..could be
<wpwrak_>
so i don't know what we're seeing there. if the FPGA can output negative voltages, maybe it's just a misconfigured I/O buffer.
<wolfspraul>
yes I read the backlog, looks like a lot of work
<wolfspraul>
:-)
<wolfspraul>
I was a bit worried about the 1nF test because I thought that's where the problems started in rc2 yesterday, but now it seems it can boot even with that. alright then.
<wolfspraul>
yes, don't rush buying 150pF until the negative voltage is looked at
<wpwrak_>
wolfspraul: the good news is that 100 pF is almost right. a little more and the signal will be good. not perfect but good. plus, we already know that we have plenty of headroom.
<wolfspraul>
do we know the upper boundary?
<wpwrak_>
wolfspraul: (1 nF) i think that was also around the time the M1rc2 developed its fatal flaw. anything after than was meaningless.
<wolfspraul>
yes
<wolfspraul>
that's why I'm saying - hopefully not caused by the 1nF :-)
<wpwrak_>
(upper boundary) no. we know it's > 1 nF. which is plenty :)
<wpwrak_>
ah ;-)
<wpwrak_>
naw, i don't think 1 nF can do this
<wpwrak_>
too much rework can, though
<wolfspraul>
how big of a problem is the negative voltage?
<aw>
sorry my laptop crashed. ;-)
<wpwrak_>
wolfspraul: how much of a problem is a sparrow doing deep see diving ? :)
<wpwrak_>
wolfspraul: it's something absurd
<wolfspraul>
if we are so little worried about upper boundary, why not just take the 200pF instead of 150pF then?
<wolfspraul>
220pF
<wpwrak_>
(220 pF) lekernel seems to worry about rise/fall time. making C238 big would increase these times. i don't know what the problem patterns are with PROGRAM_B_2 would be. could be that slow rise/fall just increases the risk of sporadic failure. or that some chips have a problem and others not. etc.
<wpwrak_>
(220 pF) so it's up to lekernel to decide what value he'd still consider to be safe
<wpwrak_>
aw: ah, in your rc3, the pull-ups on PROGRAM_B_2 and INIT_B have already been changed from 4.7 k to 10 k, correct ?
<aw>
not yet.
<wpwrak_>
wolfspraul: (220 pF) if he thinks 220 pF are still okay for the rise/fall time, then i'd agree to go ahead with it
<aw>
but I talked to factory this morning already.
<wpwrak_>
aw: i mean your rc3 board, the one we're testing now
<aw>
sure sure my rc3 are 10K. ;-)
<wpwrak_>
excellent :) have you also already removed the pull-up on FLASH_RESET_N (R60)
<aw>
i may order/prepare 150pF in advance not just wait. ;-)
<aw>
sure R60(removed), also talked to factory.
<wpwrak_>
aw: naw, let's not waste wolfgang's money :)
<wolfspraul>
wpwrak_: it was lerkernel who immediately suggested 1nF instead of 47pF. When the test result came in from Adam ('poweroff after short rendering'), that's when he started to talk about the rise/fall time.
<aw>
wpwrak_, ;-)
<wolfspraul>
but if he now finds out that 1nF works, who knows
<wpwrak_>
aw: if you need some other component because of the -1.1 V problem, you'll be happy to be able to put that into the same order
<wolfspraul>
if it would have worked yesterday, he would have never mentioned the rise/fall time, I'm sure
<wolfspraul>
so it may have been an attempt at explaining the 1nF failure, which we now thing wasn't even caused by 1nF (possibly)
<wpwrak_>
*grin*
<aw>
wolfspraul, maybe just my rc2 board was not pretty good at well-condition yesterday.
<wpwrak_>
wolfspraul: if you want to put something large (470 pF or more), adam should test with >> 1 nF, to make sure we still have enough headroom. maybe 4.7 nF or 10 nF
<wolfspraul>
better not
<wpwrak_>
why not ? afraid of too much rework ? :)
<wolfspraul>
no because I have no reason to ask for that, and I don't want to complicate the issue
<wpwrak_>
ah :) well, if you were to use a large C238, then the 1 nF test adam just did wouldn't be enough. but as long as we stay around <= 220 pF, it's plenty
<aw>
hmm...i don't have 150pF, even 220pF on hand now. although i can parallel two 100pF but not good.
<aw>
checking if have 10nF though.
<wpwrak_>
aw: you'll need the caps only for rework. i don't think we need any additional testing with values in the 120-220 pF range. i had a lot of faith in my simulation results :)
<wpwrak_>
aw: (10 nF) yeah, that could be useful to see how much headroom we really have. not really urgent, but not a waste of time either.
<aw>
wpwrak_, i have 10nF 0603...let's see if m1 still can boot well..and capture!
<wpwrak_>
but i'm very curious about those -1.1 V :) they're a totally unexpected finding
<aw>
so this proves that my rc2 + fix2 was somewhere is wrong already to cause not rendering...let's forget about yesterday. ;-)
<wolfspraul>
you are brave
<aw>
all related to rc3. ;-)
<aw>
maybe just cuased by my soldering. :-(
<aw>
yeah..this one is better than 1.1nF
<aw>
so i guess wpwrak_ now you are checking your simulation tool again. ;-)
<wpwrak_>
wolfspraul: (brave) naw, C238 can't do much harm. even if you shorted it and drive FLASH_RESET_N or INIT_B permanently high (i think both are open-drain), it's extremely unlikely to cause damage
<aw>
but it's really late you there. :)
<wpwrak_>
aw: (simulation) naw, i don't need simulation to know that 10 nF eliminates the drop ;-)
<wpwrak_>
aw: (late) oh, i'm not really synchronized to the sun
<aw>
wpwrak_, ;-)
<wpwrak_>
wolfspraul: (brave) most chips don't mind if you short their outputs to ground and let them burn 100 mW or whatever on that pin. not that anyone would recommend doing that, but it's usually quite safe. e.g., consider the lovely LED transistor without base resistor we had in GTA02. that was as good as a straight short to ground. and the GPIO survived this quite well.
<wpwrak_>
(there's we burnt something like 20-50 mW, don't remember the exact current. in any case, a lot. we could just have driven the LED directly, without the transistor. it would have been easier on the pin ;-)
<wpwrak_>
s/there's/there/
<aw>
wpwrak_, will be greatful if you can plot capacitor value vs voltage drop from your tool then set two boundaries as well?
<aw>
if it's hard, forget it. ;-)
<wpwrak_>
hmm, a parametric plot .. it can do that. there's probably a min(x) function somewhere, too
<wpwrak_>
the simulation can't really give you an upper bound, though
<aw>
yes, that's what i meant a parametric plot. so we and others can easily know capacitor value behavior, thanks. ;-)
<aw>
no problem about upper bound. ;-)
<aw>
meanwhile, although i don't have suitable capacitors on hand, but from scope results, the m1 rc3, the range of choosing C238 seems that can be 150pF ~ 470pF for safe?
<aw>
wpwrak_, if i was wrong, pls correct me. since the 10nF is to know a enough headroom.
<wpwrak_>
yes, 150 pF to 470 pF seem reasonably safe, provided that lekernel doesn't have any horror scenario for slow rise/fall times
<aw>
meanwhile i am testing rendering at least 10 times @ 10nF
<aw>
since this is really no need though. becuase the curve is much better. ;-)
<wolfspraul>
let's not become obsessed about this value
<wolfspraul>
we have enough data and to me it sounds like we can use the same 220 pF we have already in the bom
<wolfspraul>
the only thing left open to look at is the negative voltage
<wpwrak_>
still need to find a way to plot it in a nicer way, though
<aw>
sure, but just confirm a full test on rendering
<aw>
wpwrak_, great.
<wpwrak_>
aw: you should take the time to learn to use qucs. it's very easy. the only difficult part is that sometimes the simulation hits a problem and loops forever. then you need to tweak some parameters or add parasitic resistances or such.
<wolfspraul>
fully supported by me, but maybe after the rc3 run :-)
<wpwrak_>
wolfspraul: he can do this while waiting for lekernel to wake up :)
<aw>
wolfspraul, ha...i was though you won't let me spend too much time on this. ;-)
<aw>
s/though/thought
<wpwrak_>
aw: qucs will serve you with a lot of other problems :)
<wolfspraul>
oh, I totally support this. first it's a free tool, and then of course simulation can help us be faster and more effective, once the tool is well understood.
<wpwrak_>
aw: and this is an easy problem to simulate, so it's a nice things to get started with
<aw>
wpwrak_, alright..so just google "qucs"?
<wolfspraul>
in theory we can simulate the entire board and all chips, right? then no more small runs, no more production uncertainty - wonderful!
<aw>
i save related link first. ;-)
<wolfspraul>
:-)
<wolfspraul>
aw: can you upload pictures of the reworked rc3?
<aw>
moments..sorry
<lekernel>
aw, when the M1 stops at JTAG USB connection, it's usually because your distribution runs some daemon (e.g. gpsd) on the serial port that pushes some crap data which makes the M1 enter the debugger
<lekernel>
nothing to worry about
<aw>
lekernel, ;-) alright. good to know for me.
<lekernel>
where are those large under/overshoots measured?
<wpwrak_>
lekernel: CH2 is FLASH_RESET_N. CH1 is PROGRAM_B_2. what you see is the reset pulse on FLASH_RESET_N and the contamination it causes on PROGRAM_B_2
<lekernel>
ok, so I understand the PROGRAM_B waveform and it doesn't look too bad
<aw>
all those measured today.
<wpwrak_>
lekernel: yes, and we made it even better :) that's as good as solved
<lekernel>
but why the heck does the FLASH_RESET drop have a 4.1V amplitude?
<wpwrak_>
lekernel: what's weird is that FLASH_RESET_N drops to something like -1.1 V
<wpwrak_>
exactly :)
<wpwrak_>
i'm glad you're as puzzled about this as i am :)
<lekernel>
aw, does the power supply on your board work?
<lekernel>
is the 3.3V really 3.3V, or is it more like 4.1V?
<aw>
lekernel, no i used DC adapter
<lekernel>
i'm talking about the power regulators on the pcb
<wpwrak_>
lekernel: can the FPGA output negative voltages ? (e.g., if the I/O driver is configured for something funny, differential or such)
<lekernel>
no
<wpwrak_>
lekernel: note that the high voltage is a nice 3.3 V. the drop is from +3.3 V wrt ground to -1.1 V wrt ground. and it's fairly stable - no significant change over 1.5 us
<lekernel>
I think this is a measurement/ground problem
<aw>
lekernel, power regulators?
<lekernel>
aw, what is the "3.3V" voltage on your board?
<aw>
my common ground pin is TP34.
<wpwrak_>
lekernel: (measurement/ground problem) let's hope. otherwise, it's something very very interesting :)
<lekernel>
aw, and what happens when you measure the flash power supply pin with the ground on TP34?
<wpwrak_>
lekernel: is there a way to drive FLASH_RESET_N low for more than 1.5 us ? e.g., 1 ms or just permanently ? (doens't matter if the M1 crashes/hangs)
<lekernel>
yes, keep the reset buttons pressed
<lekernel>
all three pushbuttons
<wpwrak_>
aw: this would be a way to keep FLASH_RESET_N low for, say, a few ms. then we can see if it recovers (goes back to 0 V) or if it constantly stays at -1.1 V
<wpwrak_>
aw: you may want to connect the other channel to some reference voltage. maybe the 3.3 V rail.
<wpwrak_>
but that's the only good thing i have to say about it :)
<lekernel>
1V overshoot for 100us??
<lekernel>
urgh
<wpwrak_>
(about the signal, not the measurement. the measurement is perfect)
<wpwrak_>
quite a lot
<lekernel>
how is that possible?
<lekernel>
absolute maximum rating for the flash is -2V, so this is still acceptable, even if weird & a lot
<wpwrak_>
;-)
<wpwrak_>
now, where is that inductor :)
<wpwrak_>
or maybe a wayward cap ?
<lekernel>
I wonder what the other flash signals look like
<lekernel>
aw, can you try with R60 = 10K?
<lekernel>
same measurement
<aw>
okay...moments
<wpwrak_>
lekernel: maybe you can check on one of your boards ? or has FLASH_RESET_N changed a lot ? (besides the diode)
<lekernel>
I don't have a scope with memory
<wpwrak_>
oh dear
<wpwrak_>
well, even an analog scope should do
<wolfspraul>
I will review leaflet and brochure today, and send off for printing
<wolfspraul>
lekernel: how many brochures should we print?
<lekernel>
not too many i'd say, < 100
<wolfspraul>
that few?
<wolfspraul>
I'm in China here they will laugh at me.
<roh>
*g*
<wolfspraul>
they will think I forgot the 'K'
<lekernel>
I don't know, what do you want to do with them?
<wpwrak_>
wolfspraul: maybe ask them about their price structure. find the "knee" :)
<wolfspraul>
similar to the notebook stickers, hand out to people who go to events, conferences, etc.
<wolfspraul>
the question is how long they will remain unchanged
<roh>
wolfspraul: send me one together with a empty box (for my 'collection') ;)
<wolfspraul>
so I need to review the text and see how quickly it will age :-)
<wolfspraul>
maybe I print 500 or 1000 or so
<wolfspraul>
I also plan to send them to would-be shops and distributors, so they can put some in their store and see whether any customer reacts
<lekernel>
ok, then print more
<wolfspraul>
a lot of shops would do that for us, but it's a bit of work for us to mail it all out...
<lekernel>
how much are they anyway?
<wolfspraul>
no idea
<wolfspraul>
very little
<lekernel>
maybe 5k if we distribute them around like crazy
<wolfspraul>
well :-)
<wolfspraul>
you are a bit extreme
<wolfspraul>
first you say 100, now 5000
<wolfspraul>
the problem is:
<wolfspraul>
a) how quickly does the text age
<wolfspraul>
b) how much can we realistically distribute without recipients discarding them or treating them badly
<wolfspraul>
I'll start with 500 or 1000 or so
<wolfspraul>
when I mail them to shops, I guess if I mail 20 or so each time that's enough
<wolfspraul>
alright, I got my answer - thanks :-)
<wolfspraul>
100 leaflets, 500-1000 brochures
<lekernel>
ok
<wolfspraul>
I'm also thinking about making new notebook stickers with the new design from Christopher Adams, but I still have a lot of the old ones
<wolfspraul>
well, we get it all distributed...
<wolfspraul>
:-)
<lekernel>
aw, also try to measure flash A1 (pin 28) and see if you get large overshoot too when this pin toggles (e.g. when you apply power, during FPGA configuration)
<lekernel>
and during boot
<lekernel>
aw, so:
<lekernel>
1) overshoot on RESET with 10K pull up present (R60)
<lekernel>
2) overshoot on A1 (pin 28) during FPGA configuration
<lekernel>
3) overshoot on A1 (pin 28) during software boot (immediately after BIOS starts, as soon as you get something on the serial console)
<lekernel>
maybe it's the inductance of the long wire that causes the overshoot on reset?
<aw>
1) use rising when power up?
<lekernel>
no, same measurement as before, when the 3 pushbuttons are pressed after the board booted
<aw>
to eliminate consideration of inductance of long wire, i can use sharp prober again. then we know. ;-)
<aw>
alright
<lekernel>
it's also weird that there is this large overshoot but no ringing at all
<lekernel>
it looks like a RC circuit
<lekernel>
aw, leave the long wire in place, just add R60
<aw>
let me directly touched TP37, then we know if a long wire caused that. yes i added 10K and leave long wire.
<aw>
bad, no three hands..thinking.. ;-)
<lekernel>
aw, I just want a trace of FLASH_RESET_N, when the three buttons are pressed, and with R60 present
<lekernel>
but it seems they go rather low already ...
<aw>
yeah...so don't need to zoom in though
<lekernel>
the bottom curve is the 3.3V supply right?
<aw>
NO, ch2 is TP37
<aw>
correct sorry
<lekernel>
could you still zoom the pulses?
<aw>
typed too quick. bottom is CH1 (TP37)
<wpwrak_>
good :)
<aw>
zoom in A1, right?
<lekernel>
yes
<wpwrak_>
lekernel: lots of heavy overshoots also after the first one.
<lekernel>
yeah, but no ringing, why?
<wpwrak_>
i don't claim i understand what's happening there :)
<lekernel>
usually, heavy overshoot is accompanied by at least some ringing
<wpwrak_>
aw: oh, maybe do a probe compensation, just in case
<lekernel>
ah, yeah, maybe all this happens inside the probe
<lekernel>
it definitely looks more than a RC discharge than ringing or other transmission line effects
<wpwrak_>
you'd need a rather long transmission line for this ... no ringing within ~500 us ...
<aw>
oah..yes...maybe compensation on prober itself...man!
<wpwrak_>
well, about 50 km minimum. not too bad :)
<lekernel>
yeah... I did some measurements on the SDRAM signals (which are the most critical) with a high end 6GHz scope and there was negligible overshoot. so it's weird that it would happen that much on the flash.
<wpwrak_>
seems too extreme for being just a probe compensation problem, though
<aw>
no more -1V overshoot caused by didn't compensation.
<aw>
so previous on program_b just confirmed surely no doubt. :)
<wpwrak_>
hmm. there are still a few rather interesting excursions
<wpwrak_>
i wonder what they are ...
<lekernel>
aw, zoom on the pulses
<aw>
okay
<lekernel>
maybe just a scope problem - from my experience, digital scopes tend to do all kind of weird things when the sample rate is not high enough
<wpwrak_>
aw: you should be able to see them as follows: get rid of CH1. set CH2 trigger level to -0.5 V. Auto/Normal trigger. then zoom in.
<lekernel>
good old analog ones are better in this respect
<wpwrak_>
lekernel: also note that he's in peak detect mode now. in general, this shouldn't produce artefacts. but it may exaggerate some problems.
<wpwrak_>
lekernel: in general, peak detect works very well with that kind of scope (i have almost the same). and you need it to see things because it has very little memory.
<lekernel>
phew
<wpwrak_>
aw: after zooming in, lower the trigger until it stops triggering. then we'll have the worst glitch/whatever
<lekernel>
there are 2.5Gsps ADC chips under 100E (in single qty) now
<lekernel>
we should hook one of those to a FPGA, and add 1GB of DDR3 SDRAM and a USB connection
<wpwrak_>
lekernel: WANT ! :) how many bits ?
<lekernel>
14 iirc
<wpwrak_>
lekernel: (hook up to FPGA) YES :)
<wpwrak_>
lekernel: my dream is a scope with, say, 8-16 channels. doesn't have to have a lot of bits, 6 would be enough.
<lekernel>
this thing hooked up to a 77GHz RF frontend from a cruise control radar could do nice things too
<wpwrak_>
lekernel: tons of memory, of course. and a display with touch screen, for easy setup. going via PC is messy.
<scrts2>
how much such ADC costs?
<scrts2>
I am thinking of software defined radio, but my idea was 4ADCs of 250MSPS
<scrts2>
each sampled same clock but +90deg
<lekernel>
mom... I just received some ADI spam about that
<lekernel>
let me find it again
<scrts2>
250MSPS ADC costs ~60-100USD @ digikey, but I found the same for 10USD
<aw>
yes, after this, i tried to trigger at -0.5V, then I can't get anything.
<wpwrak_>
uuh. ugly things.
<lekernel>
aw, could you reduce the time/div setting?
<lekernel>
nah I don't believe this
<wpwrak_>
aw: what's the trigger coupling ?
<aw>
yes, i did..but once i reduce one segment time/div, then I can't get anything. seems that my scope memory not enough.
<aw>
DC coupling
<aw>
edge
<aw>
use level?
<lekernel>
what do you mean "can't get anything"? scope won't trigger?
<wpwrak_>
aw: you should let the board just run. no need to reset. these glitches should happen all the time.
<lekernel>
no, the flash is not accessed after boot
<aw>
since this A1 have a lot of info in front of current one I showed you.
<lekernel>
everything gets in the sdram
<wpwrak_>
lekernel: oh, damn. there goes my idea for "catching" the gliches :-(
<lekernel>
I don't believe there are such glitches
<aw>
i can slow down to 250us /div only then if 100us/div then screen shows nothing
<lekernel>
they are over the power supply voltages, and the only thing that could cause such voltages are transmission line effects. but transmission line effects do not cause sporadic glitches.
<wpwrak_>
i'd also be surprised if they're real. but the scope must have picked up *something* ...
<wpwrak_>
aw: yeah, your scope has very shallow memory. something like 1 kSa. barely enough for two zoom steps.
<aw>
i think so
<aw>
that 500us/div i can zoom on 250us/div to see, surely the waveform is strange. but if I need to trigger A1 @ 250us/div then no pulse i can get. :(
<wpwrak_>
hmm
<aw>
btw, i need to call factory about C238. it's bad that this morning I told a 100pF firstly.
<wpwrak_>
(silly me. scope shows the trigger setup. could have seen myself hat the coupling is DC ;)
<wolfspraul>
aw: we have settled on 220 pF now
<errordeveloper>
hello there ..
<aw>
if they do fast, then..bad
<lekernel>
hi errordeveloper
<errordeveloper>
actually I got a question down to the point -
<wpwrak_>
lekernel: shall we file the "glitches" under "UFO sightings - no action required" ?
<errordeveloper>
why lm32 and not openrisc or .. hm (i won't metnion the opensparc just yet)
<errordeveloper>
s/metnion/mention/
<lekernel>
errordeveloper, this is explained in the documentation online
<lekernel>
this should make it go 3 to 4 times faster
<aw>
R60(removed), R30/R157(10K), C238(100pF) , now have 45 pcs reworked done, then I just told to remove that 100pF
<lekernel>
or you can just solder another 100pF on top of the existing one during rework ...
<aw>
since I'll do a soldering for wire and one diode for sure, no need to tell them rework on 220pF now.
<aw>
I don't want them to dislike us and back and forth to get pain for them.
<wolfspraul>
sure
<wolfspraul>
so you do the 220pf
<wolfspraul>
we are doing design work in parallel with the run :-)
<aw>
they helped half of reworks, then half of it  belongs to me. ;-)
<wolfspraul>
aw: yes, all good
<aw>
wpwrak_, lekernel do i need to still re-capture considerable signal concerned?
<lekernel>
what signal?
<lekernel>
no, you shouldn't recapture anything imo
<wpwrak_>
"UFO sighting" then
<errordeveloper>
well, I'm at work and here I have an apple machine, so ..hm
<errordeveloper>
let's see if I'll get llhdl to compile
<wpwrak_>
goes back to his book. and soon a little nap :)
<lekernel>
errordeveloper, are you a C programmer?
<errordeveloper>
lekernel: to be honest still learning
<errordeveloper>
well at the moment I know C better then Verilog
<errordeveloper>
been working on a few smallish projects
<errordeveloper>
in terms of llhdl, i'd be up for doing some testing to start with ...
<lekernel>
it's way too early to test anything. in fact, most things do not work and I know it.
<errordeveloper>
damn, I still didn't get any fpga hw
<lekernel>
please no not report llhdl bugs or missing functionality unless they're accompanied with a patch. there are too many.
<errordeveloper>
well .. I'll start by trying to compile llhdl on darwin :()
<errordeveloper>
kewl
<wolfspraul>
errordeveloper: you can buy the Milkymist One fpga hardware in about 2 weeks or so, 499 USD + shipping. it's not the cheapest dev board you can find but it will give you a great starting point and something that actually works and is fun to use.
<wolfspraul>
if it's too expensive, there are dev boards of all kinds, going down to 50 USD or so
<errordeveloper>
oh, well .. I would, thought it's not the kind of money I'm able to spare right now :(
<errordeveloper>
yeah, I've seen some very cheap cpld boards from poland
<wolfspraul>
there may be cheaper dev boards that will still allow you to contribute to Milkymist effectively
<wolfspraul>
well you just have to set realistic goals first - focus. you can learn for 100 years...
<errordeveloper>
however those where really just break-out boards
<errordeveloper>
sure thing
<wolfspraul>
obviously from a Milkymist perspective it would be great if you could contribute something to the bigger unified goals of Milkymist. there is a lot to choose from :-)
<wolfspraul>
establishing focus for yourself should probably be your #1 priority now :-)
<wolfspraul>
milkymist one is a product, we spend a lot of time and effort to bring it up to 'product' level, in hardware quality, manufacturability, software features, accessories, etc.
<errordeveloper>
well, I don't have a problem with that ... despite a couple of very disturbing things which happend very recently
<wolfspraul>
the cheapest fpga dev boards are essential marketing tools for the fpga makers. nothing wrong with that, like I said first you need to know what you actually want and what your focus is.
<wolfspraul>
what disturbing thing happened?
<errordeveloper>
a) I kind of really need to change the job and  & b) my uni is giving me a bit more trouble
<errordeveloper>
I got my project done quite well, though happend to fail a math module (which I chose myself)
<errordeveloper>
very very silly
<errordeveloper>
how could I know that error correcting codes is totaly not my thing !?!
<errordeveloper>
well ..
<errordeveloper>
I mean, I totally understood how they work
<errordeveloper>
but just not able to do all the proofs etc
<errordeveloper>
sorry don't want to complain
<wolfspraul>
:-) we hear you
<wolfspraul>
Milkymist for all its greatness cannot help you with that :-)
<errordeveloper>
lol :)
<errordeveloper>
lekernel: milkymist-ruby, is it just a patched MRIÂ Â to run on lm32 ?
<lekernel>
MRI?
<errordeveloper>
Matz's Implementation of Ruby
<errordeveloper>
:)
<lekernel>
it's the small ruby interpreter, with very minor modifications to run on rtems and lm32 yes
<lekernel>
if you're planning to run that on your FPGA board, keep in mind this needs SDRAM, and all non-professional people I've heard of have failed to get that to work when trying to port Milkymist (or other softcores) to their FPGA boards
<lekernel>
if you buy a M1, you get usable SDRAM out of the box
<errordeveloper>
well, I'm just generally interested how far Ruby will get in the embedded world
<errordeveloper>
I quite like Ruby as a language
<errordeveloper>
hm .. is the ac97 core capable of 96kHz sampling rate ?
<wolfspraul>
errordeveloper: if you have friends who are also developers, tell them about Milkymist :-)
<wolfspraul>
that'd be a really cool thing you could do to help the project
<errordeveloper>
sure, I mean .. at the moment I really don't know any hw people
<errordeveloper>
though .. hm, I know some people in VJ circles
<errordeveloper>
:)
<wolfspraul>
anything 'below' kernel is still out of sight for many software folks, whether that's dsp, fpga/ic design, data converters, synthesis, and so on
<wolfspraul>
just tell your friends about the project, that'd be an awesome help
<errordeveloper>
yeah, some only care about the webapps
<errordeveloper>
and may be arduinos :)~
<wolfspraul>
not bad, that's a start
<errordeveloper>
;)
<lekernel>
is reading a hardware hacker journal atm with _thermodynamics_ in it. but that was 1993 ...
<wolfspraul>
some may only care about fishing, or basketball, or ... that'd be a bigger gap :-)