Notices by Andrew Zonenberg (azonenberg@ioc.exchange), page 4

Progress! I can SFTP a file to the board, it parses the outer ELF header, finds the program header table, and identifies the PT_LOAD sections.

Now to make it actually write that data to flash...

Two-way SPI communication between the bootloader/application firmware on the front panel, and the application firmware on the main MCU, is now working.

Next step, actually writing the contents of the loadable sections to flash... and we should have a fully working SFTP OTA boot flow (for one of the five programmable chips on the board, but hey it's a start!)

The plot thickens.

I need to be able to get data out of the front panel MCU (e.g. to know if it's in DFU or application mode, or if a flash block was successfully erased/written).

But PB4 is NJTRST / SPI1_MISO is my only way to do that, and due to an errata if I ever configure it in any alt mode other than 0 (NJTRST) the JTAG TAP resets.

Current workaround is to configure it in JTAG mode except when actively executing a readback operation, at which point I change it back to SPI mode.

This isn't working and I'm not yet sure why. Hopefully implementation bug somewhere in the chain of hardware.

New (reworked) back panel cables came in! Time to bend them...

Already spun a board? STM32 silicon errata on PB4?

Try making PB4 take turns being SPI and NJTRST. SPI mode when doing a command with readback, JTAG mode the rest of the time. don't forget to put it back in JTAG mode if you segfault. you will certainly not regret making PB4 be SPI and JTAG simultaneously.

And fully assembled!

This was a nightmare. I'm never putting this much semirigid in such close quarters again. It was almost impossible to route.

Me being conservative with some of the lengths thanks to not having access to pipe-routing MCAD software didn't help.

But it worked, and it served its purpose of giving me real-project familiarity with panel design and semirigid. I doubt any of my future projects will need quite this density of ports going to a small area of board.

Well, I was not expecting that to be a multi-hour ordeal but I had a few bugs.

CRC checks added. Next step is probably going to be refactoring the front panel bootloader a bit so that as much as possible of the code is reusable on the main micro as well.

The actual DFU code will be completely different (since I'll be running the sshd on the same chip being flashed) but the basic version/CRC check logic should be the same.

The other thing I need to do is refactor the main MCU code so that it's split into a common bare bones feature set (ssh server and minimal hardware bringup) needed for OTA flashing of the main MCU, and then the full feature set for all other functionality.

Back to firmware update work. The front panel SFTP firmware updater is now working!

Only thing missing is adding integrity checks across the SPI bus (right now the front MCU calculates the CRC on its end, I'd rather CRC on the main micro so that any errors in transmission will be detected and the flash will fail).

Then I can work on figuring out how to OTA the FPGA and main micro.

APB bridge is now read-write capable.

System health sensors, MDIO controller, and the relay controller for the bidirectional IOs are now all controlled over APB instead of the legacy bus.

Next up will be APB-ifying the front panel SPI bus, the mux selectors, and the BERT SERDES configuration interface.

@ajroach42 How's your C++, technical writing, and general electronics knowledge?

Does https://www.ngscopeclient.org/ seem like something you'd be a good fit for? I have a long list of wishlist items I'm too busy to work on and will gladly throw some budget at someone willing to spend time on it.

@ajroach42 Basically, for each of ~100 processing blocks (or as many as we have time/budget for):

* Get a screenshot of it in use in the waveform viewer

* Get a screenshot of it in use in the filter graph editor

* Document all of the inputs and outputs

* Write a paragraph or two about what it does at a high level

@ajroach42 What I'm looking for is:

* Someone willing to work at a discounted rate for open source work (I'd be paying out of pocket and can't afford to pay commercial rates, and the pool of people willing to do it for nothing is small)

* Someone who understands general electronics concepts

* Someone who can read C++ code that implements various protocol decodes and DSP operations well enough to write documentation about how to use it

If this isn't you, but you can hook me up with someone who is, I'm all ears.

@ajroach42 Check out the "filters" section in here https://www.ngscopeclient.org/downloads/ngscopeclient-manual.pdf

The first dozen or so alphabetically are fairly well developed and are a good benchmark for what the rest should look like.

Note the remaining 100+ are a sentence or two, if that. This needs to change before a full release.

@goatsarah @neil

Here's a few examples of otherwise-nice shots I lost due to this.

I've mostly been able to take camera/tripod motion out of the equation by setting a ~5 second self timer, pressing the shutter button, then stepping away and letting the vibrations damp out before the exposure starts. So this blur should be all defocus.

@goatsarah @neil Oh, yeah I didn't even attempt AF because I knew it'd get nowhere.

That's pretty much what I've done, zoom in as far as I can on the EVF and twiddle the focus ring until the stars stop getting smaller. But yeah, noise makes that tricky. I guess I just need to practice more.

@goatsarah @neil Interesting, your camera does dark frame correction internally? I thought that was pretty much always done in post.

Also, do you have any tips on focusing for these shots? I find with my Sony lenses "run to the end stop" is actually a little past the true "infinity" focus point, and every time I try manual focusing on stars I get it slightly off.

@goatsarah @neil 15 minute single exposure? Wow. What ISO/aperture?

Most of my night work to date has been much shorter (few second) high ISO exposures, which are easier to get but also have much worse SNR.

@lcamtuf Yep. And I haven't used a 555 in... probably close to 20 years at this point.

In the meantime, let me at least validate all of the other stuff I can before decabling *again*.

FPGA and MCU firmware seems to be at MVP level (that's "minimum viable prototype", as in all core functionality needed for operation has been demonstrated but not necessarily fully debugged).

In particular, I can plug the device into a 10/100/1000baseT LAN (the SFP+ side still needs more work but it's functional without that) and it comes up on a hard coded IP address because I haven't got around to adding UART console commands to change that. It's reachable via SSH using a hard coded username and password and gives you a shell equivalent to what you get from the UART.

There's a SCPI server on port 5025 that provides commands to change direction of bidirectional ports, set threshold of inputs, and set swing of outputs.

As far as hardware goes, since this board seems to have had a lot of solder issues, let's just go through and validate every single one of the IO ports.

IN0...IN7 are nonfunctional due to the DAC being flatlined; all testing on them will have to be tabled until I rework the DAC that I somehow forgot to do earlier. I swear I had got to it... this is what happens when you're doing bringup in between parenting a toddler I guess lol. I should keep better notes.

All of the unbuffered outputs (OUT0-3) work.

All of the buffered unidirectional outputs (OUT4-7) work.

All of the bidir IOs (IO8-11) work as both inputs and outputs.

I strongly suspect the inputs on 0...7 will work fine once I fix the DAC. Guessing just bad soldering since the SPI bus to it looks fine. Just mad I didn't do that already as I thought I had finished the rework...