2012-01-18 08:19 AM
.
2012-01-18 09:36 PM
Not that I've noticed.
2012-01-19 07:55 AM
2012-01-19 09:02 AM
Wouldn't this depend on the size of the download, the programming strategy and the rapidity of the JTAG interface in question?
Most schemes upload an applet and blocks of data to SRAM, such an applet could kick the watchdog. Presumably when the core is halted, the DBG_IWDG_STOP or DBG_WWDG_STOP would also stall the watchdogs. One of the things that breaks the ST-LINK is DMA activity.2012-01-19 12:09 PM
are you saying that when Keil does a falsh download, they, in fact, first load a ''downloader'', then the code?One of the things that breaks the ST-LINK is DMA activity. is that ST-LINK specific or general (i.e. valid for Keil) thanx, Erik
2012-01-19 12:41 PM
are you saying that when Keil does a falsh download, they, in fact, first load a ''downloader'', then the code?
Correct, it is more efficient to do this, than bit bang the flash peripheral/memory via JTAG directly. Look in the \Keil\ARM\Flash directory for the .FLM/.FLX applet files. These are selected when you go into the Flash menu and pick the memory types and spaces. Some source is also provided. Segger has applets for there J-Flash tool, and the ability to load custom applets and run scripts to poke registers. ATMEL's SAM-BA tool permits applets for SDRAM, NAND and NOR memories.is that ST-LINK specific or general (i.e. valid for Keil) This is really a question of how effectively the JTAG pod wrestles control of the processor after the reset. The JLink and ULink seem to do this more effectively, presumably by actively poking various peripheral registers, where as the ST-LINK on the VL-Discovery is quite easy to brick.
2012-01-20 08:41 AM
Thanks, Clive
have been hunting some ''mysteries'' under the impression that reset was held during downloads. your info totally changes my route analyzing this issue. thanx, Erik