search

kanflo / opendps

Give your DPS5005 the upgrade it deserves
MIT License
892 stars 124 forks source link

unexpected EOF while looking for matching ... #242

Open fiechr opened 3 years ago

fiechr commented 3 years ago

I'm using Arch/Manjaro.

$ pacman -Qs eabi
local/arm-none-eabi-binutils 2.36.1-2
    A set of programs to assemble and manipulate binary and object files for the ARM EABI (bare-metal) target
local/arm-none-eabi-gcc 10.3.0-1
    The GNU Compiler Collection - cross compiler for ARM EABI (bare-metal) target
local/arm-none-eabi-newlib 4.1.0-1
    A C standard library implementation intended for use on embedded systems (ARM bare metal)
$ pacman -Qs openocd
local/openocd 1:0.11.0-1
    Debugging, in-system programming and boundary-scan testing for embedded target devices

Whenever I try to build I get this error:

$ make -C libopencm3
make: Entering directory '/home/cf/src/opendps/libopencm3'
  GENHDR  include/libopencm3/vf6xx/irq.json
  GENHDR  include/libopencm3/lpc17xx/irq.json
  GENHDR  include/libopencm3/lpc43xx/m0/irq.json
  GENHDR  include/libopencm3/lpc43xx/m4/irq.json
  GENHDR  include/libopencm3/sam/3a/irq.json
  GENHDR  include/libopencm3/sam/3u/irq.json
  GENHDR  include/libopencm3/sam/3n/irq.json
  GENHDR  include/libopencm3/sam/3x/irq.json
  GENHDR  include/libopencm3/sam/d/irq.json
  GENHDR  include/libopencm3/sam/3s/irq.json
  GENHDR  include/libopencm3/efm32/lg/irq.json
  GENHDR  include/libopencm3/efm32/gg/irq.json
  GENHDR  include/libopencm3/efm32/g/irq.json
  GENHDR  include/libopencm3/efm32/tg/irq.json
  GENHDR  include/libopencm3/lm3s/irq.json
  GENHDR  include/libopencm3/stm32/f3/irq.json
  GENHDR  include/libopencm3/stm32/l1/irq.json
  GENHDR  include/libopencm3/stm32/f1/irq.json
  GENHDR  include/libopencm3/stm32/f2/irq.json
  GENHDR  include/libopencm3/stm32/l4/irq.json
  GENHDR  include/libopencm3/stm32/f4/irq.json
  GENHDR  include/libopencm3/stm32/f0/irq.json
  GENHDR  include/libopencm3/stm32/l0/irq.json
  GENHDR  include/libopencm3/stm32/f7/irq.json
  GENHDR  include/libopencm3/lpc13xx/irq.json
  BUILD   lib/stm32/f0
/bin/sh: -c: line 1: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 2: syntax error: unexpected end of file
make: *** [Makefile:64: lib/stm32/f0] Error 2
make: Leaving directory '/home/cf/src/opendps/libopencm3'

Any ideas why that is?

fiechr commented 3 years ago 
$ cd libopencm3
$ make clean V=1
  CLNHDR  include/libopencm3/vf6xx/irq.json
  CLNHDR  include/libopencm3/lpc17xx/irq.json
  CLNHDR  include/libopencm3/lpc43xx/m0/irq.json
  CLNHDR  include/libopencm3/lpc43xx/m4/irq.json
  CLNHDR  include/libopencm3/sam/3a/irq.json
  CLNHDR  include/libopencm3/sam/3u/irq.json
  CLNHDR  include/libopencm3/sam/3n/irq.json
  CLNHDR  include/libopencm3/sam/3x/irq.json
  CLNHDR  include/libopencm3/sam/d/irq.json
  CLNHDR  include/libopencm3/sam/3s/irq.json
  CLNHDR  include/libopencm3/efm32/lg/irq.json
  CLNHDR  include/libopencm3/efm32/gg/irq.json
  CLNHDR  include/libopencm3/efm32/g/irq.json
  CLNHDR  include/libopencm3/efm32/tg/irq.json
  CLNHDR  include/libopencm3/lm3s/irq.json
  CLNHDR  include/libopencm3/stm32/f3/irq.json
  CLNHDR  include/libopencm3/stm32/l1/irq.json
  CLNHDR  include/libopencm3/stm32/f1/irq.json
  CLNHDR  include/libopencm3/stm32/f2/irq.json
  CLNHDR  include/libopencm3/stm32/l4/irq.json
  CLNHDR  include/libopencm3/stm32/f4/irq.json
  CLNHDR  include/libopencm3/stm32/f0/irq.json
  CLNHDR  include/libopencm3/stm32/l0/irq.json
  CLNHDR  include/libopencm3/stm32/f7/irq.json
  CLNHDR  include/libopencm3/lpc13xx/irq.json
