| 02:42.18 | *** join/#openjtag xela_ (n=Alex@p549C9F4C.dip0.t-ipconnect.de) |
| 03:25.24 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 03:58.34 | *** join/#openjtag jamie (n=jamie@pdpc/supporter/active/jamie) |
| 04:35.57 | *** join/#openjtag xela__ (n=Alex@p549C9F4C.dip0.t-ipconnect.de) |
| 07:26.34 | *** join/#openjtag dwer1 (n=dwery@81-208-74-188.ip.fastwebnet.it) |
| 07:29.50 | *** join/#openjtag dwery (n=dwery@nslu2-linux/dwery) |
| 07:54.24 | *** join/#openjtag rd_ (n=rd@vnsecurity.net) |
| 08:01.21 | *** join/#openjtag aproemel (n=aproemel@p508ABEDB.dip0.t-ipconnect.de) |
| 09:14.01 | xela | Hey drath |
| 09:22.49 | drath | hey xela |
| 09:23.19 | xela | The workaround with disabling watchdogs really works like a charm now |
| 09:23.38 | xela | Next on my agenda would be to speed up things a little... |
| 09:23.51 | xela | right now i need 27 seconds for 232kb |
| 09:24.11 | xela | i remember there was something that improved that (besides jtag speed?) |
| 09:24.47 | drath | "arm7_9 fast_memory_access enable|disable" and "arm7_9 dcc_downloads enable|disable" |
| 09:24.58 | drath | both are only safe when your core is running from the PLL |
| 09:25.07 | drath | otherwise the JTAG could outrun the core |
| 09:25.43 | xela | hm |
| 09:25.51 | xela | not bad... now its 13seconds |
| 09:26.11 | xela | i could disable this for the bootloader and enable for the app |
| 09:26.16 | xela | would be sufficient... |
| 09:26.46 | drath | that's probably as good as it gets, as the starting and stopping is probably taking most of the time |
| 09:27.08 | xela | i ts ok for me |
| 09:28.01 | xela | i wanna work on something that downloads and executes code snippets |
| 09:28.04 | xela | (like pll) |
| 09:28.22 | xela | just on top of openocd |
| 09:28.30 | xela | like using python scripting via telnet |
| 09:35.11 | drath | setting up a PLL or a SDRAM controller is probably easiest done using a simple script that executes m[dw][bhw] commands |
| 09:36.28 | drath | there's usually no need for conditional execution, and simple linear instructions can be handled by the OpenOCD's "script" command |
| 09:36.51 | xela | yep but for productions its good to parse for "error" in the output |
| 09:37.37 | drath | ah, yeah, if you're going to use this in production a more complex handling is certainly necessary |
| 09:42.02 | xela | you talked about working on reset_halt for STR750 |
| 09:42.20 | xela | I imagine this being a bit hard without actual hardware |
| 09:53.01 | drath | heh, yeah, it certainly is - but I'm not even sure it's possible |
| 09:53.31 | drath | on some cores like the LPC2000 it definitely isn't possible, for code security reasons |
| 09:56.58 | drath | i'll run some checks on the str711 i've got here - i thought it was possible there, but i'm not so sure anymore |
| 09:58.52 | xela | so probably a STR750 board would help... at least for this task? |
| 10:09.46 | drath | hmm... ok, in theory it would possible to halt a STR7[13]x before it executes code, but the timinig is criticial, and i'm not sure if a FT2232 based solution could replicate the exact timing necessary |
| 10:09.57 | drath | and the whole method wouldn't work for a STR75x |
| 10:13.03 | drath | looks like debug out of reset isn't possible at all on the STR75x: |
| 10:13.38 | drath | etmv1_be_packet(); |
| 10:13.43 | drath | d'oh... |
| 10:14.30 | drath | hmm, can't paste from the ref manual |
| 10:14.54 | drath | anyway, it says that halting the core takes time, and that it's possible for code on the board to be able to turn JTAG off before a debugger has a chance to attach |
| 10:15.29 | drath | which implies that it isn't possible to halt before code gets executed, which makes sense, if they're using the same startup procedure as on the older str7x combined with a -S core |
| 10:16.10 | drath | so I guess no, this is a hardware restriction, and even without a STR750 board I wouldn't be able to add reset halt support for those chips |
| 10:16.17 | drath | s/without/with/ |
| 10:17.36 | xela | ok |
| 10:17.43 | xela | (got to run, talk to you soon) |
| 10:17.51 | xela | so anything else you could use/need? |
| 10:18.24 | drath | heh, thx, but i'm fine atm |
| 10:20.16 | xela | ok, see you |
| 10:23.07 | drath | bye |
| 10:46.55 | *** join/#openjtag rd__ (n=rd@toi.yeu.phu.nu) |
| 10:47.38 | *** part/#openjtag rd__ (n=rd@toi.yeu.phu.nu) |
| 11:03.49 | *** join/#openjtag rd_ (n=rd@toi.yeu.phu.nu) |
| 11:44.41 | *** join/#openjtag p2-mate (n=p2@cable-87-244-173-194.upc.chello.be) |
| 12:14.10 | *** join/#openjtag nm (n=hongtd@222.252.102.104) |
| 12:48.42 | *** join/#openjtag rd_ (n=rd@toi.yeu.phu.nu) |
| 13:24.23 | *** join/#openjtag prpplague (n=dave@mail.americanmicrosystems.com) |
| 14:08.24 | *** join/#openjtag prpplague^3 (n=dave@mail.americanmicrosystems.com) |
| 14:57.45 | *** join/#openjtag rd_ (n=rd@toi.yeu.phu.nu) |
| 15:24.20 | *** join/#openjtag Chocobo (n=swinchen@strongbad.eece.maine.edu) |
| 15:59.51 | *** join/#openjtag mthomas__ (n=ask@fuchur.arubi.uni-kl.de) |
| 16:02.04 | mthomas__ | hello, drath: is a "flash protect off" always needed before a cfi flash page can be programmed or is it depending on the type of memory used? |
| 16:42.40 | drath | mthomas__: depends on the flash |
| 16:43.26 | drath | mthomas__: intel C3 for example requires an unlock iirc |
| 16:43.43 | drath | mthomas__: which flash are you working with? |
| 17:06.19 | mthomas__ | the one on the str710 eval-board just a momement, searching for the exact type |
| 17:08.22 | mthomas__ | M28W320, but i can not tell the following id-numbers, it think its a FSB, but not sure |
| 17:08.57 | mthomas__ | works well will openocd, just wanted to make sure if i "wear" out some limited protection switches |
| 17:48.48 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 17:54.25 | *** join/#openjtag ka6sox-laptop (n=tom@nslu2-linux/ka6sox) |
| 23:04.03 | *** join/#openjtag drath_ (i=vmaster@p5B07DB13.dip.t-dialin.net) |
| 23:44.25 | *** join/#openjtag p2-mate (n=p2@cable-87-244-173-194.upc.chello.be) |