comparison: content/hp34970a_5.rst
content/hp34970a_5.rst
- changeset 132
- f4160af0485c
- child 134
- d6a1dc59a985
equal
deleted
inserted
replaced
| 131:6171b3d4e6b2 | 132:f4160af0485c |
|---|---|
| 1 ========================================== | |
| 2 HP 34970A Data Acquisition Unit - part 5 | |
| 3 ========================================== | |
| 4 | |
| 5 :Author: David Douard | |
| 6 :Category: Electronics | |
| 7 :Tags: HP, 34970A, HP34970A, DMM, repair, test equipment | |
| 8 :series: HP 34970A repair | |
| 9 :series_index: 4 | |
| 10 | |
| 11 | |
| 12 After a loooong pause on this project, I have recently been able to work on it | |
| 13 again. In `the previous post in this series <{filename}/hp34970a_4.rst>`_, I've | |
| 14 started to implement a replacement board prototype based on a an NUCLEO board | |
| 15 and an SSD1322-based OLED display. | |
| 16 | |
| 17 Meanwhile, I have also almost completely described the `communication protocol | |
| 18 <{filename}/hp34970a_protocol.rst>`_ between the main unit and the front panel. | |
| 19 | |
| 20 In this episode, I'll describe the next steps: make the circuit diagram and the | |
| 21 PCB for the replacement board. | |
| 22 | |
| 23 | |
| 24 Circuit diagram | |
| 25 =============== | |
| 26 | |
| 27 The circuit diagram is rather simple: | |
| 28 | |
| 29 - an STM32 MCU (I initially chose the `STM32F303RE | |
| 30 <https://www.st.com/en/microcontrollers-microprocessors/stm32f303re.html>`_, | |
| 31 but finally used an STM32F303RD just because the former was out of stock when | |
| 32 I made my command at mouser.) I wanted an STM32 MCU with USB support and | |
| 33 reasonnable amount of flash and ram just not to have to worry about these | |
| 34 while writing the firmware. | |
| 35 | |
| 36 - a 8MHz crystal so the clock config used on NUCLEO boards can be used as is. | |
| 37 | |
| 38 - a step-down DC-DC converter to go from the +18V coming from the main unit | |
| 39 to +5V to power the OLED display and the some chips on the board; I've chosen | |
| 40 a `TPS560430 <https://www.ti.com/product/TPS560430>`_ from TI, | |
| 41 | |
| 42 - a 5V->3.3V LDO regulator to power the MCU, an `MCP1811AT-033 | |
| 43 <https://www.microchip.com/wwwproducts/en/MCP1811>`_ by Microship, | |
| 44 | |
| 45 - a level shifter for the communication lines bertween the MCU and the main | |
| 46 unit (5V vs. 3.3V logic). For this, instead of going through individual | |
| 47 Mosfet transistors, I've chosen the `LSF0204PWR | |
| 48 <https://www.ti.com/product/LSF0204>`_ from TI, to simplify a bit the | |
| 49 assembly (this chip really is not much more than a bunch of transistors in a | |
| 50 TSOP package). | |
| 51 | |
| 52 Here is the diagram I ended up with: | |
| 53 | |
| 54 .. image:: {static}/images/hp34970a/replacement-front-panel-schematic.svg | |
| 55 :alt: Schematic for a replacement front panel for the HP 34970A | |
| 56 :class: image-process-large-photo | |
| 57 | |
| 58 PCB design | |
| 59 ========== | |
| 60 | |
| 61 I've used librecad_ to draw the edge profile of the PCB, after having carefully | |
| 62 measured the broken PCB, and a kicad plugin to generate nice keypad footprints. | |
| 63 (I had to adjust the generated footprint by hand to make it more usable.) | |
| 64 | |
| 65 The end result looks like: | |
| 66 | |
| 67 .. image:: {static}/images/hp34970a/front_panel_replacement_pcb_3d.png | |
| 68 :alt: 3D view of the PCB for a replacement front panel for the HP 34970A | |
| 69 :class: image-process-large-photo | |
| 70 | |
| 71 The 2 buttons on the left are the Reset and the DFU boot mode. The header on | |
| 72 the right is the SWD port. | |
| 73 | |
| 74 After a few days, the PCB arrived (from the usual places): | |
| 75 | |
| 76 .. image:: {static}/images/hp34970a/bare_pcb_front.jpg | |
| 77 :alt: the PCB for a replacement front panel for the HP 34970A | |
| 78 :class: image-process-large-photo | |
| 79 | |
| 80 And it fits just fine in the front panel enclosure: | |
| 81 | |
| 82 .. image:: {static}/images/hp34970a/pcb_test_fit.jpg | |
| 83 :alt: test fit of the PCB for a replacement front panel for the HP 34970A | |
| 84 :class: image-process-large-photo | |
| 85 | |
| 86 | |
| 87 Unfortunately, I made a few mistakes in this design (see below) bit I also made | |
| 88 the big mistake of swaping the marking of R11 and R12, which defined the | |
| 89 feedback divider setting the output voltage of the DC-DC converter. As a | |
| 90 result, I fried a LDO and a STM32F303RD chips! | |
| 91 | |
| 92 But once replaced correctly, is began to work: | |
| 93 | |
| 94 | |
| 95 .. image:: {static}/images/hp34970a/pcb_dfu_connection.jpg | |
| 96 :alt: test USB connection in DFU mode | |
| 97 :class: image-process-large-photo | |
| 98 | |
| 99 After installing the OLED display and adjusting the previous verison of the | |
| 100 code (which was designed for the NUCLEO F446RE board), I could compile it for | |
| 101 my custom board and make it run: | |
| 102 | |
| 103 .. image:: {static}/images/hp34970a/pcb_first_test.jpg | |
| 104 :alt: test of the display circuit | |
| 105 :class: image-process-large-photo | |
| 106 | |
| 107 Firmware design | |
| 108 =============== | |
| 109 | |
| 110 At this point, I tried to make the CDC USB driver work on the board, but I | |
| 111 failed to do so. I realized that the USB stack is `actually missing | |
| 112 <https://forums.mbed.com/t/usbdevice-support-for-stm32f3/10685>`_ for this MCU | |
| 113 in MBed OS 6. (update: there is a `PR | |
| 114 <https://github.com/ARMmbed/mbed-os/pull/13874>`_ waiting to be accepted and | |
| 115 merged to improve support for the STM32F303 family). | |
| 116 | |
| 117 Unfortunately, I could not make the debug pin of the SWD port work either. I | |
| 118 can upload a new firmware juste fine via this SWD port (in addition to the DFU | |
| 119 mode via USB), but I have been ablt tuse the SWO ping to get a console to see | |
| 120 print statements. | |
| 121 | |
| 122 In last resort, I ended up soledring thin enameled wired directly on the MCU's | |
| 123 pin to get access to of the available UARTs as console/debugger. | |
| 124 | |
| 125 At least this worked just fine, and I could then work on the code much more | |
| 126 easily. | |
| 127 | |
| 128 I also had to use my DSLogic logic analyzer to debug a few things and get to a | |
| 129 point that make the front panel usable: | |
| 130 | |
| 131 .. peertube:: cc6f4327-703f-42f6-8157-03cd0a987387 | |
| 132 | |
| 133 In this version of the code are many remaining problems, the biggest one being | |
| 134 the fact the display flickers a lot. In the code of the formware, I have a | |
| 135 "frame"-buffer in which the main loop draw the information to be displayed, and | |
| 136 a thread that copy this buffer to the actual display once every 30ms. And in | |
| 137 the first version display above, there was no DMA involved in tranferring the | |
| 138 buffer into the display unit. | |
| 139 | |
| 140 Activating the DMA did help a bit, but was not enough to get rid of the | |
| 141 glitches. The real problem was there was no lock around that buffer, so the | |
| 142 display refresher thread was making the transfer at any time, including in the | |
| 143 middle of the drawing proceure. Adding a lock around this buffer finally fixed | |
| 144 the problem. | |
| 145 | |
| 146 Another problem I had in the first version of the firmware was the fact a | |
| 147 keypress event could be sent to the main unit during a transmission of a packet | |
| 148 by this later, which mess the transmission protocol quite a bit. This problem | |
| 149 is now (mostly, not 100% sure there is no edge case left) fixed. | |
| 150 | |
| 151 Here is an example of this situation occuring (screenshot of a `PulseView | |
| 152 <https://sigrok.org/wiki/PulseView>`_ session): | |
| 153 | |
| 154 .. image:: {static}/images/hp34970a/packet-collision.png | |
| 155 :alt: transmission collision | |
| 156 :class: image-process-large-photo | |
| 157 | |
| 158 In the example above, one can see the front panel is starting a transmission | |
| 159 (sends a 0x66 on the RX line), but while this byte is being sent, the 0x66 | |
| 160 start of transmission byte is also sent by the main unit. | |
| 161 | |
| 162 Not sure yet how to fix this, either by making sure that this situation does | |
| 163 not occur (which is most unlikely not feasible), or by impriving the transmission | |
| 164 protocol handling state machine in my firmware to be aware that this may happen | |
| 165 and be resilient against it. | |
| 166 | |
| 167 But in the end, I've now reach a point where the firmware begins to be really | |
| 168 usable: | |
| 169 | |
| 170 .. peertube:: 172bf449-eba7-4429-8840-ab9b2d5398f8 | |
| 171 | |
| 172 | |
| 173 | |
| 174 Design errors | |
| 175 ============= | |
| 176 | |
| 177 Making this circuit I made a few mistakes and errors. | |
| 178 | |
| 179 Wrong MCU | |
| 180 --------- | |
| 181 | |
| 182 I've not paid enough attention when I chose the MCU. The STM32F303RE I chose is | |
| 183 more then fine on a specifications point of view, however, since I am writing | |
| 184 the formware using MBedOS, I did pay attention that the USB FS stack is not yet | |
| 185 supported for this MCU on MBed OS 6. | |
| 186 | |
| 187 My initial idea was to provide a serial communication protocol with the front | |
| 188 panel to be able to upgrade the firmware easily or get the current display | |
| 189 content, but this is for now not possible. Will have to stick to GPIB for now. | |
| 190 | |
| 191 | |
| 192 No proper USB VBUS handling | |
| 193 --------------------------- | |
| 194 | |
| 195 I decided not to connect the VBUS power line from the USB socket, but it would | |
| 196 have made my life a bit easier to connect it via the usual protection, so the | |
| 197 testing / uploading the firmware could have been a bit easier until the front | |
| 198 panel wasa plugged back to the main unit. | |
| 199 | |
| 200 Even so, it would be nice to be able to upgrade the firmware without having to | |
| 201 plug the whole unit. | |
| 202 | |
| 203 The real problem of not having connected the VBUS signal is USB detection. If I | |
| 204 want to be able to implement a USB connection, I need to be able to detect | |
| 205 wether the USB connector is plugged, and the simplest way of doing that is to | |
| 206 detect the presence of the VBUS signal. | |
| 207 | |
| 208 No diagnostic/status LED | |
| 209 ------------------------ | |
| 210 | |
| 211 I should have added a few diagnostic/status LEDs: there are plenty of GPIO left | |
| 212 unused on the MCU, having those visble indocators is alway handy. | |
| 213 | |
| 214 No extra UART | |
| 215 ------------- | |
| 216 | |
| 217 I should have routed at least one unused UART from the MCU to a pair of | |
| 218 headers: it way easier not to populate such a header than to hack small wires | |
| 219 directly on the MCU tget a decent console port... | |
| 220 | |
| 221 | |
| 222 | |
| 223 | |
| 224 | |
| 225 | |
| 226 | |
| 227 | |
| 228 .. _librecad: https://github.com/LibreCAD/LibreCAD |
