I am currently using Xilinx ZCU106 board, and I am curious about How does JTAG support flash memory programming. I can upload the boot images or hardware logic just by connecting JTAG USB cable to USB connector at the ZCU106 Board, and press the flash button on the host PC. By doing this it looks like the QSPI Flash holds the boot images or hardware logic image and the system initializes itself by using this image. It seems like a magic, and I want to know about the detail.
So far I understood is that I can access JTAG interface via USB cable (thanks to the FTDI chip?), and JTAG boundary-scans the devices connected to it.
However the problem is here, I couldn't find the link between JTAG and QSPI Flash (MT25QU512ABB8ESF-0SIT). I searched several references, including manual of QSPI Flash (MT25QU512ABB8ESF-0SIT, https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_512_abb_0.pdf) but there seems no port for JTAG (such as TDI, TDO, and TCK), but only SPI.
So the first assumption, I thought on the JTAG chain maybe there is a SPI controller to flash the memory. However I couldn't find any clue on the references that I've read so far that a SPI controller exists on the chain or even a SPI controller that controls the QSPI flash really exists. And the second assumption, I thought PS- ARM Cortex A53- TAP (?) does the magic. PS TAP receives JTAG signal and processes the JTAG command. To be precise, let's say about flash memory programming case, then there is like a JTAG command for write data on the flash memory via SPI.
Among these two, I wonder if there is the answer. One thing for the last, if the second one suppose to be the answer, then the processor (Cortex A53) should implement the functionalities by hardware logic to parse Flash write/erase command signal from JTAG interface and let the SPI controller that the system includes perform the write/erase job? Somewhere I read that the JTAG itself supports writing data on the Flash memory but everything I could find was just TDI, TCK, TDO, TMS, and TRST ports which does not fit in any port of QSPI Flash.
Probably I am confusing a lot of concepts very much, but I want to know about the exact mechanism behind the scene on JTAG flash memory programming.
Normally, it will do with the following sequence:
Send some software to target processor in RAM
Send data to target processor (in RAM)
Trigger execute command to store data into the flash memory.
Now the expected data are available in flash memory.
Related
I'm running out of memory with my STM32F107. Unfortunately is 256kb the maximum size of this MCU and there is no pin compatible alternative.
I found several Flash Modules and I know there are ways to boot from it, but I never done that before and I dont know if its possible with the STMF107.
Have someone tried that? Is SPI fast enough, I read something about QSPI, but the STM doesnt support that.
Here the Datasheet from the STM: https://www.st.com/resource/en/datasheet/cd00220364.pdf
Here the Datasheet from the favorite Flash: https://www.mouser.de/datasheet/2/198/IS25LP032-064-128-463542.pdf
The only way you would be able to do this with your microcontroller and that flash is to copy the code into ram and execute it from there. This is not a great solution.
The QSPI interface in some STM32 microcontrollers is different to regular SPI, it has 4 data lines, and is memory mapped, which allows it to be executable, the 'regular' SPI interface has no means for execution of code.
the atmega microcontrollers have the internal programmable memory.So the usb flash device write data to internal memory of atmega through spi or it store the program and works as slave?i also want to know can the atmega get program,file in the MicroSD and run without internal memory or it need to run a program in internal disk then including the program in MicroSD?i don't know how the process work in atmega microcontroller.
There are several ways to program the AVR:
Using an external programmer. The Chip is in reset state during this. Then the programmer uses special a special protocol to directly write to the flash inside the controller. This is how your USB programming device probably writes code to the AVR. There are several protocols for this, but the most common one uses the same pins that are used by SPI. You should not confuse them just because of that ;-).
The controller writes the program itself. The chip is actively executing a program. That program on the chip fetches the instructions from e.g. a sd card and using the SPM instruction to copy it to local flash.
The AVR can only fetch instructions from it's own flash memory - you cannot execute directly from RAM or from any other external source.
The best answer for this question you can find at the end or middle of datasheet for AVR device (eg ATMEGA 328P-PU). If you are using some flashing device connected with computer, there is some initialization sequence after start and then there are send some 4 Bytes commands that tels microcontrolers, where to store values to flash and/or eeprom, fuse bits, or cares about erasing etc. There is also posible to read ID of chip.
Atmega microcontroler can be also programmed in paralel mode, where are some bits used for sending commands that tels, what to do with data on data bit.
If you ask about downloading program from SD card or any other device, there is possible to write to the flash through SPM, as there was told above. Some devices do not have part of flash for downloader - if I remember ATMEGA 48, and devices, that have configurable part of memory usable also for downloader, that can handle this, eg. ATMEGA 88, 168, 328. So if you want to download program from SPI, USART, TWI, etc, you need to configure fuse bits and create downloader that will do it for you. I am not sure, how ATMEGA 48 do this, but there si probably possible to write whole flash by SPM instruction.
However the best answer you can find in the datasheet. On pages folowing 255 you can find further information. http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf
I have a custom ps2 keyboard(8x8 matrix) interfaced with AT89C51ED2 microcontroller, now I need to change it to USB interface. I have been studying about the basics of USB HID class communication(USB HID class specs, USB complete, Beyond logic) and have come to know little bit about the theory behind it.
But I am not able to understand the firmware part, I read a demo keypad application by Microchip which had given a sample source code, but I am not able to understand in the code how data(key pressed) is sent to the IN endpoint and how the host reads that through polling. I know that endpoint is a buffer from which data is sent to host, but Is it one of the registers of the micro-controller and how do I use it in my code?.
And I have been searching the suitable micro-controller with USB support, but no supported demo's are available, any suggestions will be helpful
The AT89C51ED2 datasheet does not mention hardware support for USB, so the answer is no: an endpoint does not correspond to a hardware register. Instead, an endpoint would refer to some software buffers in the RAM of the chip, and some data to keep track of the endpoint's state. Every bit of every USB packet must be handled by the firmware of the device, and endpoints are an abstraction that live entirely in the firmware of your device.
Note: I am assuming that the keyboard doesn't have some kind of USB interface chip, and that the data lines of the USB cable connect more-or-less directly to the microcontroller.
If you can't find the source code for the keyboard, you might look into using an open-source AVR software USB implementation. Here are some useful links:
https://www.obdev.at/products/vusb/
http://www.fischl.de/usbasp/
Please note that you are undertaking an advanced project, and if you are not familiar with AVRs, USB, microcontrollers, reverse engineering, and embedded development/debugging, it might be useful to start with something simpler first.
I am working with a simple PIC18F2550 and I'm wondering about how to get a bootloader working on it. It's a very simple device with a USB port and CDC firmware. When I download Tiny Bootloader onto the pic, my PC doesn't recognize the device. Do I NEED to have a USB controller in my circuit in order for it to work? Such as the MAX232?
Would the same apply to the PIC32MX795F512L?
Thanks!
It is clear from the Tiny PIC boot loader documentation that it expects a UART connection rather than USB (that is what the MAX232 is for - it is an RS232 line driver).
You could simply do that and use an external serial to USB converter thus saving the code space required by the USB-CDC stack. Otherwise you will have to modify the boot loader code to use the CDC driver rather than the UART.
You will have to link the USB code with the boot loader, which will no doubt significantly increase its size. You may need therefore also to move the application start address to accommodate the boot loader. Furthermore, if the application needs USB comms, you may need a separate copy of the code in the application unless you provide a method of accessing the bootloader code from the application; which is possible, but not necessarily straightforward.
All that said, note the part at the end of the end of the page about extending the bootloader; On the face of it it seems unsuited to extension. Without looking at the code and its memory map, it is not clear why it has this constraint.
The PIC18F2550 has a USB interface built into it. It is called the "USB SIE" and there is a large section in the datasheet that documents it. If you make the right electrical connections, you should be able to connect your PIC18F2550 directly to a USB port without any active electronics between them. There is no reason you would need extra USB hardware just because you want to run a bootloader.
If you want to troubleshoot your problems with the bootloader, you should probably post another question with more details. It could be a problem with the PIC's configuration bits or something like that. I recommend trying to modify the bootloader to get it to blink an LED as a basic first step just so you can verify that you were able to get its code to run at all.
This question is a bit vague, and I apologzie for that, but a fairly vague answer will do :)
How do people typically access memory adresses of external devices (say, connected to a PC through USB, or even just say, a multipurpose microcontroller)? I'm wondering how software is able to find address to write to registers or EEPROM space.
For example if I want to write a value to register 0x1234, does software just send this information (the register and the value to be written) to some sort of driver that "talks" to the device and takes care of the value change through hardware?
Is implementation of this functionality mostly a hardware endeavor?
Thanks!
Let's use as an example a fairly common USB peripheral controller that is based on an 8-bit 8051 microcontroller core. One side of it attaches to the USB host controller on a desktop computer. The other end goes to a USB device controller that presents itself as a FIFO endpoint to the host.
Some 8051 firmware will be required to initialize the device side. A class driver will be required on the host side. Once those are in place, the application developer will have a device name on the host side which may be opened for read/write. Sometimes a vendor will provide a library to perform device specific tasks and isolate the user from the raw device. Often a Windows DLL is available to hide the low level I/O and present device operations as function calls.
Additional 8051 firmware monitors the FIFO from device end and interprets messages sent from the host application or DLL then takes actions. These actions may be low level such as read/write from a memory location or register. They may be high level such as setting the PWM value of a programmable counter array.
So your hypothetical description of a write to register 0x1234 is not far from how it is often implemented.