**** BEGIN LOGGING AT Fri Jan 27 03:00:02 2017 Jan 27 03:39:50 Hello guys, I am akshay from India. just wanted to know whether are there any issues reported for the library for beaglebone black. I am unable to see spidev in /dev for my black. my programs is stick at ser.read. the bbb doest give any error msg while executing the program byt when i interrupt the program it show last line of execution ser.read. please help me. my emal id is akshay280294@gmail.com Jan 27 04:21:51 any answer to my question Jan 27 04:21:52 ?? Jan 27 07:11:11 'morning! Jan 27 09:36:27 zmatt: is it possible that I am putting fifo queue in underflow? Jan 27 09:40:46 while my fifo count is != 0 (i.e. 2 in not continuous mode), my fifo sample channel ID = 0 and samples value are nuts : \ Jan 27 10:38:16 if you only read when the fifo count is nonzero then you shouldn't be underflowing the fifo, but you can check of course in the irq rawstatus register Jan 27 10:50:23 zmatt: I read only when the fifo count is != from 0 Jan 27 10:51:53 btw, in the TRM it is wrote that the fifo count contains the "words" (i.e. I believe 16bit) in fifo queue... but the fifo queue register is of 32bit... Jan 27 10:53:02 (thank you for the help ;) ) Jan 27 11:09:43 "words" generally mean 32-bit, I have absolutely no clue what on earth made them use the terminology of a word being 16-bit on PRU, especially since it's a 32-bit processor Jan 27 11:11:24 zmatt: lol Jan 27 11:12:39 you can of course use a 16-bit read on the adc fifo, but you'd still pop an entry from the fifo for each read, hence performing a 32-bit aligned 16-bit read returns just the adc value and discard the tag Jan 27 11:16:44 zmatt: lovely. Therefore, I beleive i am doing the right thing as I am popping the first entry and storing it into a structure. Then, I process which is the data and which the channel. Am I right? Jan 27 11:17:17 of course, data and id channel are extracted from the structure Jan 27 11:18:16 if you "channel" you mean "step number" then yes Jan 27 11:19:13 uhm... this sounds like I found the issue Jan 27 11:19:29 may you explain it better please? Jan 27 11:20:11 the tag contains the step number (0-15) Jan 27 11:20:39 (if enabled using bit 1 of control register of course) Jan 27 11:20:45 not sure how much more there's to explain Jan 27 11:20:55 so Jan 27 11:21:12 ADCCHNLID means the step if and not the channel id....? Jan 27 11:21:21 ADCCHNLID from fifoXqueue Jan 27 11:23:17 yes, and my own header describes this quite unambiguously in the description of control bit 1 ("tag data with step number in upper halfword") Jan 27 11:24:55 sh*t! I did not watched your comment and I was using what wrote in TRM Jan 27 11:25:05 which uses "channel" Jan 27 11:25:19 T.T Jan 27 11:25:23 lesson learned: never assume the TRM is right :) Jan 27 11:25:42 at least I learned 1 thing today ;) Jan 27 11:26:06 then, why fifo count is 2 instead of 1? I enabled only step1 Jan 27 11:26:42 basically when you read something, mentally prefix it with 'we think it might be' Jan 27 11:26:53 I have no idea Jan 27 11:27:17 if you enabled only one step, in non-continuous mode, then only one measurement should be logged in the fifo Jan 27 11:27:43 that's my understanding anyway, but I never tested that much Jan 27 11:29:22 uhm... I enabled only step1 and I have fifo count = 2 Jan 27 11:29:53 and what's fifo count after reading one value ? Jan 27 11:29:56 that is my understanding as well.. but if I think about what I learned today... Jan 27 11:30:55 are you sure fifo count was initially zero? (yes it really should be, but check it anyway) Jan 27 11:31:43 that's a good point. Let me check, please Jan 27 11:31:54 does reading a second value result in fifo underflow or not? (check and clear irq (raw)status bits at every opportunity available) Jan 27 11:32:46 you can find the definition of the Irqd4w structure I use in my headers here btw -> https://github.com/dutchanddutch/jbang/blob/master/include/ti/irqd.h Jan 27 11:32:58 as far as i am understanding, I should move from a busy wait on fifo count to a busy wait on irq raw... right? Jan 27 11:34:03 or enable the irqs you care about and busy wait on irqstatus (that's one step closer to actual irq handling) Jan 27 11:34:49 https://github.com/dutchanddutch/jbang/blob/master/include/ti/irqd.h#L41-L58 I've split out the different read/write behaviours of those registers as you can see Jan 27 11:36:50 also, in retrospect the right name for this thing is "irq combiner" but I haven't gotten around to changing my headers yet Jan 27 11:38:22 I'd now probably be more inclined to call the struct IrqcHL (irq combiner, Highlander version), maybe Jan 27 11:38:37 highlander version, lol Jan 27 11:38:39 (the 4 refers to omap4, which introduced this style of irq combiners) Jan 27 11:39:51 the term highlander also shows up quite frequently in docs, apparently referring to some TI-internal standard for common peripheral registers (ident, hwinfo, sysconfig, irq combiner) Jan 27 11:40:33 I tought that it was a joke, but it seems that it is a serious term O.O Jan 27 11:40:44 yes, search the trm Jan 27 11:41:03 lcdc uses it quite explicitly, and also mentions the internal name for the irq combiner module Jan 27 11:42:04 ipgvmodirq Jan 27 11:43:19 +1 learned things Jan 27 11:44:52 thank you zmatt ;) Jan 27 11:45:21 I like to think of it as some truce signed by the chieftains of the Wireless Technology Business Unit (WTBU) and Application Specific Products (ASP) after years of bitter warfare Jan 27 11:45:41 gtg to eat, then I'll check if counter is = 0 at the beginning and then I am gonna start to move to IRQ as you suggested Jan 27 11:45:51 zmatt: LOL xD Jan 27 11:46:23 see you later Jan 27 12:39:11 Wasn't the OMAP platform a WTFBU game, orignally? I remember that was the reason we didn't get any, we only got stuff from the "Catalog" people... Jan 27 12:42:21 WTBU was "omap etc" yes Jan 27 12:42:34 ASP is "DSPs etc" Jan 27 12:42:44 is/was Jan 27 12:42:58 dunno if the divisions as such exist anymore at all Jan 27 12:43:04 probably not Jan 27 12:46:52 nowadays omap-derived and dsp-derived technologies seem to intermingle pretty freely Jan 27 12:47:29 (k2g still caught me by surprise though) Jan 27 13:00:54 afk Jan 27 14:21:04 zmatt: Regarding boot log, image or animation during boot. Either plymouth or any kind of image on the screen. I'd like to eventually show the boot log, or a logo, or an animation during boot. Is there a way to test it? Jan 27 14:22:37 zmatt: I recompiled the kernel for my beagleboard x15 with the bootup logo enabled, but I only get a flicker on the screen. Jan 27 15:04:16 Hi guys I need help on my BBB. I want to change the pin mode on P8-46 to mode 7 GPIO. Can someone help me on how to get there? Jan 27 15:08:05 have you tried config-pin command? Jan 27 15:08:24 *did Jan 27 15:08:30 *did you try Jan 27 15:09:27 I tryied echoing Jan 27 15:09:34 But it did not work Jan 27 15:09:50 what did you try? Jan 27 15:10:27 I am trying to change the device tree. If you can tell me where the device tree for the pin control on kernel 3.8.13 Jan 27 15:10:57 echo 1 > value Jan 27 15:11:20 simple comamands but not nothing seems to work Jan 27 15:12:26 I watched so many videos online showing how to do it but most of those videos were old and the Kernel is different now Jan 27 15:12:59 most of the guides around are for different kernels. Hence, for my experience you should check for guides for your kernel (or drivers) Jan 27 15:13:13 can you run a "man config-pin" for me please? Jan 27 15:13:46 for my experence, I always used the "config-pin" command to change pin mode Jan 27 15:13:48 sure just a sec Jan 27 15:15:09 root@beaglebone:~# man config-pin Jan 27 15:15:27 No manual entry for config-pin Jan 27 15:15:48 That is what I am getting Jan 27 15:16:15 try with "config-pin -q P8.46" please Jan 27 15:17:02 if you do not have the permissions, try to "sudo config-pin -q P8.46", please Jan 27 15:17:03 P8_46 pinmux file not found! Jan 27 15:17:14 try with the sudo please Jan 27 15:17:46 cape-universala overlay not found Jan 27 15:17:55 run "config-pin overlay cape-universala" to load the cape Jan 27 15:18:17 which dtb are you using? Jan 27 15:18:48 I am not very sure but I downloaded something called a device tree Jan 27 15:18:57 and has an overlay in it Jan 27 15:19:16 ok Jan 27 15:19:57 are you just starting to play with the bbb? Jan 27 15:20:04 so if I nevegate to that will be cd boneDeviceTree/overlay Jan 27 15:20:15 I am new to it Jan 27 15:20:17 ok Jan 27 15:20:18 then Jan 27 15:20:31 as I am also new, but with a bit more experience than you Jan 27 15:20:31 I have done two projects with it so far Jan 27 15:20:41 I would suggest to read some guide Jan 27 15:20:58 I am still struggling with modules, drivers, etc. as well Jan 27 15:21:11 I read so much I wont go out to ask if I have not done my research Jan 27 15:21:32 I know I need to hack it and change the device tree Jan 27 15:22:22 what do you need to do? I mean why do you need to edit your DT? Jan 27 15:22:39 without info it is hard to suggest :) Jan 27 15:24:49 I need to change the pin mode ' Jan 27 15:25:04 without the pinmode change it wont work Jan 27 15:25:18 I can spend all my day coding but it wont work Jan 27 15:25:28 is it used by enabled devices this pin? Jan 27 15:25:32 e.g. hdmi? Jan 27 15:25:42 pin mode has to be changed and that specific pin will hurt the HDMI Jan 27 15:25:54 yes but I don't need the HDMI Jan 27 15:26:01 did you disable the hdmi then? Jan 27 15:26:27 how did you disable the hdmi? Jan 27 15:26:34 how? Jan 27 15:26:54 hdmi can be disabled via DT Jan 27 15:26:58 did you do that? Jan 27 15:27:15 if not, how did you disable the hdmi in order to change that pin configuration? Jan 27 15:27:20 No I have not done that Jan 27 15:27:24 ok Jan 27 15:27:25 then Jan 27 15:27:28 probably that is what I am after Jan 27 15:27:56 hence, you need to edit the DT in order to disable hdmi. Therefore, you would change the pin configuration Jan 27 15:28:14 ok but the question is how? Jan 27 15:28:17 http://elinux.org/EBC_Exercise_30_PRU_via_remoteproc_and_RPMsg#Setting_up_the_PRU_compiler Jan 27 15:28:27 this is a guide which could give you some info Jan 27 15:29:18 focus on the paragraph "Disable HDMI" Jan 27 15:29:40 Ok thank you I will read it and try it hopefully it will do I what I want it to do Jan 27 15:29:51 Ok thank you for the hint and the info Jan 27 15:29:58 it worked for me, I believe it will works also for you Jan 27 15:30:04 ;) Jan 27 15:30:12 welcome Jan 27 15:30:18 *work Jan 27 15:36:44 I am rebootting now lets see Jan 27 15:38:15 kk: http://elinux.org/Beagleboard:BeagleBone_Debian_Image_Migration Jan 27 15:38:29 also includes info on how to disable hdmi Jan 27 15:39:13 I did the uncommenthing thing and my BBB is not booting now Jan 27 15:39:17 yeah it's the same info Jan 27 15:39:19 All the LEDS are on Jan 27 15:39:42 (assuming you have a beaglebone black) Jan 27 15:39:52 kk: are you working on a microSD? Jan 27 15:39:58 Yes I have a Beaglebone black Jan 27 15:40:22 no I just have a beaglebone black out from the box Jan 27 15:40:28 No sd card Jan 27 15:41:00 Now I cannot SSH into it any more after the HDMI disable Jan 27 15:41:11 did you press the boot button while powering it? Jan 27 15:41:13 I did reboot and now its not booting anymore Jan 27 15:41:49 that's not good Jan 27 15:41:51 no I gave it a reboot command Jan 27 15:41:56 (if you are working on a uSD there is no need to worry, in the worst case you just reflash it ;) ) Jan 27 15:42:04 then you are not booting the uSD Jan 27 15:42:12 he's not using a card Jan 27 15:42:15 zmatt: correct me if i am wrong Jan 27 15:42:22 I am not operating on an SD card Jan 27 15:42:43 The beaglebobe is showing on my computer but I cannot SSH into it Jan 27 15:42:44 O.O Jan 27 15:42:48 lore4: there's never any need to reflash just even if you hose the uEnv.txt Jan 27 15:43:09 plug via usb? Jan 27 15:43:11 kk: it sounds like you might have made a mistake while editing the uEnv.txt ? Jan 27 15:43:16 Ok so what does that mean? Jan 27 15:43:44 kk: I don't suppose you have a console cable? Jan 27 15:43:47 I am sure I followed the web instructions word by word Jan 27 15:44:18 that's weird, the instructions look okay to me Jan 27 15:44:19 what is a console cable? Jan 27 15:44:44 a serial cable for the debug console -> http://elinux.org/Beagleboard:BeagleBone_Black_Serial Jan 27 15:44:57 But Lore4 says even if I lose the txt file I should still be able to boot Jan 27 15:45:12 it's nearly impossible to debug boot issues without a serial cable Jan 27 15:45:30 no he didn't Jan 27 15:45:50 No I just have the USB and that is how I am powering it now Jan 27 15:46:22 Ok so what should I do now? Jan 27 15:46:40 uhh, with serial cable it would probably be easy to recover Jan 27 15:47:04 I don't have one Jan 27 15:47:22 without serial cable, the next option would be flashing some system onto a card and boot from that, then investigate to see if you can find any mistake in the uEnv.txt Jan 27 15:47:25 I will order one for future but in the mean time I want to find a way to boot my BBB again Jan 27 15:47:39 zmatt: am I wrong or it is possible to edit uEnv.txt via while bbb is mounted via usb cable? Jan 27 15:47:55 *remove "via" Jan 27 15:48:05 lore4: getting it into mass storage mode to mount the bbb requires a serial cable Jan 27 15:48:30 :( Jan 27 15:48:41 Ok so flashing is my only way now? Jan 27 15:48:42 if you have a serial cable you can also override the uEnv.txt entirely Jan 27 15:49:27 kk: you can boot from an sd card and see if you can fix the uEnv.txt on the eMMC Jan 27 15:49:27 no I don't have a serial cable Jan 27 15:49:41 kk: I know, I was explaining to lore4 Jan 27 15:50:16 OK so the only option I have now is to reflash Jan 27 15:50:20 no Jan 27 15:50:29 zmatt: https://groups.google.com/forum/#!topic/beagleboard/l0oh8Amfmbw here there is wrote a way to edit back uEnv on mmc. Is it right for you? Jan 27 15:50:46 as I just said, you can boot from an sd card and then see if you can fix the uEnv.txt on eMMC Jan 27 15:50:48 I don't have a BBB 3.8.13 image to boot from an sd card Jan 27 15:51:11 kk: you can download any image from the offical site. Jan 27 15:51:13 ohh, you're using an ancient system? Jan 27 15:51:20 that explains why the modification you did failed Jan 27 15:51:35 those instructions were for 4.x systems Jan 27 15:52:13 but beaglebone comes out from the box with 3.8.13 image Jan 27 15:52:35 kk: sorry, I wrote you an updated guide : \ Jan 27 15:52:42 that's possible, it probably sat on a shelf for a while Jan 27 15:52:44 http://beagleboard.org/latest-images here there are the images Jan 27 15:52:46 ... quite a while Jan 27 15:53:02 no I bought it from Digi-KEy Jan 27 15:53:22 digi-key probably has shelves too :P Jan 27 15:53:37 yea you are right Jan 27 15:53:51 Ok so what image should I download Jan 27 15:53:59 What would you recomand for me? Jan 27 15:54:45 the latest official image is probably a good start, the iot image preferably if you don't need a gui (and I'm assuming you don't since you were going to disable hdmi) Jan 27 15:55:28 for what I am building right now I don't need the HDMI but for other projects I will Jan 27 15:55:43 the lxqt image is rather bloated in my opinion Jan 27 15:56:15 bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img.xz Jan 27 15:56:42 a flasher image might be more convenient, you can find the latest lxqt-4gb flasher here: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots Jan 27 15:56:55 if you scroll down to "Flasher: (lxqt-4gb)" Jan 27 15:57:23 the standalone images would boot from the card instead of reflashing eMMC Jan 27 15:57:37 you can pick either of those options, whichever you prefer Jan 27 15:58:05 eMMC typically has higher performance than card Jan 27 15:58:58 Ok this is what I am downloading now microSD/Standalone: (machinekit) Based on Debian Jessie (new) Jan 27 15:59:03 no Jan 27 15:59:27 So which one? Jan 27 15:59:28 machinekit? Jan 27 15:59:32 O.O Jan 27 15:59:49 kk: flasher or standalone, lxqt-4gb if you want a gui Jan 27 16:00:00 flasher flashes to eMMC, standalone runs from card Jan 27 16:00:43 I want to flash the eMMC Jan 27 16:00:55 I don't want to run of SD card Jan 27 16:00:57 then download the flasher Jan 27 16:01:49 bbl Jan 27 16:02:19 I canot find any flasher word in the page you sent me earlier Jan 27 16:02:59 https://rcn-ee.com/rootfs/bb.org/testing/2017-01-22/lxqt-4gb/bone-debian-8.7-lxqt-4gb-armhf-2017-01-22-4gb.img.xz Jan 27 16:03:05 ???? Jan 27 16:04:11 the flasher images have "blank" in the file name. Jan 27 16:05:27 http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flasher:_.28lxqt-4gb.29_.28All_BeagleBone_Variants_with_a_4GB_eMMC.29 Jan 27 16:06:45 also, they're listed as "flasher" on the webpage I linked Jan 27 16:06:50 http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flasher:_.28lxqt-4gb.29_.28All_BeagleBone_Variants_with_a_4GB_eMMC.29 Jan 27 16:12:47 Ok zmatt I will try the microsd card Jan 27 16:13:42 zmatt: I did not have success with the IRQ... hence, I came back to use fifo count. However, while I enabled 6 steps, in count I find only value 1 in fifo count. Does it sound strange to you too? Jan 27 16:13:55 kk: sorry for linking you a recent guide : \ Jan 27 16:14:24 Its ok Jan 27 16:14:29 :( Jan 27 16:14:53 just wondering if I flash with the latest image I will be ok again or no? Jan 27 16:15:18 I guess so kk, but let's wait someone else confirmation :) Jan 27 16:23:12 lore4: yes, it sounds strange to me too Jan 27 16:23:33 lore4: actually no, it doesn't Jan 27 16:24:00 lore4: since you're probably waiting until fifo count != 1, so finding it to be equal to 1 at *that time* makes perfect sense to me Jan 27 16:24:08 the adc is simply then still busy sampling Jan 27 16:24:50 zmatt: I also tryed to wait fifo count > number of enabled steps -1 but it goes in deadlock T.T Jan 27 16:25:06 that's not good Jan 27 16:25:22 may I say that I am getting a bit pissed about this ADC? :P Jan 27 16:25:23 I'd suggest simply dumping a lot of state along the way Jan 27 16:26:18 I'd suggest first getting the adc working from linux userspace before moving your code to the pru, since it's obviously easier to log or debug stuff there Jan 27 16:26:56 guys I am guessing you both are part of beaglebone company or team? Jan 27 16:27:01 nope Jan 27 16:27:12 actually, I made up a message from PRU to ARM which contains an header (i.e. number of samples) and then it packs for each samples if, fifo count, tag, and value) Jan 27 16:27:23 I'm just Some Guy™ Jan 27 16:27:28 no, I am just a developer for a small company Jan 27 16:27:34 yeah ditto Jan 27 16:27:42 top! Jan 27 16:27:49 Ok Jan 27 16:28:19 I am still trying to download the latest image Jan 27 16:28:22 lore4: if you think the ADC is troublesome to setup, wait until you have to deal with an UART or I2C controller ;) Jan 27 16:31:17 T.T Jan 27 16:31:33 tomorrow, it will be a bright new day Jan 27 16:33:32 hi there channel :-) Jan 27 16:34:12 you realize a channel is inanimate right, and not going to reply? Jan 27 16:35:57 can anyone answer me which it's better for a webserver beaglebone black rev. c or beaglebone black industrial the one has red board? Jan 27 16:37:20 or to build a drone ? what's your opinion zmatt? Jan 27 16:38:01 I have no idea what exactly is different about the industrial, apart from the pcb color Jan 27 16:39:28 zmatt, all right... what about to build a drone to fly at least an hour? Jan 27 16:42:11 zmatt: goody... I will have the weekend to rest a bit... see you monday! Jan 27 16:42:15 bye at all! Jan 27 16:42:47 lore4: you actually work weekdays nine-to-five or something? such lack of commitment! ;-) Jan 27 16:43:20 8 to 6 ;) Jan 27 16:43:28 well okay Jan 27 16:44:11 you too? Jan 27 16:44:16 I think the industrial version has more to do with the guaranteed reliability of the parts populated on the board. In terms of what they are capable of, I don't remember seeing any difference in their specs. I think the board operates in a wider range of temperatures. Jan 27 16:44:24 That's the only thing that stood out to me when I read about it on release Jan 27 16:44:25 btw +1 UTC Jan 27 16:45:42 yeah, I stopped to work during weekend after I stopped to work at the university Jan 27 16:45:54 now I lack of commitment : Jan 27 16:45:56 :P Jan 27 16:46:05 bye bye Jan 27 16:47:58 MathOnNapkins, so to keep a beaglebone black device 24 hours without switching off I guess industrial will do better job than the other one, right? Jan 27 16:48:57 dury: I think that's the idea, but any device can fail of course Jan 27 16:52:53 MathOnNapkins, I see... what about to build or assemble a drone to fly for an hour. Which beagleboard and capes Jan 27 16:53:29 dury: I have no idea about building drones nor the interest. I'd google around to see what you can find. Jan 27 16:55:26 MathOnNapkins, what's your purpose with your beaglebone black or the beagleboard you have? Jan 27 16:57:00 dury: A customer of ours needs us to provide applications and libraries that are compatible with it. (For use with various instruments we manufacture) Jan 27 16:57:52 (Not that I don't think little boards like that are neat on their own, but I don't have any hobbyist plans for them at the moment) Jan 27 16:58:10 *aren't neat Jan 27 17:02:33 MathOnNapkins, just curious is your device BBB Rev.C ? mine it's Rev. A5C Jan 27 17:03:03 I have some Rev A5C, some rev Bs, and some rev Cs Jan 27 17:03:28 I think I have about 8 in all laying around here Jan 27 17:03:52 I see.... gesssss Jan 27 17:04:00 Generally I'd prefer to have Rev Cs b/c of the larger eMMC Jan 27 17:05:08 I know what you mean 'cause it has more capacity 4GB eMMC Jan 27 17:05:10 But the older revs, well I don't really want to trash them but they're kind of useless for my current development b/c my customer wanted to switch to Debian Jan 27 17:05:50 Been trying to think of something to use them for that would get me interested but nothing yet Jan 27 17:07:38 MathOnNapkins, the same happens with my Rev. A5C what I can do with it?, gesssss Jan 27 17:08:26 Ya got me Jan 27 17:09:06 you can use a5c for pretty much the same thing as a rev c Jan 27 17:09:22 what's that "Ya got me" Jan 27 17:09:33 sorry to ask you that Jan 27 17:09:35 I meant like "I have no idea" Jan 27 17:09:46 right I see Jan 27 17:10:12 I just noticed rcn-ee even releases 2gb lxqt images again, if for some obscure reason you want a desktop environment on your bbb Jan 27 17:10:53 oh.... well that is neat to know zmatt Jan 27 17:11:04 I reflexively want a desktop environment, though I never use it XD Jan 27 17:11:07 yeeaah Jan 27 17:11:32 MathOnNapkins: you simply love an eMMC stuffed full of crap? Jan 27 17:11:49 I don't love it, I just reflexively reach for it Jan 27 17:12:41 and more importantly, I try to develop in an environment the customer is deploying in, and they've never indicated they install headless images Jan 27 17:15:01 I really never felt any urge to have a desktop environment on the bbb Jan 27 17:15:29 we run them exclusively headless or with a dedicated fullscreen gui Jan 27 17:15:38 zmatt, rcn-ee release 2gb lxqt image... that's mean it can flash it in eMMC REV A5C Jan 27 17:15:55 yes Jan 27 17:16:10 of course you can also flash the console or iot images Jan 27 17:16:38 (or boot from SD if you want to use a more bloated image) Jan 27 17:17:07 zmatt, I personally prefer X Desktop Jan 27 17:17:32 dury: well yes I have a reasonably comfortable X11 environment... on my laptop Jan 27 17:18:04 which I much prefer to use over some slower environment on a bbb Jan 27 17:21:15 zmatt, what's the link of that 2gb lxqt image to burn it in a sd card to flash Jan 27 17:21:51 zmatt, is that debian based? Jan 27 17:23:08 lxqt-2g standalone image is on the bbb debian snapshots wiki page, you can make that into a flasher in the usual way Jan 27 17:25:48 zmatt, jeesuuuss mate!!! I don't know how to do it, though!! can you help me, please Jan 27 17:26:42 zmatt, just drive me how to, please Jan 27 17:26:57 sorry, bit distracted so I was too lazy to look it up Jan 27 17:26:58 :) Jan 27 17:27:20 zmatt, take your time no rush Jan 27 17:27:50 zmatt, actually I will leave it for tomorrow though Jan 27 17:28:47 zmatt, steady, steady Jan 27 17:29:03 need a break Jan 27 17:29:53 I will be in this channel probably tomorrow Jan 27 18:36:29 Wondering if the Beagle bone black industrial solution comes with a UL 796 certification per the construction Jan 27 19:20:28 ok, I guess I'm seriously stuck and could use some ideas :) Jan 27 19:20:31 http://csgraf.de/agraf/sdemu/cmd18.png Jan 27 19:21:00 CLK is connected to P9.31 CMD is P9.29 Jan 27 19:21:41 CLK is set to mode6 (pru0 gpo in), CMD to mode5 (pru0 gpo out) Jan 27 19:22:42 as long as my clk signal is slow enough (seems to work up to 6mhz) everything is fine Jan 27 19:23:04 but if it wiggles too fast, I'm getting weird side effects on the CMD line Jan 27 19:23:50 all the 0 bits in the "Argument" field that look odd - those are all r31.t1 set to zero Jan 27 19:24:20 if I add another "1" in the Argument field, the noise creeps in a few bits later Jan 27 19:24:34 if anyone has ideas what that could be, I'd definitely appreciate it Jan 27 19:26:16 I wish I could agraf, your knowledge is better than mine though Jan 27 19:30:33 agraf, this one not info http://alex.csgraf.de/self Jan 27 19:30:55 dury: yeah, it's been broken for a few years :) Jan 27 19:31:46 agraf, this one does success http://csgraf.de/ Jan 27 19:32:06 dury: yes, that's not mine ;) Jan 27 19:34:11 agraf, I'm not saying if it's yours or not just it works and that's it only Jan 27 19:42:37 agraf: can you capture this with a scope? Jan 27 19:42:58 zmatt: if i had one ;) Jan 27 19:43:16 also, interesting, your PNG has JPEG artifacts Jan 27 19:43:28 zmatt: yes, it's a screen capture from a vnc session Jan 27 19:43:37 zmatt: which got transferred over nx Jan 27 19:43:47 heh Jan 27 19:43:48 :) Jan 27 19:44:08 zmatt: so what would the scope tell us? Jan 27 19:44:18 zmatt: it's always at the same spot Jan 27 19:44:25 agraf, the responsible for web programming http://www.ilkahennig.com/ not found. it seems that csgraf.de wasn't update in ages, right? Jan 27 19:44:26 if it's a signal integrity issue of some sort Jan 27 19:44:27 zmatt: if i add a delay to my reply, it's still at the same spot Jan 27 19:44:45 e.g. cross-talk Jan 27 19:44:54 zmatt: yeah, i was thinking cross-talk too at first Jan 27 19:45:03 what's generating the clock? Jan 27 19:45:07 zmatt: but it's *very* unlikely, given that it all works if running slightly slower Jan 27 19:45:23 zmatt: transmitting over the DAT line is also crystal clear Jan 27 19:45:48 zmatt: and it's always in that packet in those bits - the beginning of the packet is fine and the end is too Jan 27 19:46:06 zmatt: the clock is external, it comes from an sd host adapter Jan 27 19:46:21 dury: yes, a few years sounds about right Jan 27 19:46:24 you want PRU to pretend to be an SD/SDIO card basically? Jan 27 19:46:28 zmatt: right Jan 27 19:46:29 ok Jan 27 19:47:00 still sounds like signal integrity to me, intuitively Jan 27 19:48:08 what's your overall hardware setup? Jan 27 19:49:01 zmatt: I just took a photo today, let me upload Jan 27 19:49:41 zmatt: csgraf.de/agraf/sdemu/cap_rpi.sr Jan 27 19:49:44 zmatt: that's the full capture Jan 27 19:50:51 .sr extension which applications opens that agraf? Jan 27 19:51:31 agraf: how do you generate that signal trace? is it part of the beaglebone software? Jan 27 19:51:42 sigrok apparently Jan 27 19:51:43 dury: that's sigrok Jan 27 19:52:07 raffo: the trace is done using another beaglebone with beaglelogic Jan 27 19:52:42 ah, even more opportunity for signal integrity issues Jan 27 19:53:08 zmatt: http://csgraf.de/agraf/sdemu/sdemu.jpg Jan 27 19:53:53 jeeesssuuuusss Jan 27 19:54:20 zmatt: sure, and if there was a tiny glitch here and there I'd totally say it's signal integrity Jan 27 19:54:45 zmatt: but suddenly seeing a signal that almost looks like PWM on a line where it shouldn't appear seems outside that scope Jan 27 19:54:58 what makes you think signal integrity issues manifect as glitches? Jan 27 19:55:49 lemme re-read what you said about what you intended to transmit Jan 27 19:55:56 what cape is that btw? custom? Jan 27 19:56:06 zmatt: it's custom, yes Jan 27 19:56:21 zmatt: basically just wires from something of the shape of a micro-sd into the BBB pins Jan 27 19:56:34 is there a ground plane? Jan 27 19:56:37 zmatt: yes Jan 27 19:57:08 in fact, there are two ground planes ;) Jan 27 19:57:12 uhh Jan 27 19:57:18 explain? Jan 27 19:57:26 well, it's a two-sided board Jan 27 19:58:49 with ground plane I mainly meant one below the traces to act as return current path, ground fill on the signal layer probably doesn't have much influence (unless you managed to make an antenna ;-) Jan 27 19:59:10 oh~ Jan 27 19:59:24 no, the traces are really just free floating Jan 27 19:59:37 can I see the pcb layout? Jan 27 19:59:44 sure Jan 27 20:00:06 brb Jan 27 20:01:18 zmatt: https://www.dropbox.com/sh/o1k64kcd7tstvzw/AAAJJKBlp09jcyFUbXaDgJrXa?dl=0 Jan 27 20:06:21 hmm, an export in pdf or image format would be nice, I don't have any schematics/pcb software installed on my laptop Jan 27 20:08:07 zmatt: my kicad foo is very bad - i had to ask a friend to design this thing for me :) Jan 27 20:08:26 zmatt: basically it really is just wires going from the microsd plug thing into the beaglebone pins Jan 27 20:08:56 zmatt: http://paste.opensuse.org/view/raw/76585830 Jan 27 20:09:09 zmatt: this is the original mapping table Jan 27 20:09:29 I understand, but the devil is in the details Jan 27 20:10:16 actually, there's a bug in that map Jan 27 20:10:47 zmatt: http://paste.opensuse.org/view/raw/43705685 Jan 27 20:10:54 (also, just a random remark, apparently the "EDIO" functionality in pruss (part of IEP) supports direction switching without having to meddle with pinmux. haven't had time to experiment with it myself though) Jan 27 20:12:08 zmatt: that's what it looks like today - the CLK for PRU1 is routed to P8.15 in the original design (the board I have), I soldered a small wire from P9.31 to P9.26 to fix that up Jan 27 20:12:28 zmatt: but the effect you're seeing there happened with longer clk wires too ;) Jan 27 20:12:54 zmatt: and yeah, I haven't really found any good documentation on EDIO at all and the bitbang approach seems to be feasible enough Jan 27 20:13:01 zmatt: even pinmuxing isn't as bad as I though it would be Jan 27 20:13:05 thought* Jan 27 20:13:43 pruss can't do pinmuxing by itself though I think? due to the privileged-writes-only restriction of the control module? Jan 27 20:15:20 zmatt: yes, I have a trivial irq handler in the linux kernel on the arm core Jan 27 20:15:31 ah, yeah that's one option Jan 27 20:15:55 my thought would have been to setup a privileged edma job for it that pruss can trigger Jan 27 20:16:58 isn't the linux irq latency potentially going to be a problem? Jan 27 20:17:10 i think i tried something like that too and then resorted to the irq approach Jan 27 20:17:16 but i don't remember why - it's been a while Jan 27 20:17:37 hmm, kicad wants 700MB of disk space... not going to install that Jan 27 20:22:29 a screenshot maybe? your photo is just too blurry to really make out sufficient detail (pretty nice looking faceted blur though) Jan 27 20:22:35 (of the pcb) Jan 27 20:23:16 maybe I'll just install kicad anyway, I see I have more free disk space than I thought Jan 27 20:25:36 zmatt: it's probably much smarter to install kicad, yes :) Jan 27 20:27:11 zmat, agraf, is kicad a cad application? Jan 27 20:27:13 signal integrity issues can be quite interesting.... https://liktaanjeneus.nl/with-terminator.png https://liktaanjeneus.nl/without-terminator.png Jan 27 20:27:39 (this is really completely dissimilar to your situation, but I thought it was funny enough to share ;) Jan 27 20:28:57 http://kicad-pcb.org/ Jan 27 20:29:18 sorry Jan 27 20:29:24 zmatt: http://csgraf.de/agraf/sdemu/top.png Jan 27 20:29:30 zmatt: http://csgraf.de/agraf/sdemu/bottom.png Jan 27 20:34:51 apt-get install kicad Jan 27 20:35:00 success Jan 27 20:37:37 exit Jan 27 20:38:08 be back tomorrow... take care all Jan 27 20:42:23 agraf: ok, so cmd and clk run parallel to each other Jan 27 20:42:46 unlike the data lines Jan 27 20:44:06 yes Jan 27 20:44:44 and I see no grounding between them Jan 27 20:45:07 and the grounding on this pcb definitely looks iffy, though I'm still trying to grasp the big picture of what is going to happen Jan 27 20:46:51 they have an image plane for most of their length, but a giant cut in it that will do an excellent job at blocking return current flow Jan 27 20:51:22 huh, the sd card protrusion has the same tracks on both sides? o.O Jan 27 20:52:39 i think it just looks like that in kicad Jan 27 20:52:46 the actual board doesn't Jan 27 20:53:39 presumably it can't even, since that part is thinner Jan 27 21:02:09 anyway, yeah this looks like a recipe for signal integrity issues Jan 27 21:03:36 I can think of things that could help, but it's hard to assess their impact without a scope Jan 27 21:03:54 also beware that the attached beaglelogic may be making things worse Jan 27 21:06:12 zmatt: yeah, the main problem without beaglelogic is that I'm slightly blind :) Jan 27 21:06:27 zmatt: last time i tried without it didn't make a difference, it seemed to fail the same way Jan 27 21:06:32 zmatt: but I obviously couldn't tell for sure Jan 27 21:06:45 zmatt: so what do you think would help? Jan 27 21:07:00 zmatt: apart from redoing the pcb with proper ground plane everywhere ;) Jan 27 21:11:43 ok, made better images to examine the situation... https://liktaanjeneus.nl/data/public/LTEoKlJJmDpmeCYb/ Jan 27 21:12:06 403 Forbidden Jan 27 21:12:51 uhh, messed up that url, remove the data/public Jan 27 21:15:01 so, if your look at cmd and clk on the bottom layer, you see they have a ground plane beneath them most of the time, but it gets interrupted several times Jan 27 21:16:37 and if you look at the top layer, the long middle section barely deserves the name "ground plane" since there's no actual connection to ground (of side bbb or rpi) anywhere remotely nearby Jan 27 21:16:52 it's a big island Jan 27 21:18:11 zmatt: uh Jan 27 21:19:10 zmatt: i don't see it :) Jan 27 21:19:23 zmatt: so in the bottom layer, i don't see any ground plane between cmd and clk Jan 27 21:19:33 I didn't say between Jan 27 21:19:35 I said beneath Jan 27 21:19:39 oh~ Jan 27 21:19:59 or, strictly speaking "above" I guess since the plane is on the top layer Jan 27 21:22:24 ok, so i see that one now :) Jan 27 21:22:40 what about the ground plane on the top layer? Jan 27 21:22:49 that one is connected to the SD ground, isn't it? Jan 27 21:23:10 try to find the shortest path :) Jan 27 21:23:42 you mean in the middle where the white lines are? Jan 27 21:23:53 that's the top left ground pin i guess ;) Jan 27 21:25:06 and since the bottom plane also has a giant cut, the most convenient path back to the sd ground pin might actually be through the beaglebone's ground plane ;) Jan 27 21:25:59 except there's another nice way for return currents for the clk pin to flow Jan 27 21:27:43 namely capacitively couple, directly or via the "ground" island, to the cmd line, which you're driving low at the time of the spurious highs Jan 27 21:28:26 this is probably made worse by the overshoots the clk line probably has Jan 27 21:30:13 I'm not sure how best to patch this... somehow bridging the gaps doesn't seem very easy Jan 27 21:30:17 what's an overshoot? Jan 27 21:30:51 https://upload.wikimedia.org/wikipedia/commons/thumb/0/0e/Clock_signal.png/300px-Clock_signal.png Jan 27 21:31:08 ah :) Jan 27 21:32:09 generally countered by inserting a small resistor near the driving side of a line Jan 27 21:33:04 do the pullup/down resistors in the BBB count for that? Jan 27 21:33:09 though it's the receiving end Jan 27 21:33:17 no Jan 27 21:33:46 note I mean series resistor (a "small resistor" to ground or vdd would make the driver very unhappy) Jan 27 21:36:50 so i should also disable the pullup/down resistor in pinmux when sending? Jan 27 21:37:10 for cmd Jan 27 21:37:34 the internal pullup/down resistors are very large (~100K, although very imprecise) and will have negligible effect here Jan 27 21:37:45 ah, o Jan 27 21:37:46 ok* Jan 27 21:38:15 although in open drain mode (during initialization) there *are* supposed to be pull-ups on cmd and data lines Jan 27 21:38:46 just curious, what's the end-goal of this project? Jan 27 21:39:11 the end goal is simulation of an sd card for automated testing Jan 27 21:39:42 if I ever get there ;) Jan 27 21:40:40 zmatt: so you're saying the next thing you would try is to resolve the ground planes? Jan 27 21:43:10 yeah, so without considering how the pcb might have been done better overall the first quick patch in the layout I'd so is insert vias to stitch the bottom and ground planes together, especially whenever one of the two is getting interrupted... although probably there are more improvements that can be made Jan 27 21:43:24 *I'd do Jan 27 21:46:44 and insert series resistors near the host-side of clk and near both sides for data lines... if they turn out unnecessary then you can just place 0ohm there, but at least during prototyping you want to have the option available Jan 27 21:47:23 unfortunately all these changes seem to be hard to fix without redoing the pcb :/ Jan 27 21:47:41 zmatt: I've had this project going for a while, redoing the pcb isn't too bad :) Jan 27 21:48:00 also, I see a Y-split on data lines.... don't Jan 27 21:50:10 zmatt: so you'd chain them? Jan 27 21:50:25 why do you need two destinations for data? Jan 27 21:51:06 these lines should be point-to-point normally Jan 27 21:53:07 interesting how clk has actually been daisy-chained, hadn't noticed that yet Jan 27 21:53:38 zmatt: because I need to process the cmd line on pru0 and data on pru1 Jan 27 21:53:47 zmatt: unless I'm in SPI mode, in which case I want to use the SPI-IP Jan 27 21:54:07 zmatt: so I need to route the DAT lines to pru0 for SPI and pru1 for SD mode Jan 27 21:54:20 spi mode? isn't that a thing of the ancient past? Jan 27 21:54:28 i wish it were so ;) Jan 27 21:55:21 ugh Jan 27 21:55:36 maybe you can get away with it, dunno up to what frequency though Jan 27 21:56:33 a Y would probably be preferred to a daisy-chain Jan 27 21:57:59 so, here I'm in uncertain territory... I know a fair bit about how to do it Right™, but I don't have much intuition with what exactly you can get away with (even if strictly speaking Wrong™) Jan 27 21:58:15 I've seen things that couldn't possibly work, but did Jan 27 21:59:00 but in other cases, simple circuits at pretty low speeds had plenty of trouble Jan 27 22:01:00 :) Jan 27 22:01:09 ok, I'll see if I can get it redesigned Jan 27 22:01:16 let's see what happens Jan 27 22:01:24 I can always keep working on the code at lower speeds Jan 27 22:02:31 http://www.ti.com/lit/an/spraar7f/spraar7f.pdf might be useful Jan 27 22:02:54 not all of it.... I wouldn't worry about fiber weave :P Jan 27 22:05:13 hmm, in my memory more of this was useful than it seems now... quite a bit of this is for considerably higher-speed signals than yours Jan 27 22:15:52 btw, I don't know if those thin strips of "ground" between data lines actually do good or harm, but at the very least they should be stitched to the real sd ground at the first available opportunity Jan 27 22:47:05 zmatt: thanks a bunch :) Jan 27 23:19:26 zmatt I see you still live here :D Jan 28 00:29:20 agraf: still here? Jan 28 00:36:11 agraf: in my pile of scope pics I found this nice one, which shows how distortion can "creep in" over the course of several cycles: https://liktaanjeneus.nl/2017-01-05-130140.png Jan 28 00:36:29 notice the quite strong history-dependence Jan 28 00:47:20 clean version of similar signal for comparison -> https://liktaanjeneus.nl/2017-01-05-130358.png Jan 28 00:47:34 (amplitude reduced due to termination) Jan 28 00:51:48 GenTooMan: part-time :P Jan 28 00:52:32 agraf: the difference between those two images btw is a 100 ohm resistor ;) **** ENDING LOGGING AT Sat Jan 28 03:00:02 2017