[ot][spam][crazy] The Trials of Controlling a Programmer
I have an LPC flasher (a chip programmer) I've been using to learn coreboot and to try to drop a little life into an old board. After a month or more of use, my programmer just won't program anymore. When I try to flash things flashrom complains that no flash chip was detected. Note: the spacebar on my hardware-keyboard phone is also breaking, so I may be less verbose. Similarly, my raspberry pi won't seem to load gnome, and I still haven't figured out how to get neomutt to download email. The neomutt challenge seems the easiest, but is kind of different. Anyway, the programmer is breadboarded based on a teensy board, and the LPC socket was sometimes showing the issue previously, refusing to find the LPC chip unless I reinserted it a number of times. Long ago I would have been excited to troubleshoot an LPC socket. It would perhaps have been an excuse to build a logic analyser with tiny LPC leads. Nowadays most of my brain refuses to move carefully with intensity comparable to trauma, and for that and other dangerous and unknown reasons, my hands and fingers shake and jerk and my visual perception is quite poor, partly from my eyes doing the same. This coreboot task has been really great. It can be many months between having a project that feels like a doable, productive challenge, where I can often barely control my body let alone my mind. But I need a programmer if I want to keep porting the bios for my motherboard. I used some small jumper wires to try to test some of the leads around an lpc chip once. Unfortunately I didn't verify the chip wasn't one I had burned out, a different issue. Additionally, I wasn't [amnesia shift here, hello! we're describing working on fixing the plcc flasher] sure my jumper wires were touching the chip and not the socket which are very very near. But I did try to gently bend some leads to resolve connection issues, and thinking on that I guess that means I might have a way to consider whether I'm testing the chip leads or socket leads. Anyway, it still didn't work,even with a known-working chip, but I didn't examine it with a known-working chip. Then later, I tested connections from the chip seating all the way to the teensy board, and found a number that were failing due to wear on the breadboard, and adjusted and squeezed these until they conducted. But it still wouldn't detect a known-working chip. I then removed it from the breadboard and wired it up hanging in the air with female jumper wires. This is not working either. I also have two pcbs of this tool I tried to solder, but I have broken the smd pads off on both from being uncareful while doing so. When I try to be careful, it can stimulate my spasms further in various ways, a gently developing frustration of some years now. There used to be sold flashers for LPC chips, but I haven't found any, which is a blessing in some ways, for open hardware and all. I was thinking of buying an arduino, for which flasher code exists. I actually should _have_ arduinos somewhere, unused for years, uncertain where. I was also thinking of porting a flasher to use my raspberry pis gpio pins. But these other flasher board ideas don't seem to have much return right now, when I have reason to believe the problem could be in the socket. I also have a small handful of smd sockets. Hard to solder without a pcb. I could also attempt to desolder the pcb from my breadboardable socket. I think another breadboardable socket is in the mail, but I worry I will forget I am working the task if I stop working it. I'd like to compare the electrical activity at the chip pins to what the device is supposed to send somehow. Maybe I could try to add debug information to flashrom's serprog protocol, although I'm feeling that might be inefficient.
the LPC socket was sometimes showing the issue previously, refusing to find the LPC chip unless I reinserted it a number of times.
But I did try to gently bend some leads to resolve connection issues, and
thinking on that I guess that means I might have a way to consider whether I'm testing the chip leads or socket leads.
Then later, I tested connections from the chip seating all the way to the
teensy board, and found a number that were failing due to wear on the breadboard, and adjusted and squeezed these until they conducted. But it still wouldn't detect a known-working chip.
I then removed it from the breadboard and wired it up hanging in the air with female jumper wires. This is not working either.
It sounds like there are two issues: a failing socket, and failing wire connections. Not considering that there are likely two separate kinds of issues could have worsened the confusing frustration.
I'd like to compare the electrical activity at the chip pins to what the
device is supposed to send somehow.
Maybe I could try to add debug information to flashrom's serprog protocol, although I'm feeling that might be inefficient.
It's important to eventually have logic debugging. But maybe something more reusable than serprog additions. Thinking about testing manually vs building or finding logic probing tools, one thinks about time. Both tasks are slowed from human issues. I bet there's existing code to use raspberry pi as a logic analyser somewhere ... but I'm unsure if the frequency will be sufficient without learning the flashing protocol. Learning the protocol would normally be expected for hobbying this. Thinking on manually testing things with more rigor. Ensuring the chip used works. Considering every pin in all the ways, and verifying they all work before a test. It's frightening to think of putting all that work in and having it still possibly fail for unknown reason, but it may be an important and rational diagnostic step. One that has not yet been done.
I'm reading a little about breadboard reliability and learned it's important not to put square header pins in the breadboard's round holes, that this will break them. I did not know this. I'm also using lower utility stranded jumper wire with the solid tips that comes with hobby kits, from my nyansat attempt.
Breadboard purchasing tips from https://forum.arduino.cc/t/good-quality-breadboards/539538/9 This is also of interest to me because I almost completed a 12dof quadruped robot for my niece and nephew during my chemotherapy, but then got confused and stopped associated with breaking the prototype controller, which I had foolishly soldered onto a wire wrap board, not knowing how to use one.
I've seen 3M and Global Specialties recommended.
recommend the K&H AD-series breadboards, they have 6 tiepoints per strip
breadboards made by Osepp are pretty reliable.
have found that the breadboards with the model number, “ZY-201”, available on ebay, work well
would recommend BusBoard. They have good breadboards and they last long.
wirewrap:
Green PCB is from Velleman,
https://www.vellemanusa.com/products/view/?country=us&lang=enu&id=350322 15 <https://www.vellemanusa.com/products/view/?country=us&lang=enu&id=350322>
ECS 1/2 it's called, very good quality, holes very even spaced and pads are also very good.
Wirewrap sockets and wirewrap socket strips, 30 AWG wire, and wrapping tool can be found here.
https://www.peconnectors.com/wire-wrap-sockets-and-headers/ 22 <https://www.peconnectors.com/wire-wrap-sockets-and-headers/>
I use the Gold colored tool on page 2. Stripper built into the handle.
I'm thinking it could make sense to tin a small strand of wire to make a fine probe, and see if I can detect activity on any of the chip's pins when the programmer probes it, using my cheap pocket oscilloscope. Doing that, I expect to find a way to use my oscilloscope to make a log of logic behavior on a pin. Maybe I could then log the logic behavior of all the pins. I glanced at the source code, and it looks like it uses bitbanging to set each clock tick, without regard to a constant time base or anything. I could glance a little further to see what kind of activity is expected on each pin. I could also attach leds to see the activity, if I have any.
I found a higher quality breadboard I didn't know I had. It also shows I have higher quality wire somewhere (some is in it). Plan is to move the project to this breadboard, kicking out the unutilised nyansat work already on it.
It's always exciting to use an oscilloscope or logic analyser. Before I lost my mind, I had just barely started using them. 0629 ET. 0631 ET. The jumper wires I'm using are square tip. Lucky I noticed before putting many of them in the other breadboard. I guess maybe I'll test with the already-impacted breadboard for now. 0632 ET.
In addition to the programmer issues, after the work, the flash chip I wanted to use appears to be broken. It is a relief to diagnose that component, because it is hard to make a programmer write to a nonresponsive flash chip. I was testing with a working flash chip. Multiple issues. All resolvable!
I have this jerry-rigged enough to have satisfaction for a bit now, by stashing the factory rom off a factory chip and repurposing it. I had a factory chip that wasn't working for me, and after my experience examining things, I noticed one of the leads had slightly bent and was in danger of shorting when not used carefully. I bent it back and am curious if the other board on which I thought the socket was broken, might work again. I also have some little experience now resoldering these, if I do end up replacing that socket.
I haven't made much progress since I found a way to continue on this. I've been stuck horizontal, my body writhing. But it's still so much fun to know I found a way forward :) It's just nice to think about. When my setup stopped working it was so frustrating, and now I can continue again! While I was working recently I accidentally put my last flash chip in backward and powered the system up. When you do this the chip begins bheating up rapidly and then burns out. I walked away, not realising, and then turned around and pulled it out before it burned out. It was a big relief. I had identifying tape on the chip that partially melted. It still works though! I wrote some assembler code to boot up the serial port before the ram was initialised, to debug early boot, and after using the setup to verify it worked I shared it with the devs, but just casually not with a pull request yet. I've realised while daydreaming and such that the code has a bug that doesn't express: it checks for the serial data port being ready using the 8-bit port command rather than the 16-bit one. So it's actually reading from the wrong io port (8-bit truncated) and waiting for timeout rather than detecting readiness. I don't know why I didn't notice a compiler error, passing a 16-bit port number for an 8-bit operand. Today I'm expecting a cheap breadboard in the mail to replace the ones that might be broken, and tomorrow a set of round pin headers to use as buffers to prevent breaking the new breadboard with square pins.
I've gotten a little confused around this project. I was using an olimex teres as my serial terminal. The teres is not presently charging. When powered, smoke is emitted from a large rectangular component between mainboard labels 'D1' and 'DC5'. I'm thinking it makes sense to work on my teres, rather than continuing the coreboot work. Don't want to increase the number of things I have and am using, that are broken. The teres has a recently replaced mainboard and charger, so the failure is unexpected, but could be a developing problem from an error made during assembly.
The smoking component is labeled 'KG' with a small picture under the label, kind of like an ear of corn or a 4-armed spirograph. Hilariously, there is a spot next to the component labeled 'FUSE' which is empty, nothing soldered in.
Looks like the component i'm guessing is smoking is https://www.digikey.com/en/products/detail/stmicroelectronics/SMBJ6.0A-TR/63... -- a big diode intended for surge protection or something. Some of the amperage columns in the datasheet mention low values, microamps and milliamps. This isn't really what I'm prepared to diagnose. I didn't learn a lot of electronics before going crazy. I wish I had some idea what caused it to fail.
The schematic for my currently-not-charging-teres-mainboard is at https://github.com/OLIMEX/DIY-LAPTOP/blob/rel3/HARDWARE/A64-TERES/TERES-PCB1...
The diode D1 and the power supply are in the upper left corner of page 4 of that schematic. It appears to connect +5V to GND. Looking up diode polarity, it looks like that diode is reverse polarised. I vaguely recall that diodes have some use when placed backward. Usually one thinks of a diode as only allowing current in the forward direction, and preventing it in the backward. If my diode broke, maybe it would be acting as a short, producing the smoke from current rushing through it to ground.
[If the diode is broken, I have other mainboards and could try to transfer the same diode over. But the issue must have been caused by something.]
The diode is conducting in both directions, so it is broken. This can likely also be inferred from the smoke. The datasheet for this diode is at https://www.st.com/content/ccc/resource/technical/document/datasheet/19/78/9... The datasheet has a picture on the second page, of typical voltage/current curves for bidirectional and unidirectional devices. Pretty sure a diode is a unidirectional device. The curves include both negative and positive voltage and current. I'm guessing that chart is displaying positive forward voltages to the left of the Y axis, and negative or reverse voltages to the right. Not totally sure. It looks like there is a minimum voltage called V_F needed for the diode to conduct in the forward direction, and a maximum voltage called V_RM (maybe safety), and V_BR (breakdown), above which it will conduct in the reverse direction, and it roughly doesn't conduct in-between these voltages. With my diode broken, it seems this would imply that it was provided excess voltage in either direction, producing enough current to melt its innards. I'm using the factory-provided charger. It's probably been plugged in for weeks. There were various issues before this failure. Notably the power LED would blink red and the system would power off, while it was running. The charger right now is behaving in a funny way, where its green light is pulsing on and off. Measuring the voltage shows at the start of a pulse, it gives the correct 5V, and then this quickly drops to zero for the rest of the pulse. When connected to the shorting diode, it provides about 2.8V across it, continuously, while making a strange staticy noise at the wall. On the third page of that datasheet, the diode electrical characteristics are given. This is a SMBJ6.0A, so it looks like V_RM=6.0 V, V_BR=6.70-7.05 . I'm guessing that V_F is so small it doesn't matter. There's another item in that graph on page 2. I_PP, the peak pulse current, and its voltage V_CL, which they call the clamping voltage. Not sure what that means precisely, but on page 3 it has footnotes regarding their numbers:
3. To calculate V_CLmax versus I_PPappli: V_CLmax = V_CL - R_D x (I_PP - IPP_appli) where IPP_appli is the surge current in the application 4. Surge capability given for both directions for unidirectional and bidirectional devices
There are two values given for I_PP, V_CL, and R_D . One labeled 10/1000 us, and one labeled 8/20 us. I'm guessing that's the duration of the surge. The SMBJ6.0A has these numbers: 10/1000 us: V_CL = 10.3 V I_PP = 61 A R_D = 0.048 Ohm 8/20 us: V_CL = 14.8 V I_PP = 270 A R_D = 0.027 Ohm It sounds like this device will break if more than 10 V is applied for more than 1 ms, in either direction. I'm not sure of this, though. With a little bit more reading, maybe I could calculate how much current and heat is generated if the laptop is reverse-powered, and whether that would break it or not. -- Another thing going on is that I had the laptop plugged into the old RS-232 serial port of the mainboard I'm poking at, via a usb-serial adapter. Additionally, the laptop charger is ungrounded. An RS-232 serial port can have voltages between +-14V of ground. And I'm wondering if the ungroundedness of the laptop could have produced a different ground between them, and maybe a strong ground current when the cable was replugged. I don't really know. But after reading about this, and seeing it needed >10V difference to likely burn, I'm going to be thinking there's a reasonable chance it's either the grounding or some voltage from the RS-232 port escaping through the usb adapter. I'm also thinking that's most likely to happen when I hard repower the mainboard, which I am doing a lot. When I repower the mainboard, I often see garbage on my serial terminal, and sometimes the terminal is strangely forced to close. This is supporting information that there could be voltage spikes coming in through USB. ---- Whew ! :)
omigod I replaced D1 with one from a broken board and it actually fixed everything. I was lucky I happened to pick a board broken from a different issue. It was hard to do the soldering. It has a mess of solder around it now. I found I have another board that also has a burnt out D1. I suspect it could be repaired the same way.
Mysteries That Could Be Solved I have two firmwares. The official release from many years ago, and the new code I'm porting from recent months. I've modified both of them to run the exact same assembler on boot. However, the addresses the entry point jumps to find it are different, due to different rom layouts from other code that would be run later. The old official code functions. The newer ported code does nothing. I've visually inspected the assembler and the bytecode, and they appear bit-for-bit identical to me, aside from the initial jump instruction. It is completely possible to troubleshoot the issue, by finding what set of changes from the working bytes, to the failing bytes, trigger the failure.
[spam] The old, working jump address is fffff838. The new, failing jump address is fffffab0. The jump instruction itself is stored at a special address and its operand is offset by a specific amount from the absolute address it jumps to.
[spam] There are 4 bytes at the end of the roms that differ by a nonparallel amount. It's likely the reason for the change. I was maybe looking at the reset code, and these bytes are maybe the entry address at boot.
[spam] nope! mutating these bytes seems to do little to the area of code i'm attending to. I get to mutate the jump address.
[spam] coda on the jump address stuff: it turns out my southbridge reads a data table to initialise the cpu before boot. providing this table seems to get the new layout to run at boot (although earlier changing the jump address seemed to do it, and no longer does. I infer I was cross-eyed again earlier, but a third check is needed.) I still don't understand all the parts, but the southbridge information is enough to make the problem much more manageable. -- regarding the programmer, the headers that arrived are square pin. I can use male-female jumper wires though. apparently I also ordered backup sockets, so I can in theory troubleshoot the hardware programmer issue now, by swapping components. to do these tests I was flashing with the internal functionality of the board itself which involves a boot cycle every test.
So, this isn't really using a programmer at the moment, but spamlogging this kind of perception can often resolve it. I'm trying to write assembler so that my bios post codes are written to my serial port. I spent many days fixing things to try to debug it. I presently have two implementations. One works, the other doesn't. However, it seems the two implementations are exactly identical, as far as I can tell. The working one was slowly migrated from code that worked already. The failing one was copied over by me earlier. I've mutated them to be identical, and the failing one is still failing, while the working one is still working. I had the working one preceding the failing one, and only one character was output. When I duplicate the working one, there are two characters. When I remove it, there is one. But get this: when I copy-paste the failing one to come before the working one, I get an additional character from that. You'd think it would be something after the working one, and before the failing one, but they appear completely identical. Since writing your own bios is an unlikely task to complete in a timely manner without experience, it seems to make sense to try to troubleshoot this further. I'm not planning on investigating the per-clock-tick behavior of the cpu. But I am interesting in finding a property of the source code that distinguishes whether or not it works when run. If that property is where its source code bytes came from, that would be interesting. In such situations one can seem very likely to experience a delusion, which are also helpful to sort out. I'm logging the terminal output of the development and run system, and the serial system accessing it, and both systems are airgapped. So there's something to check what is real at least a little bit more.
On Wed, Mar 30, 2022, 5:34 PM Undiscussed Horrific Abuse, One Victim of Many <gmkarl@gmail.com> wrote:
So, this isn't really using a programmer at the moment, but spamlogging this kind of perception can often resolve it.
I'm trying to write assembler so that my bios post codes are written to my serial port.
I spent many days fixing things to try to debug it. I presently have two implementations. One works, the other doesn't.
However, it seems the two implementations are exactly identical, as far as I can tell.
The working one was slowly migrated from code that worked already.
The failing one was copied over by me earlier.
I've mutated them to be identical, and the failing one is still failing, while the working one is still working.
I had the working one preceding the failing one, and only one character was output.
When I duplicate the working one, there are two characters. When I remove it, there is one.
*when I remove it, there anone.
But get this: when I copy-paste the failing one to come before the working one, I get an additional character from that.
You'd think it would be something after the working one, and before the failing one, but they appear completely identical.
Since writing your own bios is an unlikely task to complete in a timely manner without experience, it seems to make sense to try to troubleshoot this further.
I'm not planning on investigating the per-clock-tick behavior of the cpu. But I am interesting in finding a property of the source code that distinguishes whether or not it works when run. If that property is where its source code bytes came from, that would be interesting. In such situations one can seem very likely to experience a delusion, which are also helpful to sort out.
I'm logging the terminal output of the development and run system, and the serial system accessing it, and both systems are airgapped. So there's something to check what is real at least a little bit more.
0539 I copied the working block below the failing block. The blocks are now: 1 copied from failing 2 working blocks 1 original failing block 1 working block This is producing 4 characters of output, from 5 identical blocks. A working theory is that only the original failing block is failing, which can be tested by removing it. An alternative theory could be that only the last block is failing. A tertiary theory could be that a different block is failing each time, or that it the unexpected output is unrelated to failure of a block. As I type this I will likely make errors from my perception issues.
On Wed, Mar 30, 2022, 5:42 PM Undiscussed Horrific Abuse, One Victim of Many <gmkarl@gmail.com> wrote:
0539
*1739
I copied the working block below the failing block.
The blocks are now: 1 copied from failing 2 working blocks 1 original failing block 1 working block
This is producing 4 characters of output, from 5 identical blocks. A working theory is that only the original failing block is failing, which can be tested by removing it. An alternative theory could be that only the last block is failing. A tertiary theory could be that a different block is failing each time, or that it the unexpected output is unrelated to failure of a block.
As I type this I will likely make errors from my perception issues.
1749 Output drops to three when the "failing" block's output line is removed! This means it is not my delusion of it being when and how the source bytes were written, which makes it much easier to troubleshoot. I'm guessing there's some code after all the blocks that quickly removes the character last output. Something nice and logical. Whew.
the coda on that was that due to a recopying error in the code following, a serial configuration port was being written to. this likely was disabling the port before the character was output. -- this morning I found I had left the flash chip in backward all night while the system was powered. however, on replacement, it works fine. I didn't notice it being as hot as it has been, although i've gotten better at protecting my fingers. i wonder about my busted chips. maybe they could have broken some other way, or maybe they aren't broken somehow.
recap: my chip flasher stopped working and I didn't finish troubleshooting it, instead using internal flashing, which is slow. side information: i've started porting serialice to my board, which lets you step through bios firmware and try different images without removing the chip. I got two new sockets in the mail, and a new breadboard. I wired them up but it's still not working. I'm not using the breadboard yet, because the sockets have square pins and I don't want to add points of failure. The most likely candidate for misbehavior is atm the teensy flasher i'm using. This flasher's code is open (the teensy's seems not to be, unsure) was recommended by the community, but they all use internal flashing themselves. There are flashers using the same code for a beagleboard and a raspberry pi. I'm thinking a reasonable next troubleshooting step would be to try swapping teensies out. I also have interest in doing the teensy programming on another system, for convenience and to consider bisecting the system it's connected to as a failure point. It's hard to track possible issues with the wiring, with 32 wires and my hands spasming. It would seem easier on a breadboard. I think it would be helpful to label each wire.
It seems it would be really good to log the pin behaviors at the chip. This is hard for me, due to inhibitions around logic probes. The concept is easier if I split it into two parts. The connection at the chip could be discerned canonically by using new sockets and chips. Then I could add a wire to every 2.54 mm pin to log it, without worrying about surface mount socket stuff.
I have a flasher again !!!! I soldered round wires onto my teensy to function as the round headers I don't have, but then I dropped the teensy approach. In all this exploration, I found there is an old arduino flasher. I happen to have an arduino as the same model as the dev. I looked at his pcb schematic and wired up a breadboard the same way. I put an LPC socket, with its square pins and all, in a breadboard, but was careful never to remove it in case it wouldn't reinsert well. I used the larger breadboard I had gotten for the nyansat kit, which looks higher quality. When wiring it, I used solid core jumper wire from the nyansat kit, and kept the wires flat to the breadboard and short, and of colors consistent with their use, and straight and organised, to easily comprehend them visually. I used a 100nF 104 capacitor instead of the large round 1uF capacitor used in the schematic, which I don't have on hand (although I do have a 10uF, unsure which is better), between ground and 3.3v. To wire the arduino, I had to map the schematic to the shield headers on the arduino. It turns out they are labeled a little wrongly, but visually are aligned to the same locations, looking from above. I happen to have a huge bag of resistors and used the exact 4.7K and 2.2K resistors used in the schematic. Some apear to be 2.2K pullup, some appear to be 4.7K pullup, although I'm never sure of these things, and some are voltage dividers. This made for a little more complicated wiring, and I kept it organised, relatively consistent, and flush with the board. In order to make the arduino flashing code run successfully, I had to replace the serial firmware code on the board with some written by the dev. I was pleased that the dev shared some of my opinions regarding arduino's coding style and quality, which I don't usually encounter. The entire setup can be built and flashed without ever installing java, using only the avr toolchain. The dfu flashing process was a little poorly documented. There is a bad that needs to be grounded called "reset" on the serial chip. This is completely different from the "reset" line of the avr chip on the arduino that is wired to a button. Pressing that button until your finger is sore won't get the arduino into dfu mode to reflash its serial firmware. Rather, the serial reset pad must be grounded or bridged to its neighbor. The board then stays in dfu mode until repowered or instructed to leave. While in dfu mode, I found the serial port kept resetting, and often my kernel driver would get confused and disable it. I tried even with a usb cable that seemed new, and had the same experience. It took some replugging and some timing and repeated attempts to flash the firmware, to succeed, and then it eventually did. The custom firmware flashing step used a "launch" command to the "dfu-programmer" debian binary, which my binary did not have. It looked like this was supposed to be part of bringing the board out of dfu mode correctly, without powercycling it. Replugging the usb cable instead seemed to function fine. Once the board has its serial firmware, and the flashing code uploaded for the main chip, flashrom would only recognise it as a serial programmer if the device and correct baud were specified (115200). This was different from the behavior of the teensy. Additionally, my device was detected as a ttyACM device, whereas the documentation indicated my setup would show as a ttyUSB device. However, it ended up working anyway. An extant bug is that it takes two run cycles to use the programmer with flashrom. The first one encounters a "device or resource is busy" error, and the second works. "fuser" reports nothing else using the port. This has been a silly multiweek struggle for me! I'm excited that the solution I ended up finding uses open source hardware and firmware, and requires no gui tools like teensy's installer. I'm using an arduino uno r3. The custom arduino serial firmware is at https://github.com/urjaman/fast-usbserial . The LPC flashing code and wiring schematics are at https://github.com/urjaman/frser-m328lpcspi . There is further documentation at https://www.flashrom.org/Serprog/Arduino_flasher but note that most of that page is for SPI flashing whereas I have LPC chips. I took a photo of the new flasher but ran into some issues (during brief period, with my EEG off for the photo, my body spasmed and knocked many things on floor, still shaky and anxious from big spasm, other parts of my behaviors acting more inaccurately) and decided not to go through the trouble of uploading it somewhere and linking it here at this time.
My arduino flasher, although I appreciate it, is running into the same issue as the teensy flasher. It says there is no chip when one is there. I've reseated connections that look loose. I've replugged the usb cable. I've reseated the flash chip and verified it's not backward. I've tried a 10uF capacitor instead of a 100nF. I've put tape under the arduino in case it's shorting on something below it. Same behavior. I've also labeled the lines! And plugged in my oscilloscope and wired its probe ground to the board ground. Plan is to plot the clk line just to get comfortably with measuring a logic line.
I'm observing CLK stay low during the chip probe. I was hoping to see a square wave. Makes sense to look at the source as see where CLK is used, I think. On Tue, Apr 5, 2022, 6:40 AM Undiscussed Horrific Abuse, One Victim of Many <gmkarl@gmail.com> wrote:
My arduino flasher, although I appreciate it, is running into the same issue as the teensy flasher. It says there is no chip when one is there.
I've reseated connections that look loose. I've replugged the usb cable. I've reseated the flash chip and verified it's not backward. I've tried a 10uF capacitor instead of a 100nF. I've put tape under the arduino in case it's shorting on something below it. Same behavior.
I've also labeled the lines! And plugged in my oscilloscope and wired its probe ground to the board ground.
Plan is to plot the clk line just to get comfortably with measuring a logic line.
notes: in the flasher source, it's designed for more than one interface, and use of the lpc chip is guarded by this: uint8_t lpc_test(void) { nibble_hw_init(); lpc_init(); if (lpc_read_address(0xFFFFFFFF)==-1) return 0; return 1; } flashrom itself doesn't seem to care about that check (although I haven't looked in the source): it just probes for a bunch of chips anyway. so I guess the thing to do would be to look for the first lines that are engaged, and see where failure starts.
On Tue, Apr 5, 2022, 7:02 AM Undiscussed Horrific Abuse, One Victim of Many <gmkarl@gmail.com> wrote:
notes: in the flasher source, it's designed for more than one interface, and use of the lpc chip is guarded by this: uint8_t lpc_test(void) { nibble_hw_init();
FRAME is driven high for 1us and then allowed to drop for 1us.
lpc_init();
calls nibble_init(): INIT is briefly dropped and then raised. CLK is raised. FRAME is raised. calls nibble_write(0): DATA lines are set high. calls clock_cycle() 24 times. The code for clock_cycle drops CLK then immediately raises it. It goes on with more port writes. I may have made an error in transcribing the above. I'm guessing the clock is happening faster than I have my oscilloscope set. Maybe I can spend some time learning it better and see the 1us FRAME behavior. if (lpc_read_address(0xFFFFFFFF)==-1) return 0;
return 1; }
flashrom itself doesn't seem to care about that check (although I haven't looked in the source): it just probes for a bunch of chips anyway.
so I guess the thing to do would be to look for the first lines that are engaged, and see where failure starts.
I'm still trying to figure out this oscilloscope (dso nano) which I think needs a firmware update. I'm looking at a log of CLK from the voltage divider connected to my raspberry pi. The chart goes off the display and it says the peak-to-peak voltage is 33.6V . It goes off the display in both the positive and negative directions. A raspberry pi usually produces no more than 5V, so this is some electrical thing. I don't know a lot about electronics, but they're full of noise and stuff. On Tue, Apr 5, 2022, 7:15 AM Undiscussed Horrific Abuse, One Victim of Many <gmkarl@gmail.com> wrote:
On Tue, Apr 5, 2022, 7:02 AM Undiscussed Horrific Abuse, One Victim of Many <gmkarl@gmail.com> wrote:
notes: in the flasher source, it's designed for more than one interface, and use of the lpc chip is guarded by this: uint8_t lpc_test(void) { nibble_hw_init();
FRAME is driven high for 1us and then allowed to drop for 1us.
lpc_init();
calls nibble_init(): INIT is briefly dropped and then raised. CLK is raised. FRAME is raised. calls nibble_write(0): DATA lines are set high. calls clock_cycle() 24 times. The code for clock_cycle drops CLK then immediately raises it.
It goes on with more port writes. I may have made an error in transcribing the above.
I'm guessing the clock is happening faster than I have my oscilloscope set. Maybe I can spend some time learning it better and see the 1us FRAME behavior.
if (lpc_read_address(0xFFFFFFFF)==-1) return 0;
return 1; }
flashrom itself doesn't seem to care about that check (although I haven't looked in the source): it just probes for a bunch of chips anyway.
so I guess the thing to do would be to look for the first lines that are engaged, and see where failure starts.
On Tue, Apr 5, 2022, 8:15 AM Undiscussed Horrific Abuse, One Victim of Many <gmkarl@gmail.com> wrote:
I'm still trying to figure out this oscilloscope (dso nano) which I think needs a firmware update.
I'm looking at a log of CLK from the voltage divider connected to my raspberry pi. The
this is an arduino, not a raspberry pi
chart goes off the display and it says the peak-to-peak voltage is 33.6V . It goes off
I think it might also be more than that. the display is configured for 10v increments and there are 8 vertical increments. i'm thinking it's likely calculation corruption in the device.
the display in both the positive and negative directions.
A raspberry pi usually produces no more than
this is an arduino, not a raspberry pi
5V, so this is some electrical thing. I don't know a lot about electronics, but they're full of noise and stuff.
and see where failure starts
I'm really scared I could be being exposed to high-voltage EM noise. When I try to act on emergencies, I experience. strong amnesia and loss of ability to act around the topic. So it's somewhat doubly scary. I know it's probably corruption from old firmware, but if it were high-voltage EM noise maybe that could explain my neurological issues. I feel scared.
The plan is to ignore the fear and situation for a bit and maybe brainstorm ways remaining to me to help others be safe from it.
I'm playing with using the oscilloscope more. The apparent voltage levels of the signal have changed. I have to adjust the trigger down a little bit for it to fire.
I am having trouble using the oscilloscope. I am no longer seeing big spikes. I am also seeing far more square waves. It is still not detecting the chip. I haven't figured out how to get it to the same region of the signal yet. The signal idles high. When I set a falling edge trigger, it triggers late, after the signal has already been low for some time, then risen and fallen again.
Being smaller or such and getting more curious about this might help me. I have a lot to learn about electricity.
This is probably because I had the dso nano plugged into the same power supply that burnt out the olimex's diode, when the olimex was plugged into it. Maybe no scary EM. Maybe just a difference in ground voltage.
I made the sure the grounds of my power supplies are unified. I didn't check their different voltages (to ease inhibitions); but it seemed confirmed well enough by the olimex's smoking power diode, which hasn't recurred since I put it on the same power supply as its serial host. It's satisfying to reduce possible causes of problems.
There's a specific branch of flashrom for this setup. I switched to it and tried it, but the results were the same. It looks pretty old. There is a quirk going on where the wiki says the new serial firmware is supposed to get 2Mbaud, whereas it's only communicating for me with 11kbaud, but I may have missed something. I added some debugging output to flashrom and saw the chip manufacturer and id are reading as 0xFF both, as is data. When I glanced at the detection code earlier with the oscilloscope, it was inverting the data read, so 0xFF may mean the data lines are simply not powered. Something I could maybe pursue next might be using the scope to see if any pins on the chip are outputting anything at all. I could also try poking at the clock pin more. Even if it's quirky, it's good practice getting comfortable with the scope, and maybe I can learn the quirks. Might also be meaningful to look up the sample rate of this scope and see if using a pi or an arduino as a logic analyser could increase it -- seems pretty unlikely though. I'm thinking an RTL-SDR would work as a high-rate logic probe, but I may be way off base.
I added some debugging output to flashrom and saw the chip manufacturer and id are reading as 0xFF both, as is data. When I glanced at the detection code earlier with the oscilloscope, it was inverting the data read, so 0xFF may mean the data lines are simply not powered.
Here, I could instrument all reads, and see whether any are ever not 0xFF .
The oscilloscope trigger is more reliable at slower time bases. Measuring at 20uS, I can massage the trigger to detect the first voltage drop: https://ipfs.io/ipfs/bafybeiggijiystskmrgdocvczfoqqulvfnzuktle7cuwy73kqpjyo5... It turns out the voltage scale is wrong in the pictures, because I tried to zoom out by setting it to 10. I think it only affects the next recording, unsure. The gradiations were set to 1V for the recording. Farther to the right there are visual corruptions that go off the scale and report multi-ten p2p voltages: https://ipfs.io/ipfs/bafybeibyzmeqcqa24rkib6gleg74jmg44ztny4vev23qg6ua7jthk5... This seems to happen associated with viewing a signal farther into the buffer. I might guess some kind of memory corruption. It makes sense that memory corruption would appear this way. My first idea was that the signal could be oscillating so fast that it misleads the analog-to-digital converter. I'm guessing this isn't the issue, because after measuring a couple times it seems more associated with buffer position.
I'm looking a little into using an rtlsdr as a software oscilloscope. It has a higher samplerate than the nano, and I like to imagine one could use the radio tuner to infer the square wave corners and make a ghz logic analyser for clean signals. Reddit implies 0.3V - 1.8V are good maximum voltages to think about. Probably stay safer near the 0.3V bound on the lower end. So maybe >10x voltage drop from 3.3V. I could also work with the signal within the working range of the oscilloscope, and modify the software to output a signal that is easier to log (by adding delays). I tried to update the firmware of the dso nano oscilloscope, but my system didn't recognise the device, keeping giving usb errors (this is the raspberry pi, not the olimex serial client the programmer is plugged into). Trying with a different micro usb cable would be the next step for that.
rtlsdrs are scary :) not finding one immediately nearby. likely one near where another miniusb cable might be. might _mostly_ get miniusb cable, maybe just a smidge of rtlsdr. can also diagnose without these things by finding ways to trigger later into signal. for example, I could use diodes to OR the signal with an unused pin at higher voltage, and engage the pin via software to decide where to trace.
i'm tentatively moving forward on the rtlsdr approach. I've found an rtlsdrblogv3 dongle, a pigtail adapter I can cut to wire to a probe, and i've instally pysoapysdr on a system. i'm thinking it could be a few phases. first, measure a signal at all, using direct sampling. then, store the signal to a disk. thinking on a quick format. maybe a dedicated directory containing paired files: a binary vector of complex64s (with real component 0 for real-valued data), each with adjacent json metadata. I was going to do sqlite but this system doesn't have py3 sqlite at this time, and it's about as complex to relearn the api as to set up the dirtree, maybe a little more. but first, measure a signal at all, using direct sampling. it gets harder for me near the radio being powered.
I've got it outputting zeros, no gain, as it should. I'm passing "direct_samp=1" but haven't checked if it's actually enabled direct sampling. Next would/will be to cut the pigtail and set up a voltage divider to see if it can measure 0.1V or so.
Getting zeros out of my code even when the antenna is driven with 100mV. Also when the voltage is toggled. And when I ramp the gain from 0 up to the max of around 50dB. So next step is to get any signal at all. The missing data could be an undrained buffer issue, since it starts with zeros. Or the radio could be broken, as many of my old rtlsdrs are.
Fixed the zero issue. Fixed that direct sampling wasn't enabled (quickly and shoddily). It's not behaving how I expect, indicating I'm missing some knowledge. Direct sampling quickly picks up the 3V source if and only if there is no resistor between it and the antenna port, even if the resistor is very small, giving the same voltage on a voltmeter. Given this isn't the primary goal atm and takes some learning, I might think about it a bit, maybe try harder to flash my oscilloscope firmware. Or I could switch over to oscilloscope stuff. I found a bug in pysoapysdr I could contribute, maybe.
I asked in the old rtlsdr chat regarding this and learned about buffering, and electrical engineering concept. Without sorting buffering out, I did find I have an optoisolator, a potentiometer, and a few transistors from the nyansat kit. I wired the potentiometer in and just judging it visually, it kind of looks like there is a weak association between value and voltage from 0V-1V and then a very strong association from around 1V-1.4V or something like that. It reminded me a little of the shunt resistor diagram from the laptop. (I also saw different, less distinctive, behavior when reverse polarized). I recall there were also strong spikes seen when tuned to a frequency, when the voltage changed. So basically this isn't going to be an oscilloscope quickly, but would indeed work as a quick and messy logic probe. I'm thinking I might just kind of move forward on logging data from the lines in any adhoc manner that can be correlated. The rtlsdr maybe has more utility than the oscilloscope here, because it has an api I can wire to data storage and event information. Even if the signal is heavily transformed by shoddy circuitry. I do not have anything visual at this time. I am just looking at scrolling numbers. Assuming I can work through the double inhibitions, logging multiple event-synchronised signals and plotting them would be a good step for me. Maybe in c/c++ so the code would be easily portable to a more embedded device that might be capable of bitbanged probing.
I tried a new cable on the dso nano and it works much better. So, flashing the firmware of that is available now. On Wed, Apr 6, 2022, 3:23 PM Undiscussed Horrific Abuse, One Victim of Many <gmkarl@gmail.com> wrote:
I asked in the old rtlsdr chat regarding this and learned about buffering, and electrical engineering concept.
Without sorting buffering out, I did find I have an optoisolator, a potentiometer, and a few transistors from the nyansat kit. I wired the potentiometer in and just judging it visually, it kind of looks like there is a weak association between value and voltage from 0V-1V and then a very strong association from around 1V-1.4V or something like that. It reminded me a little of the shunt resistor diagram from the laptop. (I also saw different, less distinctive, behavior when reverse polarized).
I recall there were also strong spikes seen when tuned to a frequency, when the voltage changed.
So basically this isn't going to be an oscilloscope quickly, but would indeed work as a quick and messy logic probe.
I'm thinking I might just kind of move forward on logging data from the lines in any adhoc manner that can be correlated.
The rtlsdr maybe has more utility than the oscilloscope here, because it has an api I can wire to data storage and event information. Even if the signal is heavily transformed by shoddy circuitry.
I do not have anything visual at this time. I am just looking at scrolling numbers.
Assuming I can work through the double inhibitions, logging multiple event-synchronised signals and plotting them would be a good step for me.
Maybe in c/c++ so the code would be easily portable to a more embedded device that might be capable of bitbanged probing.
https://gitlab.com/dsonano/dso-firmware https://gitlab.com/dsonano/dso-bootl https://gitlab.com/dsonano/dso-nano-old dso-firmware.git/packed-refs # pack-refs with: peeled fully-peeled sorted b31cf3ac437ba095d6fbf50dafe62a22ecdcb9d0 refs/heads/dualboot 6c0434f7021a12b962ccf4691ffd2c86e2997d85 refs/heads/fft-relocated 27c16b6777d2dfe9778c2a22eae7f26f4e8efc2a refs/heads/master dso-bootl.git/packed-refs # pack-refs with: peeled fully-peeled sorted b9975eb3bd59de9b9347b897ce8371ec59b33959 refs/heads/dualboot 71fc3e208f35ebca9fc304f7be62f58db0e3c3ae refs/heads/master dso-nano-old.git/packed-refs # pack-refs with: peeled fully-peeled sorted f0079e3b3ce7f985da02279d27cc211c276d29f1 refs/heads/master
to move forward on these things, basically take small steps. - [ ] download firmware and/or - [ ] transfer nonworking crummy-logic-probe work off offline system, toward internet or even - [ ] get near system
- [x] firmware transferred to system i've been using - [x] crummy code uploaded to https://github.com/xloem/soapyscope.git next: - [ ] build dso firmware - [ ] improve soapyscope protodraft: name datafiles based on device, channel, tuning, and timestamp, so new files don't overwrite old
- packets weren't dropped, but i am encountering a timeout error now that i have wired the gui in. it is so incredibly hard to work the rtl bit, still. but it's pretty much together, just a little bit, which could take a few days to force myself to do [if i even manage to] i dropped my phone after my last post burst, and its nonremoveable battery ripped out in the impact. so i'm not spamming the list as much. i was really using that phone (and spamming this list) as a crutch! crazy stuff. i did order a new nonremoveable battery and plan to repair it after it arrives on monday.
this morning i got back on porting serialice, which lets you try firmware without reflashing the chip (and step through it). serialice is part of coreboot but has a .com main page: https://www.serialice.com/Main_Page . there's work in their issue repo to merge it into coreboot that needs a volunteer to clean it up and finish. so, i transferred my serialice work to the main system so i could test it without a working programmer. i laboriously added debugging and test statements to bisect it with known-working code. in the end, it turns it out _already works fine_. it just plain works, and i can debug my cpu with the cpu using what i already wrote. it is _incredibly easy_ to port a new board to serialice. all you need to do is initialise the cpu and the serial port, nothing else, not even the ram, and there is already code in serialice for common serial port cpus and cpu families. if you're a little familiar with assembler, you might be able to port a new board in a single day by disassembling the factory rom. the boot vector is 16 bytes prior to the end of the flash, and sometimes there is a southbridge vector 16 bytes prior to that. (at least that was how my old amd64 board is, and the code it uses is shared across many other boards). for me now, if i want to look at new bioses, the biggest impediment is gaining access to the flash chip. i dunno how to do that yet. anyway, with the logic analyser projects on the side to make the actual programmer work, next step for me with serialice is to see if my old build was actually working and my eyes were crossed, or if there is a reason it wasn't, to discern what the difference is, since the source code appears the same.
here's where i'm at: - it is very hard to move forward on the rtlsdr logic analyser. tiny steps involving dense amnesiatic spasma. - I flashed the oscilloscope with tormod's open source firmware and it won't leave dfu mode after flashing. It might be a third party variant, which there's a little documentation on. I could try the non-gcc firmware which would involve running windows. I could also try to debug the bootloader. I could maybe try reflashing the bootloader. - I contacted a makerspace around the issue. Somebody reviewed the schematic and recommended I add 200nF caps to the power pins on the socket. We also found there may still be commercial flashers that support my chip. - To test actually using my change to serialice to support my board, serialice assumes an x86 host to run qemu on. So, I tried to install x86_64 debian on my aarch64 host inside qemu, planning to nest them. Unfortunately the debian installer takes forever and then crashes, running into strange corruptions. It's hard to move forward on this, and has started engaging my issues poorly. It used to be a pleasant project that mostly avoided the issues, partly because the bios test cycle is pretty rote. It might be nice to get back to that test cycle just using the internal flasher of the board, even though that means rebooting every change. Adding the caps to the flasher makes sense. I also realised I'm unsure what model flash chips I'm using and which of the flashrom probes they're supposed to pass; it would be good to nail that down. Other things. Confusion.
flasher works again :D Debugging it was greatly helped by having labeled my pin wires. I was looking into the firmware and discovered it had a debugging mode that opened an interactive terminal. I added a command to the terminal source to send test values on the various pins, outputting text describing where each logic level should end up. I found one of my wires was miswired and mislabeled in a hard-to-notice way. Maybe I rewired it wrongly after it fell out or something. I tested and verified each voltage level, ignoring logic flow. Annnd now it works! Now to clean things up and use it again. Topic _seems_ resolved. Ideally I contribute code successfully to coreboot, a larger goal. In the meantime, I found a local makerspace and started a radio tool.
I was excited to have this working and trying to get an x86 qemu setup so as to test serialice, while installing windows on the system itself to try a phone flasher to get a nonworking phone working. The southbridge was strangely overheating; I moved the heatsink a little (which didn't used to be needed but, windows) and the system powered off and refused to power back on. Unexpected. I have two boards because I thought I broke one. Later I thought I broke one again, the flash chip kept overheating, and I switched to another. Then I learned that means the chip is in backward. I tried my other board with the chip in the right way round, but it wouldn't boot. I flashed one of my bios prototypes using the arduino flasher onto a chip, and it actually worked, sending its test byte over the serial line. This means the southbridge is successfully initialising the cpu, and the cpu can be used to further debug, which is great news. I went to flash a bigger bios onto the same chip, but suddenly the arduino flasher is running into the old weird error I ran into before, not detecting a recognized chip because the data pins are grounded when it reads the ID. I entered the firmware debug terminal that I had discovered, which thankfully worked, and it thankfully did indeed detect the presence of a chip when one was inserted. I ran the command I added to set the pins with test values, and it seems to look like the clock pin is staying high when it should go low. The clock pin being low was the very last pin state I tested, which is fine since you test them all. It's a strange error, but a resolvable one. Honestly I'm thinking the most likely problem is that I made an error setting the clock pin low in the pin test code, and didn't notice when I tested the pins last time. Finding the problems that aren't unrelated mistakes I've made is a journey through the ones that are. I reran the test voltages, and the error remains. The implication is that something is going wrong inside the arduino's microcontroller.
I thought I saw the clk voltage go to zero after repowering the board, and began diagnosing based on this. However, I'm unable to reproduce the behavior. I downloaded the main firmware off the device and used avrdude to verify the resulting binary was identical to what I had uploaded. It also has serial firmware, separate from the mcu firmware. The clk pin presently appears to go high as soon as the board is powered. I checked the source and that is correct. When I disabled it, I found the pin to oscillate on its own, while the board was theoretically waiting for instructions from the computer. I checked my test code and it looks right enough: CLK_DDR |= _BV(CLK); // output on pin CLK_PORT &= ~_BV(CLK); // set it low I added a while(1); after those lines and the clock stays low correctly. Looks like there's something else the chip does that my test code didn't account for. I commented out all code in the run loop after the debug terminal. The pin stays low on boot now, but oscillates after the voltage test. Gotta just spend some time troubleshooting and learning it.
Basically, if it detects an LPC chip, it cycles the LPC clock while it is waiting for UART data.
That explains the clock going high when a chip is in. I'm presently attempting to redo my troubleshooting ensuring I have no chip in when sending the probe voltages (there wasn't one in the first time), but the firmware debug terminal isn't loading. I reset the board with its button and I can't seem to even open the serial port. (I'm using screen; it immediately terminates on launch.) I repowered the board, and it will connect, but not launch the terminal. I thought I had reverted all my debugging traces and block comments, but I found some in a submodule and reverted those too. After a rebuild and reflash, it still won't launch the debugging terminal. The arduino serial has leds for receiving and sending data. It's supposed to switch to debug mode when I send it a spacebar. I can see it receiving the spacebar character. It sometimes takes a bit before responding to spacebars. I infer it's still in the state where it doesn't. I can theoretically debug it like I did the motherboard I'm working on, by sending tracepoints to the serial line. This arduino uno also appears to have a large removable socketed chip in it. After a very long delay, it did eventually show the debug terminal, and some spurious characters that appear to be local echo. The clk pin finally goes low. No chip is in. And it will actually read the chip data again! I think this would have been less mysterious if the clk pin didn't oscillate on its own under certain conditions when probing. I think I'll either detect or disable that in the new debug command code.
Experiences: I put a new chip in, a new model too, to try to flash some data. flashrom got stuck in an unending loop, addressing the same bytes over and over again. I put my old chip in that had just read fine. flashrom froze while reading it. No data transferred after some hundred kilobytes in. I plugged it into the same system it had worked on, and executed the same command from the history. This time, it seemed to work. This system doesn't have any of my coreboot work, though. (it does have the serialice rom, but it's good to get the tools to seem stable before using them) The working system also read fine from the new model chip. I'm noting while it writes that some addresses are changing, and some are not. Maybe it writes to one address to configure writing to another. Hopefully I was just mis-seeing the loop on the same address. I also saw some "failure" messages during flashing from the failing system. -- It looks like it's working. --- Basically, I flashed coreboot to one chip and am just using that chip to test. My main board boots until it gets to PCI scanning and then it freezes after scanning the PCI bus. This is enough functionality to test serialice, but it's frustrating the system doesn't work. I tried the other board and it fried my serial adapter on boot, which is worrying. I'm lucky I have a spare.
zeynep do you need help with filtering my emails or am I saying something dangerous or ...?
On 3/22/22, Undiscussed Horrific Abuse, One Victim of Many <gmkarl@gmail.com> wrote:
This is also of interest to me because I almost completed a 12dof quadruped robot for my niece and nephew during my chemotherapy, but then got confused and stopped associated with breaking the prototype controller, which I had foolishly soldered onto a wire wrap board, not knowing how to use one.
One of the bots that lived here had a weak tether that broke, don't remember the bots name or fate, but this post recalled the bot :)
On Sun, Mar 27, 2022, 4:14 AM grarpamp <grarpamp@gmail.com> wrote:
On 3/22/22, Undiscussed Horrific Abuse, One Victim of Many <gmkarl@gmail.com> wrote:
This is also of interest to me because I almost completed a 12dof quadruped robot for my niece and nephew during my chemotherapy, but then got confused and stopped associated with breaking the prototype controller, which I had foolishly soldered onto a wire wrap board, not knowing how to use one.
One of the bots that lived here had a weak tether that broke, don't remember the bots name or fate, but this post recalled the bot :)
:) curious to learn about bot and/or living place I ended up doing wireless rather than tether I think because the tether added weight, but I prefer wired communication. There are short videos of it during building at https://www.youtube.com/user/fuzzyTew . There's another of it dancing in rapid sine waves with my niece and nephew but probably shouldn't put video of them online.
participants (4)
-
grarpamp -
Karl Semich -
Undiscussed Horrific Abuse, One Victim of Many -
zeynepaydogan