main board work

[jkominek]

Not done with schematic capture, but starting the layout to make sure things look reasonable...

[jkominek]

That went well enough. Still need to throw something on there for power. Routing the MII interface for the ethernet was a pain. Hopefully that works.

I've also got this fantasy of putting some p-channel FETs on there for high-side control of each ADC board's power. I don't really know what good that would do. Maybe I'll just put in a single FET for controlling power to all of the ADC boards at once. That way when this board powers up, it can write to EEPROM or something a flag indicating that it is about to flip that switch. Once it does so, and finds it is still running a second or two later, it can clear the flag. If it turns on and finds the flag set, it knows it should alert the user to a potential error situation.

So, needed:

• Power (probably the same switching regulator I tossed onto the ADC boards)
• P-channel FET & control (an N-channel and some resistors)
• EEPROM or FRAM. SPI6? Or turn on another SPI interface for it?
• Do some jumpering so you can either use the LEDs built into the magjack, or bring them out on wires to a remote jack.

[davidedelvento]

Wow, you are being sophisticated with this! How would one recover from the potential error situation? Full board reset? Can it be useful in case of a power loss event?

[jkominek]

@davidedelvento The reset button for the main board is now available on a header, so that can be brought out to the exterior of the housing. That'll cause it to reset, and since it has control of power to the ADC boards, they'll all reset at the same time. (Thank you for describing errors as only "potential". 😀)

I'm not sure what you're referring to with a power loss event. As a whole, the system expects 5V, ~15V and ~48V. Inexpensive modules can provide them from AC. Slightly more expensive modules could produce them from a battery.

Latest version of the main board, which I finally committed to the repo. I just realized I left off the lines that let the microcontroller actually control the array of FETs across the top which feed the ADC boards their power. Oh well.

With that commit, rough versions of all of the necessary hardware are up online. So anyone who stares hard enough long enough should be able to figure out how it is supposed to work. 😀

[davidedelvento]

By power loss event I mean that the power gets interrupted in the middle or some (critical?) activity taking place, e.g. because the AC power is interrupted (even for just a slight moment) e.g. for snow-bent trees touching the power lines, so common here in Colorado.
Of course this can be mitigated by large enough capacitors (or even batteries as you suggest) in the power supply, but if there is a "total reset" option to avoid even the slightest risk of "bricking" it's better, IMHO. That could be a hidden button inside (or a non-button procedure), it does not need to be brought outside of the board, I think.

[jkominek]

Oh, I see what you mean. The only state in the system that could be affected would be the flash storing the firmware, and whatever nonvolatile memory I end up adding to the main board to store calibration information.

The easy case is the calibration information, I'll write a checksum to the end of the calibration, and only use it if it matches. if there's an error, then presumably the power failed during the previous calibration, and the PC holding the calibration will still be around when power is reapplied, and can just finish the process.

For both the main and ADC boards, I'll be making use of the bootloader that ST burns into the ROM of the chips, it is always present and can't be damaged. An interruption in reflashing the main board will just require you start over. An interruption in reflashing the ADC boards would be similar, but might be slightly harder for the instrument to detect/report. I'll have to scribble out some detection logic when I get to that point.

The reset button I mentioned bringing out is more akin to the old reset button on PCs. It'll just force an immediate reboot. That'll handle the case of some bug in the firmware causing the system to lock up.

[davidedelvento]

Sounds good!

[jkominek]

Ordered the next round of boards, covering everything that should be necessary. The main board looks like: