**** BEGIN LOGGING AT Tue May 16 03:00:03 2017 May 16 09:02:04 Hello. In CCS when JTAG is enabled is it possible to 'capture' ASM instructions executed during an arbitrary length of time? May 16 18:48:25 gquere: no, cpu trace data from ETM only goes to the ETB (embedded trace buffer) May 16 18:50:23 gquere: however, iirc you *can* have trace running continuously and then halt trace on (or a specified amount after) an event of some sort, thus giving you a trace of what the cpu was doing right before the event was triggered May 16 18:52:18 zmatt: in that context, what is an event? (wfi type instruction? or real HW event like GPIO flipping) May 16 20:13:32 ds2: I don't have the full details fresh in memory, except that there are quite a few possibilities May 16 20:14:19 you should be able to use an external hardware trigger as well, at least via EMU0 or EMU1 May 16 20:52:53 Howdy May 16 22:40:44 My BBB Rev C that I have operated for ~4 years as a Ninjablock succumbed to the same fate described here: https://groups.google.com/forum/m/#!category-topic/beagleboard/support/jBFshjlPeHI Anyone had this issue? Is there a common failure point and, if so, is it repairable? May 16 22:50:53 apacheguy: tip: you'll typically get a quicker response if people don't have to click links just to know what your question is May 16 22:51:59 Thanks @zmatt. Issue is a single flash of the power LED when power is supplied. Board does not boot due to power failure May 16 22:52:06 also that thread describes something quite unusual (not the power led blip of doom itself, but the "Doing that repeatedly seems to have revived the board") May 16 22:52:40 Yes. In my case doing so repeatedly did not revive the board May 16 22:53:14 power led single flash indicates an overcurrent situation immediately at boot (typically when the 3.3v supplies come up), causing the PMIC to immediately cut power again. May 16 22:53:35 Ok. So sounds like there is a short May 16 22:54:05 assuming external causes (i.e. a CAPE or other stuff on the expansion headers) has been ruled out, the typical cause is an internal short inside the processor due to a damaged I/O cell May 16 22:55:10 Yeah, so CPU failure. In theory, if one were to replace the the CPU would the board work again? Probably not worth the cost and effort, just curious May 16 22:57:50 I even know of one funny case where someone accidently managed to "repair" an am335x with this type of damage by vaporizing the short with heavy current :) this is not a recommended repair procedure ;) May 16 22:59:02 replacing the SoC would probably fix it, unless whatever damaged the SoC also caused damage elsewhere, but would indeed not be worth the effort May 16 23:00:48 lol, yeah. either repair procedure is above my pay grade. good news is the replacement beaglebone already arrived and my Ninjablock is back in operation May 16 23:01:25 maybe try to figure out what caused the failure May 16 23:03:19 overvoltage is the most common way to kill an I/O (and if you have bad luck, the whole SoC as a side-effect) May 16 23:04:38 Overvoltage is possible, but unlikely. The power supply is connected to surge protection May 16 23:05:33 hmm, I meant more on I/O.. the pmic has overvoltage protection on the power input.... what kind of external connections did it have? May 16 23:06:31 ah. well, it is connected to a ninjablock cape. that's it. and ethernet May 16 23:07:06 and ninjablock cape is totally fine. works great with the new BBB May 16 23:08:37 never heard of it May 16 23:08:54 have a link? May 16 23:09:07 they went out of business. it's basically a 433 mhz send/receive cape May 16 23:09:23 https://ninjablocks.com/ May 16 23:09:31 which revision? May 16 23:09:55 the BBB? Rev C May 16 23:09:57 (apparently there's 1.0, 1.1, 1.2, 1.2.1) May 16 23:09:58 the cape May 16 23:10:08 Ah, I belive 1.2.1 May 16 23:10:30 meh, no pdf export of schematic May 16 23:11:15 ah, or maybe May 16 23:11:42 no pdf, but schematics available: https://github.com/ninjablocks/hardware/tree/master/Ninja%20Blocks%201.2.1 May 16 23:11:50 there's also "RF cape" in their github May 16 23:12:32 pff, disorganized dump of files May 16 23:13:12 yeah, oh well. it worked for ~4 years and then failed. I'll reevaluate after another 4 years if it happens again May 16 23:15:16 heh, fair enough May 16 23:15:57 assuming this is the right schematic they seem to be driving leds directly from gpios... that's not recommended May 16 23:16:54 I usually have the LEDs switched off on the cape May 16 23:19:05 oh well, we killed two beaglebones at work today, I think in less than an hour time May 16 23:19:14 and assaulted a third one May 16 23:20:50 ouch, makes me feel better May 16 23:21:37 hehe May 16 23:23:17 ah, that was the thread I mentioned -> https://e2e.ti.com/support/arm/sitara_arm/f/791/t/469604 May 16 23:23:47 apparently the pmic they used doesn't cut power, so they simply noticed the 3.3V supply was a bit low... 0.4V May 16 23:24:46 hooked up a beefy 3.3V supply which briefly got to deliver 3A... and voila, fixed ;) May 16 23:25:44 yikes. good ref at any rate. thanks May 16 23:27:14 I find the notion quite amusing... board (probably) damaged by overvoltage, "repaired" by overcurrent May 16 23:27:51 minus some esd protection diodes presumably **** ENDING LOGGING AT Wed May 17 03:00:03 2017