I am sorry, I forgot to send the message to openocd. It is below. > "(gdb) monitor version" will show the version and date. Or "version" if > you use telnet. > (gdb) monitor version Open On-Chip Debugger 0.6.0-dev-00497-ga6cf60c (2012-04-06-08:15)
> >> If you can't, better set " -work-area-size 0 " instead of " > >> -work-area-size$_PIC32MX_PROGSIZE ". It is slow, but a little faster I am just running programming with PROGSIZE = 0. It is slow - around 1 DWord per 2 seconds, so all 32kBytes will be programmed in 4.5 hours. I see plenty of write with data of 0xFFFFFFFF. Is it necessary ? I assumed that after FLASH is erased, default contents are 0xFFFFFFFF. I tried JLink and now I am trying FT2232. Speed is quite the same. Actually, I don't know, where is the problem. I used both JLink and FT2232 for programming of ARM Cortex M3 (STM32) on Windows without any problem. But communication with PIC32 is slow. Unusable, actually. I would like to help with debugging the problem and improve support of PIC32. Does anybody else use OpenOCD with PIC32 on Windows platform ? Or only me ? What are speeds on Linux (I can install some version of Kubuntu to compare) ? UPDATE: I switched off the debugging (-d 2 parameter) and run it again. PIC32 was programmed correctly. Programming of 6800Bytes took 5100 seconds! Can I do some profiling of OpenOCD ? There must be something wrong inside... I don't know if it is libusb driver or openocd itself... ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