if [ -d lib/stm32/f0 ]; then \
    printf "  CLEAN   lib/stm32/f0\n"; \
    make -C lib/stm32/f0 clean SRCLIBDIR="/home/cf/src/opendps/libopencm3/lib\" || exit ; \
fi;
/bin/sh: -c: line 3: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 5: syntax error: unexpected end of file
make: *** [Makefile:75: lib/stm32/f0.clean] Error 2

I think the backslash right before the " is the issue, since it escapes it.

So something in this line maybe:

SRCLIBDIR:= $(subst $(space),\$(space),$(realpath lib))

realpath on the shell gives me a correct path without backslash though...

I think I'm really close, but not there yet...

fiechr commented 3 years ago

Ok, it seems to work by simply removing the insertion of the backslash.

#SRCLIBDIR:= $(subst $(space),\$(space),$(realpath lib))
SRCLIBDIR:= $(realpath lib)
fiechr commented 3 years ago

Ok, building works fine now, as far as I can tell.

I've connected the PCB with a STLinkV2 and using other software I can read the chip ID and type, so the connection seems to be working (I've flashed STM8/32 type µCs before, so not a total noob).

But if I try to connect using openocd, like described in the howto/documentation, I get this:

$ openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'adapter driver' not 'interface'
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
DEPRECATED! use 'swj_newdap' not 'hla newtap'
[... 331 lines more of that ...]
embedded:startup.tcl:265: Error: Infinite eval recursion
in procedure 'script' 
at file "embedded:startup.tcl", line 26
in procedure 'swj_newdap' called at file "target/stm32f1x.cfg", line 38
in procedure 'hla' called at file "target/swj-dp.tcl", line 28
in procedure 'swj_newdap' called at file "embedded:startup.tcl", line 265
in procedure 'hla' called at file "target/swj-dp.tcl", line 28
[... 331 times the same over and over again ...]
at file "embedded:startup.tcl", line 265

Am I doing something basically wrong here?

kanflo commented 3 years ago

Build problems with libopencm3 is probably handled more efficiently in the libopencm3 repo.

As for the OpenOCD issue I noted last week that the script syntax changed some time ago. The maintainers probably had good reasons but nevertheless it's a bit of a bother if you ask me. I guess you are using the scripts from the openocd dir of this repo. Try upgrading the scripts or downgrading the version of OpenOCD you are using.

fiechr commented 3 years ago

Thank you for your reply!

I found out, that OpenOCD starts, when I first change into the opendps folder and run

openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg

It doesn't work in the openocd/scripts folder (errors, see above post).

Now it seems to work as expected:

$ openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.210000
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f1x.cpu on 3333
Info : Listening on port 3333 for gdb connections

I could then connect to port 4444 and erase the flash of the µC.

After that building and flashing a DPS3003 with firmware and bootloader worked also fine.

Still not exactly sure about the Makefile thing, but it seems to work just fine without the backslash.

Thank you for your work on this! :)

hseibel12 commented 3 years ago

I have a working DPS3003! If you like, I can send you my binaries for flashing. Also for me: It took some time to get it calibrated. I tried the method of dpsctl several times but did not succeed. Finally I wrote my own calibration software using VB.NET. The release I have been using is a little bit older (somewher in the middle of 2019 I think). Feel free to contact me again if you like! Regards, Horst

fiechr commented 3 years ago

Thank you for your offer, maybe I will get back to you about that!

Using dpsctl.py I've now completed the calibration process, but something is still off, the displayed input voltage jumps up and down, which it didn't do before. Also the display only flashes when I enable the output. But I will try it again.

At first I've used a generic USB to serial adapter (PL2303 IC) connected to RX/TX and some things worked (like --ping), but others don't. Now I've connected one of the "original" RDTech adapters (using a CH340 IC), which somehow seems to work better.

$ ./dpsctl.py --device /dev/ttyUSB0 --baudrate 9600 --calibrate
For calibration you will need:
    A multimeter
    A known load capable of handling the required power
    A thick wire for shorting the output of the DPS
    2 stable input voltages

Please ensure nothing is connected to the output of the DPS before starting calibration!

Would you like to proceed? (y/n): y

