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 <[email protected]> wrote: > > > On Tue, Apr 5, 2022, 7:02 AM Undiscussed Horrific Abuse, One Victim of > Many <[email protected]> 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. >> >
