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.
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.
We have an embedded board that has an iMX8M-Plus Processor and Linux v5.4.161. This board has one PCIe bus and that one is connected to an FPGA. When we power up the board, the FPGA is not yet configured, so it acts as if it was not on the PCIe bus.
Once the Linux is fully booted, we configure the FPGA and only after that it starts acting as a PCIe endpoint (device).
At this point, when I run lspci -> it returns nothing.
When I first execute echo "1" > /sys/bus/pci/rescan as suggested here and here and then lspci, I still get nothing.
But if I reboot the linux without reseting the FPGA, it starts being visible in the lspci list. Rebooting the linux is not an option for us. Somehow I need to tell the linux that whatever it's doing at the boot time, please do it again at runtime. But I couldn't find a solution for this so far.
According to the Texas Instrument support forum, they said if the PCIe link is not trained at the boot time, rescan command never works.
At the boot time, while linux loads a pci driver, it tries to establish a PCIe link, I can see that with an oscilloscope, PERST pin is asserted and PCIE_CLK generated for a while and then stops if it can not detect any device. But the rescan command never does that.
Also in the system there is no pcie device to executeecho 1 > $pcidevice/remove in order to make rescan functional. Or there is no device or bus to set power off and on back like echo 0 > /sys/bus/pci/slots/.../power
I also learned that there was a method in old linux times (v2.6) called adding a Fake PCIe Device which physically doesn't exist to solve this problem. For that I took the fakephp.c driver from an old linux repo and ported it to ours. After solving a couple of deprecated function problems, it is compiled for Linux Kernel v5.4. modprobe fakephp worked and driver loaded but somehow I didn't get this fake device in my device list. Here it is mentioned that the fakephp driver was removed from mainstream linux since PCI core has similar functionality, but he never mentioned how.
Short of the story is that, I am stuck here, I need my FPGA to be visible in the lspci list without restarting the linux.
I recommend configuring the FPGA in u-boot to get away from these kinds of problems. Connect up SPI pins to FPGA's config pins & run it in Slave configuration mode.
I am working with Sasebo GII board that has two FPGAs on it:
Xilinx Spartan and Xilinx Virtex5 (and the board has several separate JTAG interfaces for configuration of fpgas).
I am useing ISE 14.4 under Linux and I have some troubles to configure the Virtex 5 FPGA.
(no problems with Spartan).
I am using "Impact" to send the configuration files to FPGAs.
At the beginning Impact scans the board and finds Spartan FPGA without problems
and I can configure it, but when I plug the cable to the other interface and press scan on Impact it says:
"There are many unknown devices being detected. Press Yes to continue or press No to stop."
If I press the NO option, well, obviously nothing happens :-)
And if I click on YES it fails, I can manually add Virtex5 FPGA, but than it fails to upload the config file to it (and even fails when I try to detect the device ID).
I already tried all JTAG interfaces on the board, nothing.
Same operations work on the same board with SPARTAN FPGA, so I'm stuck. Any ideas ?
Well, I am not familiar with that particular board, but there are many things you can look into when it comes to your JTAG problem.
Check the voltage of your VCC, make sure it has a good value for the board
Make sure your ground connection is well connected and you don't have much impedance
between the connector's GND and the boards GND
Try other JTAG connectors and see if you see any difference in the detection of the
devices.
Try to run the IMPACT in debug mode. Capture the data and see if the patterns look OK
Also something that may not be JTAG related, is to make sure your V5 device has all the powers it needs, if there are any power problems, it may cause the JTAG interface to behave like you explained here.
Also, look on the board and see if there are any switches or jumpers to chose different way of configuring the V5 device. This can be a big issues with multi-FPGA board, maybe the V5 is configured to be programmed from a controller or other devices on the board and the JTAG chain is not set up for programming.
These are just different thoughts, they may help you toward the right direction.
Found this on their site:
User guide for the board
To reprogram the flash ROM (ST45DB16D, U11) for the control FPGA (Spartan-3A), attach the configuration
cable to CN7. For configuration, use the provided mcs file sasebo_gii_ctrl.mcs.
Reprogram the flash ROM (ST45DB16D, U4) for the cryptographic FPGA (Virtex-5 LX30) with the provided
mcs file sasebo_aes_comp_lx30.mcs as well. Connect the configuration cable to CN4.
To configure the FPGA immediately after reprog
ramming of the flash ROM, cycle the power.
Blockquote
This means you can't program the FPGA directly, you need to convert your bit file into MCS file and then load it into the FLASH memory on the board.
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 ;)
I have a Arduino app that needs to talk to my PC across the USB (Serial) connection. I have this bit of code that I lifted from the Arduino Playground at
http://arduino.cc/playground/Interfacing/CPPWindows#VisualStudio2008
this->serialPort1->PortName = "COM5"; // Replace with your COM port!
this->serialPort1->Open();
this->serialPort1->Write( "7" ); // In the future, you'll expand on this
// to write your custom data to the board
this->serialPort1->Close();
My question is how does one determine what COM port the Arduino USB cable is attached to?
There are several ways you can approach this.
The most obvious is that you simply make your application configurable and tell it which serial port to use. The port name should never change, unless you have other processes on your machine allocating virtual COM ports such as Bluetooth drivers.
A second option is that you can do what the Arduino app does and scan the serial ports on the system looking for the hardware. Since you are using the CLR, System.IO.Ports.SerialPort.GetPortNames() will give you a list of all the serial ports on the system. (You can also get this from the registry.) Then you can enumerate through them and check the status of the pins to see which serial ports have devices attached. You should probably include in your sketch a way to query the Arduino so that you can send it a command and have it give a fixed response. This would allow you to discern your application from other serial devices such as modems.
There is a third option which would involve figuring out where the FTDI driver stores its configuration information in the system/registry and going from there. This is a bit more involved, so I can't give any information on if this approach is even viable.