unexpected EOF while looking for matching ... #242
Comments
I think the backslash right before the " is the issue, since it escapes it. So something in this line maybe:
I think I'm really close, but not there yet... |
|
Ok, it seems to work by simply removing the insertion of the backslash. |
|
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: Am I doing something basically wrong here? |
|
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. |
|
Thank you for your reply! I found out, that OpenOCD starts, when I first change into the opendps folder and run
It doesn't work in the openocd/scripts folder (errors, see above post). Now it seems to work as expected: 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! :) |
|
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
|
|
Thank you for your offer, maybe I will get back to you about that! Using At first I've used a generic USB to serial adapter (PL2303 IC) connected to RX/TX and some things worked (like |
|
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, <#242 (comment)> view it on GitHub, or <https://github.com/notifications/unsubscribe-auth/AMPLUQS7LQRV6KDMZGH54CLTQFDWDANCNFSM45O2L3WQ> unsubscribe. <https://github.com/notifications/beacon/AMPLUQXAGT2NGWK4SJJHGUTTQFDWDA5CNFSM45O2L3W2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGK3ZQVQ.gif>
|
|
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 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. |
|
@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. |
|
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.
|
|
This is the output I get now after calibration with the correct (and higher) input voltages (and all other) values: But as mentioned above, no output when enabled. |
|
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 <#242 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMPLUQTNM4TXV44KUSTYCQDTQIDHTANCNFSM45O2L3WQ> . <https://github.com/notifications/beacon/AMPLUQUBI7XS2I5GF74NKYDTQIDHTA5CNFSM45O2L3W2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGK4M6MY.gif>
|
|
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: 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 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 I can change the function mode, calibrate and stuff like that, but can't set any voltage or current with |
|
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.
|
|
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
|
|
I've added some debug messages to the Near at the end of the calibration process, I get this (part of it): 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: or |
|
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.
|
|
The original issue was also addressed in the libopencm repo libopencm3/libopencm3#1321 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm using Arch/Manjaro.
Whenever I try to build I get this error:
Any ideas why that is?
The text was updated successfully, but these errors were encountered: