--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/content/hp34970a_5.rst Sat Nov 07 15:49:10 2020 +0100
@@ -0,0 +1,228 @@
+==========================================
+ HP 34970A Data Acquisition Unit - part 5
+==========================================
+
+:Author: David Douard
+:Category: Electronics
+:Tags: HP, 34970A, HP34970A, DMM, repair, test equipment
+:series: HP 34970A repair
+:series_index: 4
+
+
+After a loooong pause on this project, I have recently been able to work on it
+again. In `the previous post in this series <{filename}/hp34970a_4.rst>`_, I've
+started to implement a replacement board prototype based on a an NUCLEO board
+and an SSD1322-based OLED display.
+
+Meanwhile, I have also almost completely described the `communication protocol
+<{filename}/hp34970a_protocol.rst>`_ between the main unit and the front panel.
+
+In this episode, I'll describe the next steps: make the circuit diagram and the
+PCB for the replacement board.
+
+
+Circuit diagram
+===============
+
+The circuit diagram is rather simple:
+
+- an STM32 MCU (I initially chose the `STM32F303RE
+ <https://www.st.com/en/microcontrollers-microprocessors/stm32f303re.html>`_,
+ but finally used an STM32F303RD just because the former was out of stock when
+ I made my command at mouser.) I wanted an STM32 MCU with USB support and
+ reasonnable amount of flash and ram just not to have to worry about these
+ while writing the firmware.
+
+- a 8MHz crystal so the clock config used on NUCLEO boards can be used as is.
+
+- a step-down DC-DC converter to go from the +18V coming from the main unit
+ to +5V to power the OLED display and the some chips on the board; I've chosen
+ a `TPS560430 <https://www.ti.com/product/TPS560430>`_ from TI,
+
+- a 5V->3.3V LDO regulator to power the MCU, an `MCP1811AT-033
+ <https://www.microchip.com/wwwproducts/en/MCP1811>`_ by Microship,
+
+- a level shifter for the communication lines bertween the MCU and the main
+ unit (5V vs. 3.3V logic). For this, instead of going through individual
+ Mosfet transistors, I've chosen the `LSF0204PWR
+ <https://www.ti.com/product/LSF0204>`_ from TI, to simplify a bit the
+ assembly (this chip really is not much more than a bunch of transistors in a
+ TSOP package).
+
+Here is the diagram I ended up with:
+
+.. image:: {static}/images/hp34970a/replacement-front-panel-schematic.svg
+ :alt: Schematic for a replacement front panel for the HP 34970A
+ :class: image-process-large-photo
+
+PCB design
+==========
+
+I've used librecad_ to draw the edge profile of the PCB, after having carefully
+measured the broken PCB, and a kicad plugin to generate nice keypad footprints.
+(I had to adjust the generated footprint by hand to make it more usable.)
+
+The end result looks like:
+
+.. image:: {static}/images/hp34970a/front_panel_replacement_pcb_3d.png
+ :alt: 3D view of the PCB for a replacement front panel for the HP 34970A
+ :class: image-process-large-photo
+
+The 2 buttons on the left are the Reset and the DFU boot mode. The header on
+the right is the SWD port.
+
+After a few days, the PCB arrived (from the usual places):
+
+.. image:: {static}/images/hp34970a/bare_pcb_front.jpg
+ :alt: the PCB for a replacement front panel for the HP 34970A
+ :class: image-process-large-photo
+
+And it fits just fine in the front panel enclosure:
+
+.. image:: {static}/images/hp34970a/pcb_test_fit.jpg
+ :alt: test fit of the PCB for a replacement front panel for the HP 34970A
+ :class: image-process-large-photo
+
+
+Unfortunately, I made a few mistakes in this design (see below) bit I also made
+the big mistake of swaping the marking of R11 and R12, which defined the
+feedback divider setting the output voltage of the DC-DC converter. As a
+result, I fried a LDO and a STM32F303RD chips!
+
+But once replaced correctly, is began to work:
+
+
+.. image:: {static}/images/hp34970a/pcb_dfu_connection.jpg
+ :alt: test USB connection in DFU mode
+ :class: image-process-large-photo
+
+After installing the OLED display and adjusting the previous verison of the
+code (which was designed for the NUCLEO F446RE board), I could compile it for
+my custom board and make it run:
+
+.. image:: {static}/images/hp34970a/pcb_first_test.jpg
+ :alt: test of the display circuit
+ :class: image-process-large-photo
+
+Firmware design
+===============
+
+At this point, I tried to make the CDC USB driver work on the board, but I
+failed to do so. I realized that the USB stack is `actually missing
+<https://forums.mbed.com/t/usbdevice-support-for-stm32f3/10685>`_ for this MCU
+in MBed OS 6. (update: there is a `PR
+<https://github.com/ARMmbed/mbed-os/pull/13874>`_ waiting to be accepted and
+merged to improve support for the STM32F303 family).
+
+Unfortunately, I could not make the debug pin of the SWD port work either. I
+can upload a new firmware juste fine via this SWD port (in addition to the DFU
+mode via USB), but I have been ablt tuse the SWO ping to get a console to see
+print statements.
+
+In last resort, I ended up soledring thin enameled wired directly on the MCU's
+pin to get access to of the available UARTs as console/debugger.
+
+At least this worked just fine, and I could then work on the code much more
+easily.
+
+I also had to use my DSLogic logic analyzer to debug a few things and get to a
+point that make the front panel usable:
+
+.. peertube:: cc6f4327-703f-42f6-8157-03cd0a987387
+
+In this version of the code are many remaining problems, the biggest one being
+the fact the display flickers a lot. In the code of the formware, I have a
+"frame"-buffer in which the main loop draw the information to be displayed, and
+a thread that copy this buffer to the actual display once every 30ms. And in
+the first version display above, there was no DMA involved in tranferring the
+buffer into the display unit.
+
+Activating the DMA did help a bit, but was not enough to get rid of the
+glitches. The real problem was there was no lock around that buffer, so the
+display refresher thread was making the transfer at any time, including in the
+middle of the drawing proceure. Adding a lock around this buffer finally fixed
+the problem.
+
+Another problem I had in the first version of the firmware was the fact a
+keypress event could be sent to the main unit during a transmission of a packet
+by this later, which mess the transmission protocol quite a bit. This problem
+is now (mostly, not 100% sure there is no edge case left) fixed.
+
+Here is an example of this situation occuring (screenshot of a `PulseView
+<https://sigrok.org/wiki/PulseView>`_ session):
+
+.. image:: {static}/images/hp34970a/packet-collision.png
+ :alt: transmission collision
+ :class: image-process-large-photo
+
+In the example above, one can see the front panel is starting a transmission
+(sends a 0x66 on the RX line), but while this byte is being sent, the 0x66
+start of transmission byte is also sent by the main unit.
+
+Not sure yet how to fix this, either by making sure that this situation does
+not occur (which is most unlikely not feasible), or by impriving the transmission
+protocol handling state machine in my firmware to be aware that this may happen
+and be resilient against it.
+
+But in the end, I've now reach a point where the firmware begins to be really
+usable:
+
+.. peertube:: 172bf449-eba7-4429-8840-ab9b2d5398f8
+
+
+
+Design errors
+=============
+
+Making this circuit I made a few mistakes and errors.
+
+Wrong MCU
+---------
+
+I've not paid enough attention when I chose the MCU. The STM32F303RE I chose is
+more then fine on a specifications point of view, however, since I am writing
+the formware using MBedOS, I did pay attention that the USB FS stack is not yet
+supported for this MCU on MBed OS 6.
+
+My initial idea was to provide a serial communication protocol with the front
+panel to be able to upgrade the firmware easily or get the current display
+content, but this is for now not possible. Will have to stick to GPIB for now.
+
+
+No proper USB VBUS handling
+---------------------------
+
+I decided not to connect the VBUS power line from the USB socket, but it would
+have made my life a bit easier to connect it via the usual protection, so the
+testing / uploading the firmware could have been a bit easier until the front
+panel wasa plugged back to the main unit.
+
+Even so, it would be nice to be able to upgrade the firmware without having to
+plug the whole unit.
+
+The real problem of not having connected the VBUS signal is USB detection. If I
+want to be able to implement a USB connection, I need to be able to detect
+wether the USB connector is plugged, and the simplest way of doing that is to
+detect the presence of the VBUS signal.
+
+No diagnostic/status LED
+------------------------
+
+I should have added a few diagnostic/status LEDs: there are plenty of GPIO left
+unused on the MCU, having those visble indocators is alway handy.
+
+No extra UART
+-------------
+
+I should have routed at least one unused UART from the MCU to a pair of
+headers: it way easier not to populate such a header than to hack small wires
+directly on the MCU tget a decent console port...
+
+
+
+
+
+
+
+
+.. _librecad: https://github.com/LibreCAD/LibreCAD