Input Voltage Calibration:
Please hook up the first lower supply voltage to the DPS now
ensuring that the serial connection is connected after boot
Type input voltage in mV: 2494

Please hook up the second higher supply voltage to the DPS now
ensuring that the serial connection is connected after boot
Type input voltage in mV: 4992

Output Voltage Calibration:
Finding maximum output V_DAC value.......................... Done

Calibration Point 1 of 2, 10% of Max
Type measured voltage on output in mV: 3269

Calibration Point 1 of 2, 90% of Max
Type measured voltage on output in mV: 18653

Output Current Calibration:
Max output current of your DPS (e.g 5 for the DPS5005) in amps: 3
Load resistance in ohms: 10
Load wattage rating in watts: 100
Please connect the load to the output of the DPS, then press enter
Calibrating output current ADC............... Done

Constant Current Calibration:
Please short the output of the DPS with a thick wire capable of carrying 3.0A, then press enter

Finding maximum output A_DAC value.......................... Done
Calibrating output current DAC............... Done

Calibration Complete!
$ ./dpsctl.py --device /dev/ttyUSB0 --baudrate 9600 -cr
Calibration Report:
    A_ADC_K = 0.9988852143287659
    A_ADC_C = -22.790977478027344
    A_DAC_K = 0.0
    A_DAC_C = 204.0
    V_ADC_K = 8.156081199645996
    V_ADC_C = -117.81263732910156
    V_DAC_K = 0.2129485160112381
    V_DAC_C = -287.1286926269531
    VIN_ADC_K = -49959.9921875
    VIN_ADC_C = 56819496.0
    VIN_ADC = 1134
    VOUT_ADC = 15
    IOUT_ADC = 5
    IOUT_DAC = 0
    VOUT_DAC = 0
hseibel12 commented 3 years ago

When analyzing your calibration report I’ve found an error in two values:

    VIN_ADC_K = -49959.9921875
    VIN_ADC_C = 56819496.0

This are the values for input voltage calculation. They are expected to be much smaller than yours. In file dps_model.h you can find the values similar to your own specific device:

VIN_ADC_K shozld be around 16.8, means the max. calculatable input voltage is 16.8 * 4095 = 68.8V. DPS3003 are designed having an input voltage range of +6 … 40V.

And this is the second error I have found. The report shows input calibration voltages of ~ 2.5V and ~ 5V. Due to the specs of the device this is not enough! Otherwise your reports also shows an output adc calibration voltage of ~3.2V and ~ 18.6V. That’s physically not possible because the DPS only has a step down converter. I assume, your real input voltage is about 20V or higher?

So, please repeat your calibration. Appy the input voltage to your dps and measure this value with your DMM. Omit the smaller value and use it as 0.

Please find below as it should look now:

