The time mentioned above is standard for the release you are using - We are looking into that..
Just to note the ROM should be flashed to the 8KB OTP Flash - start address 0x00000000
0x00180000 is the start address for the 32KB System Flash
In general, we need to wait about one minute before we start debugging D2000 with flashing (using Intel uC Studio and openocd). For example, in comparison with LPC microcontrollers or STM (M0/M0+ cores) it takes 5-8s on my machine...
I will report in more details later.
Is there any update on this issue ? I'm trying to debug an application ported to quark_se which is about 160K binary size. Takes >10 minutes to load to flash (openocd 0.8.0-dev-gba72ade) making the development cycle extremely slow. Tried tweaking jtag clock speeds in the .cfg scripts but doesn't seem to make any difference, and loading direct through openocd is only slightly faster than gdb
What's the limiting factor on flashing speed - can't be the on-chip memory itself surely ?
Can you just confirm how you are flashing the application ? Are you using the command line or the ISSM IDE ?
If you are using the command line you need to ensure you use the ARC to flash. ISSM does this by default but you need to manually set it if you are using the command line.
For GDB - the correct commands are here - IoT - Developing in the Command Line | Intel® Software
For OpenOCD you need to set 'targets 1' before flashing the .bin file
For example , I just did a test here flashing a 170KB application to the x86 core (address 0x40030000) in about 40 seconds ...
> targets 1
> load_image c:\\temp\\test.bin 0x40030000
176632 bytes written at address 0x40030000
downloaded 176632 bytes in 42.635105s (4.046 KiB/s)
Hi Michelle, and thanks for your quick reply. I'm mainly using ISSM on linux, but I had unticked 'Use internal OpenOCD' in Debug Configurations, because it only worked with a separate instance of openocd when first tested. I confirmed that openocd flashing from command line was also slow, but adding 'targets 1' it runs at 5KB/s rather than 0.3, as in your example. Couldn't see how to change the behaviour in ISSM, however on testing again with 'internal OpenOCD' enabled it now works ok, and at the correct speed. Not sure what I've changed since first trying it, but seems I have a workable solution, so thanks for pointing me in the right direction