Hi,
I have two questions about bootloader in TE0300-01IBMLP. I want to boot from bram, copy code to ram, and then jump to execute that code.
1) If I use the "copyandbuild_boot.bat" tool, it generates a firmware.fwu file. Can I upload this FWU to the module using the "USBFirmwareUpgradeTool.exe" or I have to do it with jtag?
2) The "copyandbuild_boot.bat" tool use a "download.bit" file. Is it a only implementation bitstream, a bitstream with the bootloader or a bitstream with a bootloop?
Thank you very much, and sorry for my english.
Quote from: acorde on March 14, 2011, 08:22:42 PM
1) If I use the "copyandbuild_boot.bat" tool, it generates a firmware.fwu file. Can I upload this FWU to the module using the "USBFirmwareUpgradeTool.exe" or I have to do it with jtag?
You can upload FWU (FirmWare Upgrade) files just with FUT (Firmware Upgrade Tool). Impact/JTAG do not know about FWU files.
THank you very much Horsa. I know that. But "copyandbuild_boot.bat" tool generates a fwu file and it tries to program a combined mcs file with jtag. I would like to know if the fwu file generated by copyandbuild_boot.bat can be programmed via usb without problems.
Thank you Horsa. As far as I known if the code will be execute from bram (a bootloop or bootloader, for example), the .bit can contain the code too. Is that right?
Quote from: acorde on March 15, 2011, 10:22:15 AM
But "copyandbuild_boot.bat" tool generates a fwu file and it tries to program a combined mcs file with jtag.
Yes, you are right:
impact -batch impact\burnspiprom_jtag.cmdQuote from: acorde on March 15, 2011, 10:22:15 AM
I would like to know if the fwu file generated by copyandbuild_boot.bat can be programmed via usb without problems.
Yes, you can:
http://www.youtube.com/TrenzElectronic
http://www.youtube.com/watch?v=7K-roP8nGKg
Hi,
It seems that you need some clarification.
The copyandbuild_boot.bat script programes the SPI FPASH via JTAG (if connected) and generates the FWU file which can be used to program the FLASH via FUT. This script appends .elf to the .bit at specified offset.
But first you need to generate the executable (.elf) and bitstream with the bootloader (combined in download.bit). Important: the bootloader project MUST be marked to initalize BRAM.
After bootup the bootloader reads the header, copies the executable to DDR memory, verifies the executable (checksum) and boots from DDR.
Best regards,
Ales
Thank you Ales. That's what I thought. I was including a bitstream without bootloader.
I have another question. There is a comment in the main.c of bootloader code: (line 62)
" // First write in dynamic RAM fails for unknown reasons...
// This is an hack which works, but still doesn't explain
// the cause... "
I cannot debug my application with SDK. Everything seems to be ok, SDK starts debugging but debug didn't stop on main.c. It opens a wrong execute address. Can "Ram bug" be the problem? How can I debug an application executing from RAM?
Quote from: acorde on March 16, 2011, 01:36:01 PM
I cannot debug my application with SDK. Everything seems to be ok, SDK starts debugging but debug didn't stop on main.c. It opens a wrong execute address. Can "Ram bug" be the problem? How can I debug an application executing from RAM?
What build configuration are you using?
http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/SDK_doc/concepts/sdk_c_build.htm
For debugging, I recommend
Debug, of course.
Hi,
This debugger is sometimes very unpredictable. The build settings optimization should be set to "None" for a start. The project has usually optimization se to "Size optimzed" which is usually a problem for a debugger.
I usually rely only on UART for debugging.
Best regards,
Ales
Thank you very much Ales, your replies are usefull.
Maybe I didn't explain it well. I want to know how to debug a code executing it from ram. If I configure the same code in order to run from BRAM, everything works fine.