Von: Christian Fiebig @.> Gesendet: Samstag, 29. Mai 2021 22:18 An: kanflo/opendps @.> Cc: hseibel12 @.>; Comment @.> Betreff: Re: [kanflo/opendps] unexpected EOF while looking for matching ... (#242)

Thank you for your offer, maybe I will get back to you about that!

Using dpsctl.py I've now completed the calibration process, but something is still off, the displayed input voltage jumps up and down, which it didn't do before. Also the display only flashes when I enable the output. But I will try it again.

At first I've used a generic USB to serial adapter (PL2303 IC) connected to RX/TX and some things worked (like --ping), but others don't. Now I've connected one of the "original" RDTech adapters (using a CH340 IC), which somehow seems to work better.

$ ./dpsctl.py --device /dev/ttyUSB0 --baudrate 9600 --calibrate For calibration you will need: A multimeter A known load capable of handling the required power A thick wire for shorting the output of the DPS 2 stable input voltages

Please ensure nothing is connected to the output of the DPS before starting calibration!

Would you like to proceed? (y/n): y

Input Voltage Calibration: Please hook up the first lower supply voltage to the DPS now ensuring that the serial connection is connected after boot Type input voltage in mV: 2494

Please hook up the second higher supply voltage to the DPS now ensuring that the serial connection is connected after boot Type input voltage in mV: 4992

Output Voltage Calibration: Finding maximum output V_DAC value.......................... Done

Calibration Point 1 of 2, 10% of Max Type measured voltage on output in mV: 3269

Calibration Point 1 of 2, 90% of Max Type measured voltage on output in mV: 18653

Output Current Calibration: Max output current of your DPS (e.g 5 for the DPS5005) in amps: 3 Load resistance in ohms: 10 Load wattage rating in watts: 100 Please connect the load to the output of the DPS, then press enter Calibrating output current ADC............... Done

Constant Current Calibration: Please short the output of the DPS with a thick wire capable of carrying 3.0A, then press enter

Finding maximum output A_DAC value.......................... Done Calibrating output current DAC............... Done

Calibration Complete! $ ./dpsctl.py --device /dev/ttyUSB0 --baudrate 9600 -cr Calibration Report: A_ADC_K = 0.9988852143287659 A_ADC_C = -22.790977478027344 A_DAC_K = 0.0 A_DAC_C = 204.0 V_ADC_K = 8.156081199645996 V_ADC_C = -117.81263732910156 V_DAC_K = 0.2129485160112381 V_DAC_C = -287.1286926269531 VIN_ADC_K = -49959.9921875 VIN_ADC_C = 56819496.0 VIN_ADC = 1134 VOUT_ADC = 15 IOUT_ADC = 5 IOUT_DAC = 0 VOUT_DAC = 0

— You are receiving this because you commented. Reply to this email directly, https://github.com/kanflo/opendps/issues/242#issuecomment-850892886 view it on GitHub, or https://github.com/notifications/unsubscribe-auth/AMPLUQS7LQRV6KDMZGH54CLTQFDWDANCNFSM45O2L3WQ unsubscribe. https://github.com/notifications/beacon/AMPLUQXAGT2NGWK4SJJHGUTTQFDWDA5CNFSM45O2L3W2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGK3ZQVQ.gif

fiechr commented 3 years ago

Ok, I've re-run everything with the best multimeter I have, hooked on a 2.2 (2.27 to be exact) Ohms load with 100W for measuring and successfully completed the --calibrate process.

The input voltage is showing up stable now in the LCD and doesn't jump around anymore.

Unfortunately the device won't output any voltage or current when I enable it. I tried CV with 12 Volts, no output. Display shows 0V 0A (which is correct but not expected).

I also tried to power a bunch of LEDs with constant current (80 mA, Voltage set to max, in CC mode) -- also no output.

fiechr commented 3 years ago

@hseibel12: You're right the input voltage I entered was nonsense! I repeated the above mentioned calibration with about 6.5 V and 19 V. I additionally measured the exact value with my DMM and put in the actually value.

hseibel12 commented 3 years ago

When analyzing your post I have found some mistakes in the calibration report! First please have a look to the file dps-model.h. The values for the input voltage calibration are to be expected somewhere like

Your values are much to high. I think you did an error with the input voltage calibration. Your values of approx.. 2.5 and 5 volts are much too low. The DPS3030 hat an input operation range of 6V to 40V DC. I had the same problems when trying to calibrate at the beginning.

fiechr commented 3 years ago

This is the output I get now after calibration with the correct (and higher) input voltages (and all other) values:

$ dpsctl/dpsctl.py --device /dev/ttyUSB0 --baudrate 9600 -cr
Calibration Report:
    A_ADC_K = 1.0069375038146973
    A_ADC_C = -83.07911682128906
    A_DAC_K = -1.3510895155839012e-17
    A_DAC_C = 245.0
    V_ADC_K = 8.158334732055664
    V_ADC_C = -119.56439208984375
    V_DAC_K = 0.21321184933185577
    V_DAC_C = -287.9895324707031
    VIN_ADC_K = 16.752090454101562
    VIN_ADC_C = 30.79538345336914
    VIN_ADC = 1134
    VOUT_ADC = 15
    IOUT_ADC = 0
    IOUT_DAC = 0
    VOUT_DAC = 0

But as mentioned above, no output when enabled.

hseibel12 commented 3 years ago

The error is with the A-DAC_K. It should be around 0.12 not 0,00000000……

The formular for calculation is Amp = mx + b x -> ADC-Count

m -> V_DAC_K b -> V_DAC_C

this always calculates to around 0!

Von: Christian Fiebig @.> Gesendet: Sonntag, 30. Mai 2021 11:53 An: kanflo/opendps @.> Cc: hseibel12 @.>; Mention @.> Betreff: Re: [kanflo/opendps] unexpected EOF while looking for matching ... (#242)

This is the output I get now after calibration with the correct (and higher) input voltages (and all other) values:

$ dpsctl/dpsctl.py --device /dev/ttyUSB0 --baudrate 9600 -cr Calibration Report: A_ADC_K = 1.0069375038146973 A_ADC_C = -83.07911682128906 A_DAC_K = -1.3510895155839012e-17 A_DAC_C = 245.0 V_ADC_K = 8.158334732055664 V_ADC_C = -119.56439208984375 V_DAC_K = 0.21321184933185577 V_DAC_C = -287.9895324707031 VIN_ADC_K = 16.752090454101562 VIN_ADC_C = 30.79538345336914 VIN_ADC = 1134 VOUT_ADC = 15 IOUT_ADC = 0 IOUT_DAC = 0 VOUT_DAC = 0

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kanflo/opendps/issues/242#issuecomment-850972467 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AMPLUQTNM4TXV44KUSTYCQDTQIDHTANCNFSM45O2L3WQ . https://github.com/notifications/beacon/AMPLUQUBI7XS2I5GF74NKYDTQIDHTA5CNFSM45O2L3W2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGK4M6MY.gif

fiechr commented 3 years ago

Ok, I give up.

The calibration process also doesn't seem to work correctly.

I reset the calibration data and tried manually setting VOUT_DAC by pressing M1 + M2 and enter the value, but that also doesn't generate any voltage output. Not sure if this option is broken or I don't understand how it works. My idea was to measure the values manually and then calculate the K and C values. Like it is described here: https://leo.leung.xyz/wiki/DPS5005

But if I enter for example 50 for VOUT_DAC and enable the output, it still shows 0 Volts (even after resetting all calibration data to the defaults, like the are in the dps-model.h).

I think I put it in the trash, buy a new one and keep using the original firmware. I may not be perfect but at least it works. ;-)

Also the dpsctl.py script somehow differs in behavior from the description on this page: https://johan.kanflo.com/upgrading-your-dps5005/

I can change the function mode, calibrate and stuff like that, but can't set any voltage or current with --voltage 3000 for example, using the serial connection. I can enable the device and ping it, though. Also the --status option doesn't work or doesn't exist (anymore?).

hseibel12 commented 3 years ago

I understand your frustration. Similar happened to me ….

Attached the binaries of my working device. If it generally works, I expect the calibration not being absolutely perfect. If this basically works, the reason should be in the version you are using or in the compilation process … But, if it does, I would not suggest to use the calibration routines of the distro. There are some reasons that may lead to your problems.

hseibel12 commented 3 years ago

Sorry, forgot to say:

My files are working at the former baudrate setting of 115200 Baud! You should not use the original converter because it does not work at this higher baudrate. (I’ve been using very successfully a DIY FTDI-version!). If the files basically work, I can make a 9600 Buad version for you. Here’s the makefile I have been using for my binaries:

BINARY = opendps

Build with commandline interface rather than serial interface

COMMANDLINE := 0

The baudrate used for serial communications, defaults to 115200

BAUDRATE ?= 115200

Set build model, defaults to DPS5005

MODEL := DPS3003

Include splash screen

SPLASH_SCREEN := 0

Build wifi version (only change being that the wifi icon will start flashing

on power up)

WIFI := 0

Maximum current your DPS model can provide. Eg 5000mA for the DPS5005

This is usually set by MODEL but you can override it here

MAX_CURRENT := 3000

Please note that the UI currently does not handle settings larger that 9.99A

Print debug information on the serial output

DEBUG ?= 0

Font file

METER_FONT_FILE ?= gfx/Ubuntu-C.ttf

METER_FONT_SMALL_SIZE ?= 18

METER_FONT_MEDIUM_SIZE ?= 24

METER_FONT_LARGE_SIZE ?= 48

FULL_FONT_FILE ?= gfx/ProggyClean.ttf

FULL_FONT_SMALL_SIZE ?= 16

Color space for the DPS display. Most units use GBR but RGB has been spotted in the wild

COLORSPACE ?= 0

Colors for the main UI elements -- see ili9163c.h for list of colors

COLOR_VOLTAGE ?= WHITE

COLOR_AMPERAGE ?= WHITE

COLOR_INPUT ?= WHITE

Optional tinting for UI elements

TINT ?= ffffff

Enable CC mode

CC_ENABLE ?= 1

Enable merged mode

MERGED_ENABLE ?= 1

GIT_VERSION := $(shell git describe --abbrev=4 --dirty --always --tags)

CFLAGS = -I. -DGIT_VERSION=\"$(GIT_VERSION)\" -Wno-missing-braces

Output voltage and current limit are persisted in flash,

this is the default setting

CFLAGS += \

      -DCONFIG_DEFAULT_VOUT=5000 \

      -DCONFIG_DEFAULT_ILIMIT=500 \

      -DCONFIG_BAUDRATE=$(BAUDRATE) \

      -DCOLORSPACE=$(COLORSPACE) \

      -DCOLOR_VOLTAGE=$(COLOR_VOLTAGE) \

      -DCOLOR_AMPERAGE=$(COLOR_AMPERAGE) \

      -DCOLOR_INPUT=$(COLOR_INPUT) \

      -D$(MODEL)

Application linker script

LDSCRIPT = stm32f100_app.ld

OBJS = \

flashlock.o \

bootcom.o \

crc16.o \

uui.o \

uui_number.o \

func_cv.o \

settings_calibration.o \

hw.o \

pwrctl.o \

event.o \

past.o \

tick.o \

tft.o \

spi_driver.o \

ringbuf.o \

ili9163c.o \

mini-printf.o \

gfx_lookup.o \

font-full_small.o \

font-meter_small.o \

font-meter_medium.o \

font-meter_large.o \

gfx-cc.o \

gfx-crosshair.o \

gfx-cv.o \

gfx-merged.o \

gfx-padlock.o \

gfx-power.o \

gfx-thermometer.o \

gfx-wifi.o

ifdef MAX_CURRENT

           CFLAGS +=-DCONFIG_DPS_MAX_CURRENT=$(MAX_CURRENT)

endif

ifeq ($(DEBUG),1)

           CFLAGS +=-DCONFIG_DEBUG

           OBJS += dbg_printf.o

endif

ifeq ($(CC_ENABLE),1)

           CFLAGS +=-DCONFIG_CC_ENABLE

           OBJS += func_cc.o

endif

ifeq ($(MERGED_ENABLE),1)

           CFLAGS +=-DCONFIG_MERGED_ENABLE

           OBJS += func_merged.o

endif

ifeq ($(SPLASH_SCREEN),1)

           CFLAGS +=-DCONFIG_SPLASH_SCREEN

endif

ifeq ($(WIFI),1)

           CFLAGS +=-DCONFIG_WIFI

endif

ifeq ($(COMMANDLINE),1)

           CFLAGS +=-DCONFIG_COMMANDLINE

           OBJS += cli.o command_handler.o

else

           CFLAGS +=-DCONFIG_SERIAL_PROTOCOL

           OBJS += uframe.o protocol.o protocol_handler.o

endif

include ../libopencm3.target.mk

fonts:

           @python ./gen_lookup.py -l -o gfx_lookup

           @python ./gen_lookup.py -f $(FULL_FONT_FILE) -s $(FULL_FONT_SMALL_SIZE) -o full_small -a

           @python ./gen_lookup.py -f $(METER_FONT_FILE) -s $(METER_FONT_SMALL_SIZE) -o meter_small

           @python ./gen_lookup.py -f $(METER_FONT_FILE) -s $(METER_FONT_MEDIUM_SIZE) -o meter_medium

           @python ./gen_lookup.py -f $(METER_FONT_FILE) -s $(METER_FONT_LARGE_SIZE) -o meter_large

test:

           @make -C tests

doxygen:

           @doxygen config.dox
fiechr commented 3 years ago

I've added some debug messages to the dpsctl.py script and found something.

Near at the end of the calibration process, I get this (part of it):

Debug: Calculated DAC value: 204
Debug: iout_adc: 5 (sample #1)
Debug: iout_adc: 65534 (sample #2)
Debug: iout_adc: 5 (sample #3)
Debug: iout_adc: 4 (sample #4)
Debug: iout_adc: 65533 (sample #5)
Debug: iout_adc: 4 (sample #6)
Debug: iout_adc: 5 (sample #7)
Debug: iout_adc: 9 (sample #8)
Debug: iout_adc: 5 (sample #9)
Debug: iout_adc: 65534 (sample #10)
Debug: iout_adc: 5 (sample #11)
Debug: iout_adc: 5 (sample #12)
Debug: iout_adc: 1 (sample #13)
Debug: iout_adc: 5 (sample #14)
Debug: iout_adc: 5 (sample #15)
Debug: iout_adc: 65535 (sample #16)
Debug: iout_adc: 5 (sample #17)
Debug: iout_adc: 65534 (sample #18)
Debug: iout_adc: 4 (sample #19)
Debug: iout_adc: 5 (sample #20)
Debug: Average: 16387.1

Debug: Calculated DAC value: 204
Debug: iout_adc: 4 (sample #1)
Debug: iout_adc: 65534 (sample #2)
Debug: iout_adc: 5 (sample #3)
Debug: iout_adc: 65534 (sample #4)
Debug: iout_adc: 5 (sample #5)
Debug: iout_adc: 65533 (sample #6)
Debug: iout_adc: 65532 (sample #7)
Debug: iout_adc: 5 (sample #8)
Debug: iout_adc: 65535 (sample #9)
Debug: iout_adc: 5 (sample #10)
Debug: iout_adc: 4 (sample #11)
Debug: iout_adc: 1 (sample #12)
Debug: iout_adc: 5 (sample #13)
Debug: iout_adc: 0 (sample #14)
Debug: iout_adc: 4 (sample #15)
Debug: iout_adc: 4 (sample #16)
Debug: iout_adc: 5 (sample #17)
Debug: iout_adc: 4 (sample #18)
Debug: iout_adc: 5 (sample #19)
Debug: iout_adc: 4 (sample #20)
Debug: Average: 16386.4

Debug: Calculated DAC value: 204
Debug: iout_adc: 5 (sample #1)
Debug: iout_adc: 5 (sample #2)
Debug: iout_adc: 4 (sample #3)
Debug: iout_adc: 2 (sample #4)
Debug: iout_adc: 4 (sample #5)
Debug: iout_adc: 4 (sample #6)
Debug: iout_adc: 8 (sample #7)
Debug: iout_adc: 9 (sample #8)
Debug: iout_adc: 9 (sample #9)
Debug: iout_adc: 4 (sample #10)
Debug: iout_adc: 1 (sample #11)
Debug: iout_adc: 5 (sample #12)
Debug: iout_adc: 4 (sample #13)
Debug: iout_adc: 5 (sample #14)
Debug: iout_adc: 9 (sample #15)
Debug: iout_adc: 3 (sample #16)
Debug: iout_adc: 4 (sample #17)
Debug: iout_adc: 2 (sample #18)
Debug: iout_adc: 4 (sample #19)
Debug: iout_adc: 4 (sample #20)
Debug: Average: 4.75

Debug: Calculated DAC value: 204
Debug: iout_adc: 65535 (sample #1)
Debug: iout_adc: 6 (sample #2)
Debug: iout_adc: 5 (sample #3)
Debug: iout_adc: 6 (sample #4)
Debug: iout_adc: 5 (sample #5)
Debug: iout_adc: 1 (sample #6)
Debug: iout_adc: 4 (sample #7)
Debug: iout_adc: 65535 (sample #8)
Debug: iout_adc: 4 (sample #9)
Debug: iout_adc: 5 (sample #10)
Debug: iout_adc: 7 (sample #11)
Debug: iout_adc: 5 (sample #12)
Debug: iout_adc: 0 (sample #13)
Debug: iout_adc: 5 (sample #14)
Debug: iout_adc: 2 (sample #15)
Debug: iout_adc: 4 (sample #16)
Debug: iout_adc: 5 (sample #17)
Debug: iout_adc: 65534 (sample #18)
Debug: iout_adc: 5 (sample #19)
Debug: iout_adc: 65533 (sample #20)
Debug: Average: 13110.3

There are some "wrong" values, that mess up the average.

I wonder where they come from. I thought about removing the outliers, but that maybe only fix the symptom but not the actual issue.

All other readings seem to be fine:

For example:

Debug: Getting current reading at 4086.0000000000005 mV: 
Debug: vout_adc: 594 (sample #1)
Debug: vout_adc: 595 (sample #2)
Debug: vout_adc: 595 (sample #3)
Debug: vout_adc: 595 (sample #4)
Debug: vout_adc: 595 (sample #5)
Debug: vout_adc: 594 (sample #6)
Debug: vout_adc: 596 (sample #7)
Debug: vout_adc: 594 (sample #8)
Debug: vout_adc: 595 (sample #9)
Debug: vout_adc: 595 (sample #10)
Debug: vout_adc: 595 (sample #11)
Debug: vout_adc: 595 (sample #12)
Debug: vout_adc: 595 (sample #13)
Debug: vout_adc: 594 (sample #14)
Debug: vout_adc: 595 (sample #15)
Debug: vout_adc: 596 (sample #16)
Debug: vout_adc: 596 (sample #17)
Debug: vout_adc: 595 (sample #18)
Debug: vout_adc: 595 (sample #19)
Debug: vout_adc: 596 (sample #20)
Debug: Average: 595.0

Debug: iout_adc: 2114 (sample #1)
Debug: iout_adc: 2112 (sample #2)
Debug: iout_adc: 2112 (sample #3)
Debug: iout_adc: 2114 (sample #4)
Debug: iout_adc: 2113 (sample #5)
Debug: iout_adc: 2116 (sample #6)
Debug: iout_adc: 2113 (sample #7)
Debug: iout_adc: 2124 (sample #8)
Debug: iout_adc: 2115 (sample #9)
Debug: iout_adc: 2117 (sample #10)
Debug: iout_adc: 2121 (sample #11)
Debug: iout_adc: 2113 (sample #12)
Debug: iout_adc: 2116 (sample #13)
Debug: iout_adc: 2113 (sample #14)
Debug: iout_adc: 2116 (sample #15)
Debug: iout_adc: 2122 (sample #16)
Debug: iout_adc: 2112 (sample #17)
Debug: iout_adc: 2113 (sample #18)
Debug: iout_adc: 2112 (sample #19)
Debug: iout_adc: 2115 (sample #20)
Debug: Average: 2115.15

or

Calibration Point 1 of 2, 10% of Max
Type measured voltage on output in mV: 3270
Debug: vout_adc: 416 (sample #1)
Debug: vout_adc: 415 (sample #2)
Debug: vout_adc: 415 (sample #3)
Debug: vout_adc: 415 (sample #4)
Debug: vout_adc: 415 (sample #5)
Debug: vout_adc: 415 (sample #6)
Debug: vout_adc: 415 (sample #7)
Debug: vout_adc: 415 (sample #8)
Debug: vout_adc: 416 (sample #9)
Debug: vout_adc: 415 (sample #10)
Debug: vout_adc: 415 (sample #11)
Debug: vout_adc: 415 (sample #12)
Debug: vout_adc: 415 (sample #13)
Debug: vout_adc: 415 (sample #14)
Debug: vout_adc: 415 (sample #15)
Debug: vout_adc: 415 (sample #16)
Debug: vout_adc: 416 (sample #17)
Debug: vout_adc: 416 (sample #18)
Debug: vout_adc: 415 (sample #19)
Debug: vout_adc: 416 (sample #20)
Debug: Average: 415.25

Calibration Point 1 of 2, 90% of Max
Type measured voltage on output in mV: 26430
Debug: vout_adc: 3254 (sample #1)
Debug: vout_adc: 3255 (sample #2)
Debug: vout_adc: 3255 (sample #3)
Debug: vout_adc: 3257 (sample #4)
Debug: vout_adc: 3257 (sample #5)
Debug: vout_adc: 3255 (sample #6)
Debug: vout_adc: 3257 (sample #7)
Debug: vout_adc: 3253 (sample #8)
Debug: vout_adc: 3256 (sample #9)
Debug: vout_adc: 3258 (sample #10)
Debug: vout_adc: 3257 (sample #11)
Debug: vout_adc: 3257 (sample #12)
Debug: vout_adc: 3255 (sample #13)
Debug: vout_adc: 3256 (sample #14)
Debug: vout_adc: 3258 (sample #15)
Debug: vout_adc: 3261 (sample #16)
Debug: vout_adc: 3257 (sample #17)
Debug: vout_adc: 3253 (sample #18)
Debug: vout_adc: 3256 (sample #19)
Debug: vout_adc: 3257 (sample #20)
Debug: Average: 3256.2
hseibel12 commented 3 years ago

I assume this is an integer error. Just do not know where it comes from but please have a look to the below calculation (I used the values of the second block):

Original

Interger

Correct values

4

0

4

65534

65536

-2

5

0

5

65534

65536

-2

5

0

5

65533

65536

-3

65532

65536

-4

5

0

5

65535

65536

-1

5

0

5

4

0

4

1

0

1

5

0

5

0

0

0

4

0

4

4

0

4

5

0

5

4

0

4

5

0

5

4

0

4

Average:

16386,4

        2,4

I also have had errors with the original software. As the output of the step-down regulator contains noise which overlaps the DC-value we run into problems near zero:

If you subtract 1 from 0 the value of an 16 bit integer counts to 65535, on 2 it calculates 65534 and so on. This seems to be the result of an underrun error somewhere when subtracting an calibration offset from the adc-reading. See above table. I am sure the right column should be the correct values (Its’s average is 2.4 which is nearly Zero!). Logically this is much closer to your small DAC value (204). In your calibration the _DAC_C = 245.0 is the value for 0,00A.

I do not know where this happens. My workaround was modifying the original software mainly in the hw.c implementing a modified ADC_ISR and also averages for this values to reduce the impact of noise. If you like I can send you my files to look into and verify if this helps in your case.

cyber-murmel commented 2 years ago

The original issue was also addressed in the libopencm repo https://github.com/libopencm3/libopencm3/issues/1321