**** BEGIN LOGGING AT Thu May 03 02:59:56 2007
May 03 09:13:56 <xela> Hey drath
May 03 09:22:44 <drath> hey xela
May 03 09:23:14 <xela> The workaround with disabling watchdogs really works like a charm now
May 03 09:23:33 <xela> Next on my agenda would be to speed up things a little...
May 03 09:23:46 <xela> right now i need 27 seconds for 232kb
May 03 09:24:06 <xela> i remember there was something that improved that (besides jtag speed?)
May 03 09:24:42 <drath> "arm7_9 fast_memory_access enable|disable" and "arm7_9 dcc_downloads enable|disable"
May 03 09:24:53 <drath> both are only safe when your core is running from the PLL
May 03 09:25:02 <drath> otherwise the JTAG could outrun the core
May 03 09:25:38 <xela> hm
May 03 09:25:46 <xela> not bad... now its 13seconds
May 03 09:26:06 <xela> i could disable this for the bootloader and enable for the app
May 03 09:26:11 <xela> would be sufficient...
May 03 09:26:41 <drath> that's probably as good as it gets, as the starting and stopping is probably taking most of the time
May 03 09:27:03 <xela> i ts ok for me
May 03 09:27:56 <xela> i wanna work on something that downloads and executes code snippets
May 03 09:27:59 <xela> (like pll)
May 03 09:28:17 <xela> just on top of openocd
May 03 09:28:25 <xela> like using python scripting via telnet
May 03 09:35:06 <drath> setting up a PLL or a SDRAM controller is probably easiest done using a simple script that executes m[dw][bhw] commands
May 03 09:36:23 <drath> there's usually no need for conditional execution, and simple linear instructions can be handled by the OpenOCD's "script" command
May 03 09:36:46 <xela> yep but for productions its good to parse for "error" in the output
May 03 09:37:32 <drath> ah, yeah, if you're going to use this in production a more complex handling is certainly necessary
May 03 09:41:56 <xela> you talked about working on reset_halt for STR750
May 03 09:42:15 <xela> I imagine this being a bit hard without actual hardware
May 03 09:52:56 <drath> heh, yeah, it certainly is - but I'm not even sure it's possible
May 03 09:53:25 <drath> on some cores like the LPC2000 it definitely isn't possible, for code security reasons
May 03 09:56:53 <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
May 03 09:58:46 <xela> so probably a STR750 board would help... at least for this task?
May 03 10:09:40 <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
May 03 10:09:52 <drath> and the whole method wouldn't work for a STR75x
May 03 10:12:58 <drath> looks like debug out of reset isn't possible at all on the STR75x:
May 03 10:13:33 <drath> 				etmv1_be_packet();
May 03 10:13:38 <drath> d'oh...
May 03 10:14:25 <drath> hmm, can't paste from the ref manual
May 03 10:14:49 <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
May 03 10:15:24 <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
May 03 10:16:05 <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
May 03 10:16:12 <drath> s/without/with/
May 03 10:16:13 <purl> drath meant: so I guess no, this is a hardware restriction, and even with a STR750 board I wouldn't be able to add reset halt support for those chips
May 03 10:17:31 <xela> ok
May 03 10:17:38 <xela> (got to run, talk to you soon)
May 03 10:17:46 <xela> so anything else you could use/need?
May 03 10:18:19 <drath> heh, thx, but i'm fine atm
May 03 10:20:11 <xela> ok, see you
May 03 10:23:02 <drath> bye
May 03 16:01:58 <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?
May 03 16:42:35 <drath> mthomas__: depends on the flash
May 03 16:43:21 <drath> mthomas__: intel C3 for example requires an unlock iirc
May 03 16:43:38 <drath> mthomas__: which flash are you working with?
May 03 17:06:13 <mthomas__> the one on the str710 eval-board just a momement, searching for the exact type
May 03 17:08:16 <mthomas__> M28W320, but i can not tell the following id-numbers, it think its a FSB, but not sure
May 03 17:08:52 <mthomas__> works well will openocd, just wanted to make sure if i "wear" out some limited protection switches
**** ENDING LOGGING AT Fri May 04 02:59:56 2007