I recently purchased an Arduino with an atmega1280 on it. I did not get it to use the Arduino IDE but just as a handy board to use with AVR Studio and my Dragon.
I purchased a new computer around the same time and it is running windows 7 64bit, I downloaded AVR Studio 5.1 and plugged in my Dragon. I upgraded to the latest firmware as it forces you to do. I then connected the Dragon to the Arduino and I get the following error:
[ERROR] Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00, ModuleName: TCF (TCF command: Device:startSession failed.)
I have verified the ribbon cable pinouts are the same on both ends and have continuity. Pin 1 goes to Pin 1 and so forth. AVR Studio can read the 5.0V on the sense line but that is it.
I then installed libusb-win (1.6.2.0) and used avrdude to get a more descriptive error:
pasebin output
I have tried to wire up an atmega8 and atmega128 on breadboard with ISP and JTAG connections and I get the same errors as above but it makes more since so troubleshoot the PCB to PCB connection issue to eliminate any mis-wireings I may have.
Any idea where to start looking for the problem???
One thing is the power on the JTAG header, and another is on the actual chip. Could you try checking connections all the way from the AVR to the JTAG-pins? In my experience, there are almost always bad wiring, even if you think it is perfect.
When that is not the case, the AVR is not getting power.
Are you trying ISP or JTAG or both? Does the AVR support JTAG?
Is it ISP extracted from a JTAG connector?
Atmel's JTAGICE mkII documentation explains quite a bit of both ISP and JTAG.
I just recently build a board with JTAG connection (http://www.avrfreaks.net/modules/PNphpBB2/files/display_105.png), which may be descriptive on how to connect your JTAG, and this I know is working ;)
Related
Overview
I need to program a recently purchased STM32F407ZGT6 board
In 'normal mode' my computer doesn't recognizing the board as a Ports (COM & LPT)/STMElectronics Virtual COM Port when connected via USB (I'm using a Windows 10 Pro). The LEDs turn on and I can get it into 'DFU mode'. When I try to debug the code, I get the "No ST-LINK detected!" message in either mode.
This is my first time connecting the board and also my first time dealing with STM32
Despite the instructions, I want to program the board using C directly from the STM32CubeIDE
Here is what I found
I found this question [1] where Device Manager reads the STM as Disk drives/STM32. My PC identifies it as mass storage and portable devices on Windows 10 Pro. When in DFU mode, I can see it as Universal Serial Bus Device/STM32 BOOTLOADER on Device Manager.
The tutorial [2] uses Flash Loader Demo and this older tutorial [3] uses STSW-STM32080, but both of the drivers are tagged as obsolete on the ST Website. STM32CuberProgrammer is indicated instead, but I would like to flash and debug directly from the IDE. Another forum reply [4] says that "you need a ST-link V2 programmer to program the brand new chip".
In summary
I can see the solution being one of the following options:
correct answer I need to use the ST-LINK-V2 to program from the IDE and that's the only way
I need to flash a bootloader via STM32CubeProgrammer to get it to work via IDE (is there a standard code for this?)
I have to build the cross-compiler for MicroPython [5] before I get to program it in C
What are your thoughts? Any other driver or idea that I might be missing?
Update
I went on and got my hands on a ST-LINK V2. I made the connection via the JTAG/SWD connector (see schematic) and I also tried connecting directly with the pins:
ST-Link
JTAG/SWD
Pins
SWCLK
9
PA14
SWDIO
7
PA13
GND
10
GND
3.3V
1
3.3V
RST
3
PB4
The ST-Link is not recognized. The ST-Link blinks and the board is powered up, but that's it. Device manager before and after shows the same.
So I went on checking if I was missing any new driver/program. I installed the STSW-LINK004 (STM32 ST-LINK Utility v4.6.0.0) based on these instructions, but no luck, Utility cannot find it either. I've reseted the computer after each driver installation. If I connect my boardvia USB in DFU mode, it is still recognized as STM32 BOOTLOADER, if I do it with the ST-Link, nothing changes.
Update solution
It turned out the ST-Link was faulty and therefore not connecting. After finding another ST-LINK/V2, the computer can recognize the board under Universal Serial Bus devices/STM32 STLink.
Debugging with STM32CubeIDE will always need an ST-LINK or other JTAG or SWD debug probe.
The bootloader allows you to program the microcontroller with a binary image, and that's it. The IDE will happily produce such a binary image, and possibly even have a wizard for transferring it via DFU. But that's only programming, no debugging And only be when the bootloader is running. If you did debug-like things like reading RAM contents, you'd get what the bootloader stores there while it is running, not the variables that your own program uses.
The ROM bootloader supports several ways of receiving new code to flash -- USB (DFU), CAN, I2C, SPI, UART. That last is not a USB Virtual COM port, it is honest-to-God UART using the USART peripheral in the microcontroller and RX/TX pins.
If you want a virtual COM port for your custom firmware to use to send data to the PC, you have to program the USB peripheral.
Is there an inbuilt or pre-existing feature I can use to accomplish Flashing a Cyclone IV's(EP4CE6E22C8) SROM(W25Q16BV) chip via its JTAG connection? Maybe some setting when compiling in Quartus to tell the FPGA "Hey flash this". Or a specific command for OpenOCD.
I saw that there are IP cores to manually flash the device, but I really do not want to go down that rabbit hole. Programming my own flasher sounds like an unnessisary hell at my experience level.
I hope this is good enough of a question, Ive been suffering with this for months, if you need any more information
INFO:
I have a W25Q16BV SROM chip connected directlyto a EP4CE6E22C8 in AS config mode. (Data input on SROM has single direct connection to FPGA's ASDO)
And to that FPGA I have a JTAG connection that connects to my computer via a J-Link adapter.
Controlling the J-Link adapter is OpenOCD that uploades compiled data(SVF file) provided by Quartus Prime.
The board is from an obscure seller, but it did come pre-flashed with an example program that starts upon every reset, so there must be some way they uploaded this.
I could program and debug this project for the first time. But the problem is that I can't reprogram or debug it again. There is no bootloader on the chip. The only way to communicate with this chip is SWD. As a debugger, I am using Atmel ice. The microchip is SAMD21E16B-U. The project is created by Atmel Start. Visual Studio is used as an IDE to import the project.
After debugging again, the error is:
The problem may be because of setup. I am not sure what I missed. I followed the visualGDB website for importing this project.
I checked the power connection.
There is no option for "connect under reset" on visualgdb debug setting. However, this option was available on STM chips.
I really appreciate it if you can guide me on what I can do for reprogramming this chip? Or which information I should look for. Thanks for any helpful recommendations, in advance.
The following steps solved my problems. I think erasing my chip was helpful to reprogram the chip. I am not sure which step exactly caused the error. But after these steps, I didn't get that error.
Choose the right chip: samd21e16b instead of samd21e16b-U (The first selection was based on a schematic. My schematic wasn't correct (look at the physical chips on our board or use a microchip studio. Microchip studio detected the right chip for me). I have selected an incorrect device while creating our project (e.g. Our device has different SRAM, Flash, and packages.)). Then, I needed to set up again and choose the right chip.
Erase the chip by microchip studio and was able to reprogram it. So, I am using microchip studio for erasing the chip and getting back to visual studio, and then reprogramming, or debugging it
Checked the power connection (connect the Vcc 3.3 by SWD connector and
make sure that the green light on Atmel ice is on before debugging (The green led on Atmel ice is showing that the chip power is ok and correct)
also, I should make sure that my chip is connected to pc by USB. It may be different in your chip to provide power)
I didn't change my debugger from Atmel ice to J-Link but it was a solution that the visualGDB (sysProgs) support team mentioned. I will only add their quotes briefly. It may be helpful for the ones who want to solve the problem by the visual studio and reset the chip. But I didn't change my debugger or didn't configure openOCD. I used microchip studio and reset the chip instead.
VisualGDB Support team: This looks like a device connectivity issue rather than something VisualGDB-specific. Our best advice would be to try using Segger J-Link. It comes with its own fully supported replacement for OpenOCD, which generally works better in many edge cases. VisualGDB supports both OpenOCD and J-Link software, so all the features you previously used will continue working the same way.
VisualGDB does not manage resetting/erasing directly. It simply launches the open-source OpenOCD tool that handles the low-level communication with the target.
You might be able to configure OpenOCD to change the reset behavior by editing the OpenOCD script files, however, this is something to do at your own risk and it may require extensive research into OpenOCD internals.
If you are looking for an easy out-of-the-box solution, please consider using Segger J-Link instead.
I'm trying to flash a basic LED blinking program to my Nucleo F413ZH board using the STM32CubeIDE, but whenever I try to debug it says:-
"No ST-LINK connected! Please connect ST-LINK and restart the debug
session."
The board has the PWR and COM LEDs blinking, meaning the USB I've connected to the board is providing power, I just can't upload any code.
I've tried using the ST-LINK upgrade firmware (https://www.st.com/en/development-tools/stsw-link007.html) to install new drivers as that's what some people online have suggested but the program won't respond once I've downloaded it, which seems to be a side issue of not registering connectivity.
I'm not sure whether this is an issue with drivers or if my hardware is busted. I'm using macOS Big Sur.
In Windows 10 this problem occurs as a result of an incorrect driver priority as pointed out in this post. Error in initializing ST-Link Device - Failed to connect to device perhaps this solution might point you in the right direction. I have set up several new M1 Mac Minis in the past few months for clients, Big Sur and the new M1 have several compatibility issues like slow network drive access and flashing screens, the Android M1 chip has dramatically less external connectivity which is why they went from 4 thunderbolt ports on the last intel Mac Mini to just 2. I would not be surprised if Big Sur is the core of the problem. Try a different computer if you have the opportunity.
I was also getting the same error on ubuntu system while using stm cube ide, with st-link v2 programmer.
blue led was continuously blinking.
but solved the error just by reconnecting the usb-extention-hub, now when connected blue led is on (no blink), and now i can program and debug the target.
Finally the sparkfun board edge boards arrived today ;-)
Following this well written guide : https://codelabs.developers.google.com/codelabs/sparkfun-tensorflow/#3 i am stuck with the following NoResponseError when trying to flash the code on the Ambiq, with the uart_wired_update.pyscript, that comes with tensorflow examples
opprud$ python3 tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py -b 115200 /dev/cu.usbserial-1430 -r 1 -f main_nonsecure_wire.bin -i 6
MOJ/Connecting with Corvette over serial port /dev/cu.usbserial-1430...
Sending Hello.
No response for command 0x00000000
Traceback (most recent call last):
File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 336, in <module>
main()
File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 38, in main
connect_device(ser)
File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 58, in connect_device
response = send_command(hello, 88, ser)
File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 235, in send_command
raise NoResponseError
__main__.NoResponseError
My setup:
Macbook pro, tried both old 15" & new 13"
Sparkfun serial basic breakout, USBC version (default jumped to 3v3)
FTDI 3v3 serial cable
I have tried
two different edge boards, with the correct Key14 & reset combo + misc variants and timing
legacy USB on old Macbook
new Macbook w USB C
FTDI 3v3 serial cable as alternative to sparkfun serial board
Running an alternative uart_boot_host.py script in tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/bootloader_scripts/uart_boot_host.py, also no response
I can measure, with a scope, the handshake bytes '0x14', '0x55', '0x9d', '0xe9' '0x0', '0x0', '0x8', '0x0' being transmitted initially at 115200 on the TXO pin on the programming header - but the ambiq is not replying anything.
btw. The onboard demo is running, blue led flashing, an some "yes's" are being recognized.
Any inputs welcome.
Does anyone know the protocol for the corvette bootloader ?
Are there any CPU revision changes from the first batch of boards, or possibly any lock bits programmed accidentally from sparkfun ?
rgds from an eager TF lite user ;-)
I tried measuring the actual baudrate with a scope on rx/tx pins, and saw that the bit timing using default OSX serial driver is rather imprecise, app 10% off, causing faulty readings, and ultimately missing bytes, when the baudrate are high.
After updating to the ch340 serial driver, timing improved, and the bit timings were correct.
At 921600bps, a single byte 8N1 is supposed to be10.9uS
Driver install
https://github.com/adrianmihalko/ch340g-ch34g-ch34x-mac-os-x-driver
This is what worked for me: (source: github.com/sparkfun/SparkFun_Edge_BSP/issues/3, the SparkFunEdge tutorial and my teammates!). I am running this on a Linux machine (x86_64; Run $ uname -a) and my SparkfunEdge DEVICENAME=/dev/ttyUSB0
The tutorial does warn you about this problem at Step 4:
Note: Some users have reported issues with their operating system's
default drivers for programmer, so we recommend installing the
driver before you continue.
Click on the driver link and follow the instructions under "Other Linux distributions" as follows:
Install the correct version of the ch34 library.
$ git clone https://github.com/juliagoda/CH341SER.git
$ cd CH341SER/
$ make
$ sudo insmod ch34x.ko
$ sudo rmmod ch341
To verify that the correct driver is being used, run:
$ dmesg
..
[889247.585301] usb 1-7: ch341-uart converter now attached to ttyUSB0
[955698.718839] usbcore: registered new interface driver ch34x
[955698.718848] usbserial: USB Serial support registered for ch34x
[955759.196437] usbserial: USB Serial deregistering driver ch341-uart
[955759.196576] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[955759.196601] usbcore: deregistering interface driver ch341
[955759.196643] ch341 1-7:1.0: device disconnected
Now unplug the USB-C from the SparkfunEdge Board, and plug it back again
$ dmesg
....
[955876.176950] ch34x 1-7:1.0: ch34x converter detected
[955876.177320] usb 1-7: ch34x converter now attached to ttyUSB0
glad to hear that you're so excited about the board. I have a hunch that this will be an easy fix.
The Edge boards handed out at the conference have a bootloader set for 115200 baud, however the Edge boards that have come out in the second batch are upgraded to flash at 921600 baud, greatly reducing flashing time. Try changing the baud rate in your serial upload script.
You can also set up the Ambiq Software Development Kit to write your own applications for the Apollo3 microcontroller. Check out the tutorial here: Using the Edge Board with Ambiq SDK
Since I can't comment on your post (not enough reputation.... thanks SE) I'll be responding here.
If the baud rate accuracy is a problem I'm slightly unsure that that would be caused by the OS, but rather I'd think it is a problem with the USB-serial converter chip. I've been using the CH340G whereas on the USB-C version there is the CH340C IC. The difference between the two is that the "C" version includes an internal oscillator to provide the frequency reference. It is possible that that one is less accurate...? I'll try it out over here (but on windows) and let you know.
If this is a persisting problem would you mind making a post on the SparkFun forums? That way our tech support can get linked in (they are the people who could get you replacement hardware in case it is defective, also). Here's a forum for the Edge: SparkFun Edge Forums
If the problem is coming from the OS then the only fix that we can do with the Edge is to reduce the bootloader speed. We're working on a short tutorial about how to do that, but it would require having a programmer/debugger for Cortex-M processors. The Ambiq Apollo3 Evaluation Board has a built-in SEGGER J-Link which is what we used to program the boards.
On MacOS Mojave, Installing/Reinstalling CH340 works for me:
https://learn.sparkfun.com/tutorials/how-to-install-ch340-drivers#mac-osx
Before doing install, check that you actually see the sparkfun edge device with:
ls -l /dev/cu*
If driver is correctly installed, you should detect:
/dev/cu.wchusbserial1420
I got similar issue whereas I only had /dev/cu.usbserial-1420 and thought that was expected device to access, whereas it is /dev/cu.wchusbserial1420 which was only detected after installed ch340 driver.
Then flashing device works successfully for me.