I am trying to open a connection and pass a value for a given channel
In order to do this I need to open a connection to the enttec open dmx usb. But I am unable to create a connection
I tried to list devices and make sure the SN matches with the HW
In [34]: import ftd2xx as ft
In [35]: ft.listDevices()
Out[35]: [b'AL05J8AO']
In [36]: ftd2xx.openEx('AL05J8AO', ftd2xx.ftd2xx.OPEN_BY_SERIAL_NUMBER)
---------------------------------------------------------------------------
DeviceError Traceback (most recent call last)
<ipython-input-36-9780ebf9f5e6> in <module>
----> 1 ftd2xx.openEx('AL05J8AO', ftd2xx.ftd2xx.OPEN_BY_SERIAL_NUMBER)
~/raj3_env/lib/python3.6/site-packages/ftd2xx-1.1.0rc1-py3.6.egg/ftd2xx/ftd2xx.py in openEx(id_str, flags)
106 instance for it"""
107 h = _ft.FT_HANDLE()
--> 108 call_ft(_ft.FT_OpenEx, id_str, _ft.DWORD(flags), c.byref(h))
109 return FTD2XX(h)
110
~/raj3_env/lib/python3.6/site-packages/ftd2xx-1.1.0rc1-py3.6.egg/ftd2xx/ftd2xx.py in call_ft(function, *args)
42 status = function(*args)
43 if status != _ft.FT_OK:
---> 44 raise DeviceError(status)
45
46 def listDevices(flags=0):
To the best of my knowledge the VCP driver is loaded by default for non windows systems (or if the EEPROM is flashed accordingly). Chances are that you have to unload the VCP first to enable the D2XX driver. To check if this is the case for you, you can try to start one of the examples provided by ftdi. Furthermore you could try to address the device not by SN but by port number.
If the VCP is the problem, it can be removed via "sudo rmmod ftdi_sio". Sometimes an additional "sudo rmmod usbserial" is required.
Some alternative solutions and approaches are discussed here
EDIT:
An alternative might be sticking with the VCP driver and just opening it via e.g. pyserial. If I see it correctly the device you want to interface actually has a RS485 with BaudRate = 250000, PARITY_NONE, STOP_BITS_2, BITS_8
according to the code example they provide. So a long as no special GPIO access is required, you might be good.
But chances are that you might have problems with opening the VCP as well and that you have to fix a driver problem first. Sadly I am not an expert in this field...
Related
I've got some issues flashing firmware using an STLINKv2 (from a Nucleo board) with an nRF52 target device using SWD. In short, I'm able to "connect" to the nRF52 (I can open a telnet session), but as soon as I try a Program command, I get a non-helpful error (below). Hex file is compiled using Arduino "export bin" file option. (Using a SEGGER isn't an option right now)
More details below:
OSX version 10.14.6, OpenOCD version 0.10.0.
Running in terminal openocd -f interface/stlink-v2-1.cfg -f target/nrf52.cfg returns:
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
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
adapter speed: 10000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : STLINK v2 JTAG v28 API v2 SWIM v17 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 0.014192
Error: target voltage may be too low for reliable debugging
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
I can then telnet in using telnet localhost 4444:
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
In telnet, I can run basic commands on the nRF52, and when I execute: program /full/path/to/hex/file.hex I get the following message:
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
** Programming Started **
embedded:startup.tcl:476: Error: ** Programming Failed **
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 532
at file "embedded:startup.tcl", line 476
Would love to know what I'm doing wrong!
ETA: The voltage error is not related; that was due to a bug in the Nucleo SWD programmer hardware one has to solder a jumper wire from the VDD-TARGET to the outward pin of R24. (When you break off the Nucleo from the STLINK board, you break off this link) Have done that, however the problem persists.
I have a custom nrf52 chip on a pcb with swd pins exposed. I have cloned and installed the latest openocd from https://github.com/ntfreak/openocd. The latest version includes all the latest pathes for the nrf52 chip, so no need for any additional changes as suggested in many older guides online. I am able to connect to the chip using ST-LinkV2. when connected I can read and write memory locations using mdw and mdb. I can also run some basic openocd commands like dump_image e.t.c, which confirms that the setup is good. But halt and program commannds always lead to errors like:
JTAG failure -4
JTAG failure -4
JTAG failure -4
JTAG failure -4
JTAG failure -4
JTAG failure -4
target halted due to debug-request, current mode: Thread
xPSR: 00000000 pc: 00000000 msp: 00000000
jtag status contains invalid mode value - communication failure
Polling target nrf52.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
Previous state query failed, trying to reconnect
jtag status contains invalid mode value - communication failure
Polling target nrf52.cpu failed, trying to reexamine
if I try to use flash image_write I get the error,
JTAG failure
Error setting register
error starting target flash write algorithm
Failed to enable read-only operation
Failed to write to nrf52 flash
error writing to flash at address 0x00000000 at offset 0x00000000
in procedure 'dap'
jtag status contains invalid mode value - communication failure
Polling target nrf52.cpu failed, trying to reexamine
I have read different guides online, and one of the possible solutions involves the APPPROTECT register which has to be disabled to enable any writes to flash.
APP_PROTECT, But the dap commmand which is supposed to help us access this bit,
dap apreg 1 0x04 0x01
returns an error:
invalid subcommand apreg 1 0x04 0x01
Please, I will like to know if anyone has had success programming a new empty nrf52 chip with the stlink-v2 and the steps which are necessary, or if any one has encountered similar problems. Thanks.
Here is my config file:
#nRF52832 Target
source [find interface/stlink.cfg]
transport select hla_swd
source [find target/nrf52.cfg]
#reset_config srst_nogate connect_assert_srst
I solved the "protected nRF52" chip problem this way, on Windows, using a Particle.io Debugger https://store.particle.io/products/particle-debugger setup to program nRF52 chips from Arduino as described in https://www.forward.com.au/pfod/BLE/LowPower/index.html
Note: The recovery process described here does NOT need Arduino to be installed
Download OpenOCD-20181130.7z pre-compiled openocd for windows from
http://gnutoolchains.com/arm-eabi/openocd/
The latest version of openocd src on https://github.com/ntfreak/openocd should also work as it includes the apreg cmd in target\arm_adi_v5.c
unzip, open cmd prompt to unzip dir, enter cmd
bin\openocd.exe -d2 -f interface/cmsis-dap.cfg -f target/nrf52.cfg
response
Info : auto-selecting first available session transport "swd". To override use '
transport select <transport>'.
adapter speed: 1000 kHz
cortex_m reset_config sysresetreq
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: FW Version = 1.10
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x2ba01477
Error: Could not find MEM-AP to control the core
Info : Listening on port 3333 for gdb connections
Open telnet program eg teraTerm and connect to localhost on port 4444, i.e. 127.0.0.1 telnet port 4444
cmd window shows
Info : accepting 'telnet' connection on tcp/4444
in telnet (i.e. teraTerm) type
nrf52.dap apreg 1 0x04
returns 0 <<< chip protected
then
nrf52.dap apreg 1 0x04 0x01
then
nrf52.dap apreg 1 0x04
returns 1 << chip un-protected
then power cycle board
Can now use arduino ide to flash softdevice and code low power BLE
Even though the dap command is listed by openOCD help, it isn't implemented for transport hla_swd that you have to use with ST-Link.
If the ST-Link is a generic type from China, it can be upgraded to CMSIS-DAP which uses the swd transport and supports the nrf52.dap apreg 1 0x04 0x01 command to disable the readback protection and erase the flash. You'll need another ST-Link to do that, or you can instead install CMSIS-DAP on a generic STM32F103C8T6 board.
After that you can either use ST-Link to program the nRF52 or continue using CMSIS-DAP, which can also be used to program STM32 MCU.
Nucleo board embedded ST-Links can also be upgraded to J-Link, which allow the use of the "recover" option in nRFgo Studio to erase the flash, it should also work with "nrfjtool --recover" or OpenOCD.
If anyone encounters this problem, I solved the problem by getting an original Jlink-Edu. I also had to pull the reset pin of the microcontroller high to get the jlink working.
There are lots of JTAG messages.
I think you might be missing the
transport select hla_swd
line in your (board) cfg file. The NRF5x chips only work properly with SWD, and ST-Link uses the hla_swd variant.
Emails are not being deliver to a particular email IDs.
We are using Sentora panel and Postfix mail server.
Error message:
Command died with signal 6: "/usr/libexec/dovecot/deliver"
Mail log:
Feb 14 09:50:27 host postfix/pipe[24913]: CBD7D2010A5: to=,
relay=dovecot, delay=13047, delays=13045/0/0/1.3, dsn=4.3.0,
status=SOFTBOUNCE (Command died with signal 6:
"/usr/libexec/dovecot/deliver")
Please help.
Signal 6 is SIGABRT, which is typically sent when there is an internal problem with the code of Dovecot's deliver binary. There are a number of reasons this could happen.
You can turn on LDA logging within your Dovecot config to get more insight on what's actually happening:
protocol lda {
...
# remember to give proper permissions for these files as well
log_path = /var/log/dovecot-lda-errors.log
info_log_path = /var/log/dovecot-lda.log
}
this can also happen when mail_temp_dir (default: /tmp) does not have enough space to extract attachments. it was fixed in https://github.com/dovecot/core/commit/43d7f354c44b358f45ddd10deb3742ec1cc94889 but is not yet available in some linux distributions (such as debian bullseye).
I have been trying to get my WiFi module, ESP8266 to work in the "update mode" where you connect GPIO_0 to ground.
The board is functional when GPIO_0 is disconnected from ground and I am able to use AT commands to talk to it via the Arduino serial monitor.
Following is what it prints upon connecting:
ets Jan 8 2013,rst cause:4, boot mode:(3,6)
wdt reset
load 0x40100000, len 1396, room 16
tail 4
chksum 0x89
load 0x3ffe8000, len 776, room 4
tail 4
chksum 0xe8
load 0x3ffe8308, len 540, room 4
tail 8
chksum 0xc0
csum 0xc0
2nd boot version : 1.4(b1)
SPI Speed : 40MHz
SPI Mode : DIO
SPI Flash Size & Map: 8Mbit(512KB+512KB)
jump to run user1 # 1000
rrlÌÿ
Ai-Thinker Technology Co.,Ltd.
ready
However, I cannot do most things as the firmware is out of date.
As a result, I am trying to update it (with no success)
When I set it to update mode and use the python tool "esptool.py", the script fails to connect to the ESP board.
Following is the command:
python esptool.py -p /dev/ttyUSB0 write_flash 0x00000 "/home/aditya/Desktop/v0.9.2.2 AT Firmware.bin"
Following is the output:
Connecting...
Traceback (most recent call last):
File "esptool.py", line 532, in <module>
esp.connect()
File "esptool.py", line 159, in connect
raise Exception('Failed to connect')
Exception: Failed to connect
I have even run the Windows counterpart of this tool "ESP Flasher" with no luck
The one who helps will be given a cookie (unless you value privacy)
This tool (esptool.py) works with a ROM bootloader, which is only started if GPIO_0 is tied to the GND during hardware reset. Bootloader also times out pretty fast, so just connecting GPIO_0 to the ground is not enough.
For me, following works:
Connect TXD/RXD/GND/VCC to the PC and CH_PD to VCC;
Make sure I can talk to the firmware via terminal (picocom/minicom/etc);
Connect GPIO_0 to the GND;
Connect RST to GND;
Release RST;
Run esptool.py
If still no dice, swap 5 and 6 above, i.e. first run esptool.py, then (as quickly as possible) release/disconnect RST. You will only have a second or two before esptool.py times out.
Try making the ground of all devices connected: if you have a level shifter inbetween, make sure the GND is tied to the GND of Arduino and also to the RS232 GND.
I've got a Tcl/Expect program that reads and writes data to the serial port.
I did all of my development and testing on a Fedora 7 machine, but I'm now trying to run the same code in Ubuntu 8.10, and I'm getting the following error:
spawn: returns {0}
bad option "-mode": should be one of -blocking, -buffering, -buffersize, -encoding, -eofchar, or -translation
while executing
"fconfigure $port -mode 19200,n,8,1"
(file "./scan1.tcl" line 31)
I have no issues in Fedora, just Ubuntu. It would seem that it doesn't like the serial options being given to fconfigure, but I don't know of an alternate way of doing this.
Both machines have Tcl 8.4.
Here's the relevant code snippet:
#Open serial port
set portname "/dev/ttyS0"
spawn -open [set port [open $portname "r+"]];#This is a beast!
fconfigure $port -mode 19200,n,8,1
Does anyone know what's wrong? Thanks for your help!
Some research seems to indicate that the [fconfigure] command doesn't offer the -mode switch when it doesn't recognize the channel in question as being a true serial port (though I don't see this mentioned in the docs). Ultimately, that decision seems to rely on an "isatty()" system call, which is apparently failing to report the channel as a TTY. More info can be found here:
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/ea0e772c59fa1e52/949c04fe4cebc2a3?q=fconfigure+mode+group:comp.lang.tcl#949c04fe4cebc2a3
According to the above thread, this could be due to a misconfigured Tcl.
Update... I see the serial configuration options (including -mode) are documented with the [open] command. There, it mentions that [fconfigure] can be used to query or set the additional options specific to serial ports. The [fconfigure] docs should probably be updated to reflect that fact also.
Bottom line, Tcl doesn't think your port really is a serial port under Ubuntu, though I don't know why...
Could be a bug. It has been in the past.
http://sourceforge.net/tracker/?func=detail&atid=110894&aid=218617&group_id=10894