I have a Pololu PGM03A isp dongle to programm microcontrollers via avrdude. It worked great under Yosemite, but under El Capitan, it seems to disconnect and reconnect randomly every 1 - 5 sec. I can see this by the green status LED and in the terminal:
Macintosh:~ xxxxx$ ls /dev/cu.*
/dev/cu.Bluetooth-Incoming-Port /dev/cu.usbmodem00070153
/dev/cu.serial1 /dev/cu.usbmodem2169
/dev/cu.usbmodem00070151
Macintosh:~ xxxxx$ ls /dev/cu.*
/dev/cu.Bluetooth-Incoming-Port /dev/cu.usbmodem00070153
/dev/cu.serial1
Macintosh:~ xxxxx$ ls /dev/cu.*
/dev/cu.Bluetooth-Incoming-Port /dev/cu.usbmodem00070153
/dev/cu.serial1 /dev/cu.usbmodem2177
/dev/cu.usbmodem00070151
As you can see, the usbmodem00070151 is there, then not, and then again available. The usbmodem00070153 belongs to the ISP Dongle too, but it provides an different feature than programming the microcontroller (it's an USART Port or something I think).
Edit: The latter modem now also disconnects.
When I try to flash the microcontroller, it sometimes manages it to write some bytes, but the time between 2 disconnects is to short to finish the job:
Writing | ######################## | 47% 0.08s
avrdude: ser_recv(): read error: Device not configured
make: *** [all] Error 1
Does anyone know how to fix this?
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.
I am trying to connect via serial line from a FreeBSD box to a Sun Fire V210 running Solaris 8.
I have a serial line connected from the FreeBSD serial port to the Sun Serial Management port.
On the FreeBSD box (observer) I have this in /etc/remote:
hardwire:\
:dv=/dev/usb0:br#9600:el=^C^S^Q^U^D:ie=%$:oe=^D:
When I do tip hardwire I get:
# tip hardwire
fcntl: Invalid argument
One note: There was a power outage that caused the FreeBSD box to be rebooted.
Before the power outage, tip hardwire worked fine.
I do not see any files in /var/spool/lock/
Any help?
This question is related to this, Cannot program ESP8266, but different settings.
I have a NodeMCU devkit v1, its comercial name is NodeMCU v2. I tried different setting to connect the devkit.
First the devkit has a usb-serial bridge (CP2102) and voltage adapter from 5v (USB) to 3.3v. So I connect the devkit with the machine via USB. The driver is installed correctly, and I can see the com, it is COM3.
After turning on the NodeMCU I can see a Wifi AI-THINKER-adfe21.
Then I tried with the nodemcu-flasher - WINDOWS.
Without any button or pin to ground. I press Flash in the flasher and stay Waiting MAC and the log says Begin Find ESP8266 as the question I told in the begin and the ESP's led (blue led) blinks.
Holding FLASH, press RESET, release FLASH. Still the same like 1.
Wire D3 (GPIO0) to GND. Same result
With ESPtool - LINUX - Trying these commands
python2 esptool.py --port /dev/ttyUSB0 read_mac
python2 esptool.py --port /dev/ttyUSB0 write_flash 0x00000 firmware.bin
Without any button or pin to ground. The output for the commands was Connecting... A fatal error occurred: Failed to connect to ESP8266
Holding FLASH, press RESET, release FLASH. Same
Wire D3 (GPIO0) to GND. Same result.
Via Arduino IDE, I installed the ESP8266 board and selected NodeMCU 1.0. The result to try upload some code -> warning: espcomm_sync failed error: espcomm_open failed
I tryed to connect the NodeMCU without the USB. Using an Arduino UNO, connecting like following... And I'm getting the same errors.
UNO | NodeMCU
5v -> Vin
GND -> GND
Rx -> Tx
Tx -> Rx
The last test I made, it is with Putty or Arduino SerialMonitor connect to the COM3 or /dev/ttyUSB0 and turning on the NodeMCU. I should see some characters or garbage if it in different baud rate. But I got nothing, the terminal is blank. I restart the NodeMCU, put it in Flash mode. No response.
Are there some solution, tip or trick to make it programmable?
PS: I know the NodeMCU is in Flash mode because its wifi disappear.
EDIT:
I discovered something.
I just connected the NodeMcu with a mobile charger and connect the D0 to Serial ground and D3 to Serial Rx. On the putty with 115200 Baudrate, I'm able to get the following code on reset.
node : sta(mac address) + softAP(mac address)
add if0
add if1
dhcp server start:(ip:192.168.4.1, mask:255.255.255.0,gw:192.168.4.1)
bcn 100
I have been working with both the node-mcu flasher and the esptool.
First in the esptool yo should use more parameter in the call. Use something like this
python esptool.py -p SERIAL_PORT_NAME --baud 9600 write_flash --flash_size=8m 0 firmware-combined.bin
Be careful with the baudrate, i always use 9600.
If you prefer using the windows program you should only connect the ESP8266 through usb and dont connect any other pin. If it still gives you problems you should check that u have installed the com ports.
Good Luck
if you are using esptool (either in Linux or windows), you should include -fm and -fs inside the esptool command. There will be no response if you did not include those 2 parameter even though it show successfully upload. you can refer the detail in this youtube tutorial or its description for flashing firmware in nodemcu V2 or v1.0.
esptool.py --port [serial-port-of-ESP8266] write_flash -fm [mode] -fs [size] 0x00000 [nodemcu-firmware].bin
Tutorial on how to flash firmware using esptool(windows):
https://www.youtube.com/watch?v=MHrm7axsImI
cheers!
Maybe you can try this setting.
$sudo esptool.py -p /dev/ttyUSB0 --baud 115200 write_flash -fs 16m -fm qio -ff 0x00000 firmware.bin
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.