Actions
Forum Thread Details
  • State Not Answered
  • Replies 3 replies
  • Subscribers 176 subscribers
  • Views 131 views
  • Users 0 members are here
Related

uZed program download speed

edoreshef

Hi everyone,

I'm using a FreeRTOS over uzed and everything works great. The only issue I have is long development cycle.

Large chunk of the time it takes to modify-build-program-download-run is the firmware download part.

Looking at the XSDB Console I get this:

xsdb% Info: tcfchan#1 closed
xsdb% Info: ARM Cortex-A9 MPCore #0 (target 2) Stopped at 0xffffff20 (Hardware Breakpoint)
xsdb% Info: ARM Cortex-A9 MPCore #1 (target 3) Stopped at 0xffffff34 (Suspended)
100%    3MB   3.0MB/s  00:01   <= FPGA download speed
Downloading Program -- uzed_app.elf
section, .text: 0x00100000 - 0x003479d3
section, .init: 0x003479d4 - 0x003479eb
section, .fini: 0x003479ec - 0x00347a03
section, .rodata: 0x00347a10 - 0x003855b3
    ... about 1500 section lines 
section, .fini_array: 0x003adc28 - 0x003adc5b
section, .bss: 0x00400000 - 0x0060812f
section, .heap: 0x00608130 - 0x1060812f
section, .stack: 0x10608130 - 0x1080992f
100%    2MB   0.0MB/s  01:43    <= Program download speed
Setting PC to Program Start Address 0x00100000
Successfully downloaded uzed_app.elf

This paste shows the FPGA programming speed is great but for some reason firmware programming speed is about 100 slower.

Questions:

  1.   Is it normal?
  2.   Why is there a differance between the FPGA download speed and the firmware download speed?
  3.   Is there anything I can do to improve this?

Best Regards,
Edo

  • 0

    Hello Edo,

    1 & 2)      I tend to believe this is normal. The FPGA programming is not limited to where the data is going, it is being written directly into the SRAM of the FPGA which is really fast(many multiples of hundreds of MB/s) That is, it is not the limiter in that write. As for the write for the firmware, you do not indicate where you are writing to, but if it is QSPI and you have it set to a slow clock and low bit width, it could be really slow. Couple that with the fact that the RTOS is probably (not always) multiples larger then the FPGA file, you could have yourself a situation where multiple things stack up to make it slow.

    3)       As far as trying to improve this, I would suggest SD card loading. Then it is just copying a file to a card an moving it between your PC and development board.

    --Josh

  • 0 in reply to jafoste4

    Hello Josh,

    Thank you for helping.

    About 1 & 2, I'm basically I loading the program directly into DRAM every time I start a debug session (this is why this is this so painful). I'm guessing that DRAM writes aren't the bottleneck. Any idea what else could it be?

    As for #3, writing to SD card every time I wish to debug the application is a serious penalty on the development cycle - so this is not really of an option.

    Thanks,
    Edo

  • 0

    Hello Edo,

    Sorry for taking so long to reply. 

    1&2: That is the extent of the knowledge I know of on that subject.

    3: As for having to SD card over every time. When I typically do development I maybe change the Firmware 2-3 times , so SD carding that data over to the development board is no issue for me. Then I use the JTAG interface to quickly program my developmnet board over and over again as I make changes. But I can see it being an issue if you are changing the firmware ever time.

    If you want to try and reach a broader audience, you could try posting this question over at the xilinx forum.

    https://forums.xilinx.com/

    --Josh