| 09:26.51 | *** join/#openjtag bullet (n=bullet@150-127.0-85.cust.bluewin.ch) |
| 09:48.18 | *** join/#openjtag rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 09:54.41 | *** join/#openjtag rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 12:32.09 | *** join/#openjtag vmaster_ (n=vmaster@p549B6E27.dip.t-dialin.net) |
| 12:57.55 | *** join/#openjtag prpplague (n=billybob@72.22.136.187) |
| 14:04.07 | prpplague | vmaster_: morning |
| 14:08.11 | vmaster_ | hey prpplague |
| 14:13.55 | prpplague | vmaster: just getting started on debugging this timeout issue |
| 14:14.37 | vmaster | do you have usbmon compiled in your kernel? i found it helpful in debugging this issue |
| 14:14.59 | prpplague | not on this specific desktop |
| 14:15.09 | prpplague | i'll have to go to another one |
| 14:15.27 | prpplague | vmaster: so you;ve run into this before? |
| 14:15.51 | vmaster | several months ago there was a bug in the ftdi driver |
| 14:16.12 | vmaster | there's a define in ft2232.c that makes the OpenOCD dump every byte sent to the chip |
| 14:16.25 | prpplague | yea got that turned on |
| 14:16.38 | vmaster | _DEBUG_USB_COMMS_ |
| 14:16.46 | prpplague | vmaster: yea |
| 14:16.59 | vmaster | when does the timeout occur? on the first packets transmitted? |
| 14:18.28 | prpplague | vmaster: full log - http://pastebin.ca/170277 |
| 14:21.34 | prpplague | vmaster: i'm not getting one of the leds turned on which leds me to believe the writes aren't occuring |
| 14:26.18 | vmaster | maybe the wrong device gets opened? |
| 14:26.44 | vmaster | try adding " A" after the ft2232_device_desc |
| 14:30.13 | vmaster | ah, you might have to unbind the ftdi_sio driver |
| 14:31.05 | prpplague | vmaster: it was the description |
| 14:31.17 | prpplague | vmaster: i already got rid of ftdio_sio earlier |
| 14:32.14 | vmaster | you can request a pid block from ftdi and run your devices under their pid, if you want |
| 14:32.33 | vmaster | that way it's easier to identify the jtag dongle, and you wont interfere with the ftdi_sio |
| 14:32.51 | prpplague | vmaster: naw this is ok, i just need to get familiar with the operations and write some notes |
| 14:32.57 | prpplague | vmaster: new error - Error: jtag.c:1148 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 3f |
| 14:33.46 | vmaster | is the dongle connected to your target board and is the board powered? |
| 14:33.57 | prpplague | yep |
| 14:35.43 | prpplague | http://pastebin.ca/170302 |
| 14:35.46 | prpplague | current config |
| 14:36.48 | prpplague | wonder if the enables for the buffer aren't getting set |
| 14:39.54 | prpplague | yea looks like the enables for the buffers are high |
| 14:43.20 | vmaster | ah, sorry |
| 14:43.50 | prpplague | vmaster: i must be dense, but i can't seem to find a good datasheet that explains the usage for these values |
| 14:44.17 | prpplague | vmaster: which ft2232 datasheet do you use to determine these values? |
| 14:44.30 | vmaster | the mpsse application note |
| 14:44.56 | prpplague | ahh |
| 14:45.09 | vmaster | in m5960_init, low_output is 0xd8, but should be 0x18 (nOE1,2 low) |
| 14:46.13 | prpplague | yea, looks good now |
| 14:50.11 | prpplague | vmaster: what enables the banks and info commands? |
| 14:58.11 | vmaster | you mean flash? |
| 14:58.24 | vmaster | #flash bank <driver> <base> <size> <chip_width> <bus_width> [driver_options ...] |
| 15:01.08 | prpplague | yea, i have that in my config, but when i try using the "info" command it tells give me an error "command info not found" |
| 15:03.08 | vmaster | it's "flash info" |
| 15:03.13 | vmaster | and "flash banks" |
| 15:03.46 | prpplague | ahh |
| 15:04.02 | prpplague | hehe did not get that from the help command |
| 15:04.49 | vmaster | heh, yeah, the user interface could use some improvements, but other things are more fun to work on ;) |
| 15:05.19 | prpplague | agreed |
| 15:05.29 | prpplague | still getting some odd results |
| 15:05.37 | vmaster | like? |
| 15:07.21 | vmaster | the cfi driver only understands Intel's commandset so far |
| 15:25.19 | *** join/#openjtag prpplague (n=billybob@69.73.222.167) |
| 15:25.57 | prpplague | vmaster: ok so i'm making progess |
| 15:26.11 | prpplague | vmaster: you mentioned a memory speed option yesterday |
| 15:38.31 | vmaster | "arm7_9 fast_memory_writes [enable|disable] tells the OpenOCD to write to memory without waiting for the core - that's safe as long as your core isn't running from a very low frequency |
| 15:39.39 | vmaster | "arm7_9 dcc_downloads enable" tells the OpenOCD to use the debug communications channel to write to the target - this gives the best speed, but requires on-target memory as a working area (working_area target# address size) |
| 15:39.45 | prpplague | vmaster: yea should be safe for 200mhz |
| 15:39.50 | vmaster | heh, definitely |
| 15:39.59 | prpplague | vmaster: but i need to make sure my processor clock is enabled correct? |
| 15:40.29 | vmaster | well, anything above a few mhz should be enough |
| 15:40.34 | vmaster | on the ep93xx, the crystal oscillator is enough |
| 15:40.40 | prpplague | vmaster: i'm used to doing bit bang flash programing using the boundry scan |
| 15:40.59 | vmaster | heh, well, this is going to be somewhat faster |
| 15:41.04 | prpplague | vmaster: hehe |
| 15:41.17 | vmaster | gotta take the dogs out... i'll be back in a few minutes |
| 15:41.21 | prpplague | vmaster: ok |
| 15:56.57 | prpplague | ho ho hum |
| 15:57.00 | prpplague | lots to learn |
| 15:57.35 | vmaster | most/some commands are documented in the wiki at http://openfacts.berlios.de/index-en.phtml?title=Open_On-Chip_Debugger |
| 15:58.11 | prpplague | vmaster: its more of the procedure for flashing that i'm gonna need to work out |
| 15:58.24 | prpplague | vmaster: i'm still getting lots of problems with the cfi driver |
| 15:59.23 | vmaster | what type of flash is it? |
| 16:01.13 | prpplague | vmaster: intel TE28F128J3c |
| 16:02.35 | prpplague | vmaster: the system should be configured on reset to work properly, it should be running at 12mhz, the bus width is set correctly |
| 16:02.50 | prpplague | vmaster: so i'm not sure why i'm getting inconsistant results |
| 16:03.17 | vmaster | what does the bank look like - one chip of 16 bit? |
| 16:03.23 | prpplague | yea |
| 16:03.44 | prpplague | vmaster: the probe identifies it properly |
| 16:04.12 | vmaster | i'll try with my ep93xx board, it has the same chip in the same configuration |
| 16:04.29 | vmaster | do you have the MMU/Caches enabled? |
| 16:05.12 | prpplague | vmaster: the mmu/caches should be turned off on reset |
| 16:05.50 | prpplague | vmaster: ( i checked to make sure) |
| 16:06.03 | vmaster | the openocd should tell you whether the caches are on or off |
| 16:09.28 | prpplague | vmaster: hmm, using the arm920t cache_info ? |
| 16:10.20 | vmaster | poll |
| 16:10.34 | vmaster | > Target 0 halted |
| 16:10.34 | vmaster | target halted in ARM state due to debug request, current mode: Supervisor |
| 16:10.34 | vmaster | cpsr: 0x200000d3 pc: 0x00010f8c |
| 16:10.34 | vmaster | MMU: enabled, D-Cache: enabled, I-Cache: enabled |
| 16:10.57 | vmaster | that's printed right after a halt, too |
| 16:11.04 | prpplague | odd, when i issue the poll command i get no additional info for mmu and d-cache |
| 16:11.52 | vmaster | did you configure your target as "target arm920t ..."? |
| 16:12.17 | vmaster | "target arm9tdmi ..." is generic for all arm9tdmi based systems, without paying attention to caches etc. |
| 16:12.37 | prpplague | ahh |
| 16:12.41 | prpplague | changed |
| 16:12.47 | prpplague | now i'm getting the additional info |
| 16:13.02 | prpplague | all disabled |
| 16:13.18 | vmaster | okay, and what operations produce inconsistent results? |
| 16:13.40 | vmaster | i haven't used the cfi stuff for a while, could be that regression causes it to fail |
| 16:13.44 | prpplague | vmaster: flash erase 0 0 10 |
| 16:14.01 | vmaster | did you specify a "working_area"? |
| 16:14.11 | prpplague | no |
| 16:14.43 | vmaster | okay, i'm just dumping my current flash content and try after that |
| 16:14.52 | prpplague | vmaster: whats the working area for? |
| 16:16.27 | prpplague | Error: cfi.c:214 cfi_intel_wait_status_busy(): status register: 0xff |
| 16:16.27 | prpplague | Error: cfi.c:216 cfi_intel_wait_status_busy(): Block Lock-Bit Detected, Operation Abort |
| 16:16.28 | prpplague | Error: cfi.c:218 cfi_intel_wait_status_busy(): Program suspended |
| 16:16.28 | prpplague | Error: cfi.c:220 cfi_intel_wait_status_busy(): Low Programming Voltage Detected, Operation Aborted |
| 16:16.28 | prpplague | Error: cfi.c:222 cfi_intel_wait_status_busy(): Program Error / Error in Setting Lock-Bit |
| 16:16.28 | prpplague | Error: cfi.c:224 cfi_intel_wait_status_busy(): Error in Block Erasure or Clear Lock-Bits |
| 16:16.30 | prpplague | Error: cfi.c:226 cfi_intel_wait_status_busy(): Block Erase Suspended |
| 16:18.22 | vmaster | the working_area is used to speed things up: the DCC download feature puts a small assembler routine into target memory and executes it there, which accepts data from the DCC (faster than normal memory writes) |
| 16:19.01 | vmaster | and the flash algorithms like cfi and str7x use it do download block flashing code, which is orders of magnitude faster than using memory accesses |
| 16:19.06 | prpplague | vmaster: ahh, but that wouldn't be required for basic flash erase? |
| 16:19.11 | vmaster | nope |
| 16:20.13 | prpplague | hmm |
| 16:23.46 | vmaster | sorry, gotta go for a bit... i'll look into this as soon as i get back |
| 16:24.08 | prpplague | vmaster: np |
| 16:24.11 | prpplague | vmaster: thanks |
| 17:28.04 | vmaster | prpplague: okay, erasing and flashing both work reliably on my ep93xx with a te28f128j3 |
| 17:36.10 | prpplague | interesting |
| 17:36.20 | prpplague | vmaster: wonder what the problem is |
| 17:36.29 | prpplague | vmaster: do you have a script that you use? |
| 17:37.00 | prpplague | vmaster: single chip width 2 bus 2? |
| 17:37.11 | vmaster | nope, no script |
| 17:37.25 | prpplague | vmaster: so you started up, did the following |
| 17:37.27 | vmaster | single chip with 2, 2 |
| 17:37.31 | prpplague | flash probe 0 |
| 17:37.41 | prpplague | flash erase 0 0 127 |
| 17:37.53 | vmaster | first i write to the ebi to enable 16-bit memory |
| 17:37.56 | prpplague | flash write 0 testapp.bin 0x00000000 |
| 17:38.26 | prpplague | vmaster: right, my board has that enabled on reset |
| 17:39.06 | prpplague | hmm |
| 17:39.13 | vmaster | then i probe, then i erase, then write, then dump to see if was written |
| 17:39.35 | vmaster | could you run with -d -l <logfile> and send me the log via mail? |
| 17:39.46 | prpplague | vmaster: can you pastebin what you got after doing a probe, issue the info command? |
| 17:40.15 | prpplague | vmaster: yep will do |
| 17:41.20 | prpplague | vmaster: i'm wondering if its getting some bogus values during the probe |
| 17:41.30 | vmaster | http://pastebin.ca/170561 |
| 17:42.19 | vmaster | do you see other Warnings/Errors in the console output beside the cfi.c errors? |
| 17:44.10 | prpplague | Error: arm7_9_common.c:560 arm7_9_execute_sys_speed(): timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 4 |
| 17:44.17 | prpplague | vmaster: my cfi data matches yours |
| 17:45.36 | vmaster | ah, okay, this isn't good |
| 17:46.10 | vmaster | try without "arm7_9 fast_memory_access enable" |
| 17:46.26 | vmaster | mhh, looks like this was without it... |
| 17:51.37 | vmaster | prpplague: what jtag_speed have you set? |
| 17:52.07 | vmaster | prpplague: 0: 6MHz, 1: 3MHz, 2: 2MHz, 3: 1.5MHz - 0-2 shouldn't make a differene performance wise |
| 17:52.21 | vmaster | but might improve stability |
| 17:54.50 | vmaster | the timeout means that the core didn't resync to debug speed in at least 500ms - all it had to do was resync back to the memory clock, execute a LDM/STM, and resync back to DCLK |
| 17:55.42 | vmaster | this is so simple that a communication problem is a likely cause - at 6mhz, jtag cable length, board traces and connectors might cause problems |
| 18:02.51 | prpplague | vmaster: i have jtag_speed set to 1 |
| 18:03.05 | prpplague | vmaster: and i've not been using it with fast_memory_access disabled |
| 18:10.51 | prpplague | vmaster: seems to be working better with 2 |
| 18:17.38 | vmaster | better as in good, or better as in doesn't fail as often? |
| 18:21.08 | prpplague | doesn't fail as often |
| 18:21.13 | prpplague | vmaster: still problematic |
| 18:28.22 | prpplague | vmaster: when doing flash procedures, why don't you display the current offset? |
| 18:32.11 | vmaster | i wanted to implement an async "progress" indication, but never got to implement it |
| 18:32.26 | vmaster | ideally, the flash interface doesn't know what a telnet interface is |
| 18:33.50 | prpplague | ahh true enough |
| 18:34.27 | prpplague | vmaster: well the wiggler seems to be working, just not the ft2232 |
| 18:34.43 | vmaster | you could try enabling the high output drive capability |
| 18:35.02 | vmaster | that solved some stability issues for me |
| 18:35.20 | prpplague | hmm |
| 18:37.21 | vmaster | you'll have to write to the eeprom |
| 18:37.32 | prpplague | lovely |
| 18:37.42 | prpplague | vmaster: what kind of stability problems did you have? |
| 18:38.04 | vmaster | sometimes bogus data when working with a FPGA board |
| 18:38.13 | vmaster | ah |
| 18:38.15 | vmaster | forget about it |
| 18:38.27 | vmaster | your drivers take care of that for you |
| 18:38.39 | vmaster | i had the plain dlp2232m |
| 18:38.55 | prpplague | ahh ok |
| 18:39.24 | vmaster | well, your problems strongly indicate a communication problem |
| 18:39.31 | prpplague | yea sounds that way to me |
| 18:39.55 | prpplague | just surprised that it works with the wiggler and not the ft2232 |
| 18:40.14 | prpplague | i'll test with a couple other boards to see what i get |
| 18:40.56 | prpplague | vmaster: one more thing, the working_area |
| 18:41.13 | vmaster | if your chip has SRAM you could use that |
| 18:41.24 | prpplague | vmaster: ahh thats what i was about to ask |
| 18:41.24 | vmaster | without offloading the flashing to the target performance is horrible |
| 18:41.50 | prpplague | vmaster: the s3c2410 has 16k internal sram |
| 18:42.08 | vmaster | ideal for this purpose |
| 18:42.23 | vmaster | you can tell the openocd either to backup this area, or allow it to do whatever it wants |
| 18:42.31 | vmaster | backup|nobackup |
| 18:42.40 | prpplague | backup to where? |
| 18:43.03 | vmaster | read everything the first time it needs the working area, restore it before a resume |
| 18:43.11 | prpplague | ahh |
| 18:43.13 | prpplague | gotcha |
| 18:52.32 | prpplague | vmaster: when the system boots its only running with the base clock of 12mhz |
| 18:52.58 | prpplague | vmaster: think it would make any difference if i setup the main clock to what the normal running speed is? |
| 18:54.24 | vmaster | hmm... it's a hard macrocell, where ARM doesn't ask for synchronizers, so it shouldn't matter |
| 18:55.09 | vmaster | but of course you could try - start up with jtag_speed 8 or so, then use 'mww' to enable the PLL |
| 18:58.36 | prpplague | vmaster: i'm using jtag_speed 2 right now, i don't see much difference in performance from a wiggler |
| 19:01.09 | vmaster | mhh, get yourself a 16kb file and upload it to SRAM (load_binary <filename> <address>) |
| 19:01.16 | vmaster | that should tell you how fast it was |
| 19:02.10 | vmaster | make sure you comment the working_area out |
| 19:03.16 | prpplague | vmaster: gotcha |
| 19:03.28 | prpplague | vmaster: for dcc_downloads you need a working area correct? |
| 19:03.31 | vmaster | yes |
| 19:03.42 | vmaster | but you'll see a huge difference even without |
| 19:04.09 | prpplague | hmm |
| 19:04.09 | vmaster | ah, debug output has a severe impact on speed |
| 19:04.14 | prpplague | ahh |
| 19:04.18 | vmaster | debug_level 2 |
| 19:04.31 | vmaster | 3 is DEBUG, 2 is INFO |
| 19:04.49 | *** join/#openjtag [g2] (n=g2@nslu2-linux/g2) |
| 19:04.53 | prpplague | Warning: jtag.c:1037 jtag_read_buffer(): value captured during scan didn't pass the requested check: captured: 00 check_value: 01 check_mask: 0f |
| 19:04.57 | prpplague | i get alot of those |
| 19:05.08 | [g2] | prpplague what are you running ? |
| 19:05.21 | prpplague | [g2]: in circles |
| 19:05.28 | prpplague | hehe |
| 19:05.35 | [g2] | :) |
| 19:05.43 | prpplague | new gee-wiz ft2232 dongle with some s3c2410 boards |
| 19:05.52 | [g2] | ahh |
| 19:06.17 | [g2] | prpplague you don't happen to have one of those olimex arm-usb-jtag dongles do you ? |
| 19:07.05 | vmaster | prpplague: that's actually fatal |
| 19:07.12 | vmaster | it means that communication is broken |
| 19:07.28 | prpplague | vmaster: ahh |
| 19:07.33 | vmaster | during Shift-IR, it should read b0001 |
| 19:07.42 | prpplague | [g2]: no the one i have is similiar |
| 19:08.21 | vmaster | if it doesn't communication is out of sync |
| 19:08.23 | prpplague | vmaster: hmm, noise? |
| 19:08.45 | vmaster | how long is the cable from the dongle to the target board? |
| 19:08.47 | prpplague | vmaster: wonder if its those buffers |
| 19:09.01 | vmaster | i've checked the datasheets, they should be good for a lot more |
| 19:09.04 | prpplague | vmaster: 6-8 inches |
| 19:09.13 | vmaster | [g2]: a FT2232L |
| 19:09.13 | prpplague | [g2]: ft2232 |
| 19:09.49 | [g2] | prpplague you don't have that sam7 running do you ? |
| 19:09.52 | prpplague | vmaster: think i need shorter? |
| 19:10.02 | prpplague | [g2]: naw, not yet |
| 19:10.22 | vmaster | hmm, 15cm should be fine |
| 19:10.35 | prpplague | vmaster: thats what i thought |
| 19:12.28 | prpplague | vmaster: with jtag_speed 8 no errors |
| 19:12.31 | prpplague | hehe |
| 19:16.57 | prpplague | vmaster: 6 is as low as i can go without errors |
| 19:20.50 | vmaster | mhh, this is going to impact performance |
| 19:21.22 | vmaster | are these your own boards? i.e. do you know if someone jtagged them at higher speeds? |
| 19:22.01 | prpplague | vmaster: these are our boards |
| 19:22.07 | prpplague | vmaster: we've always used wigglers |
| 19:23.20 | prpplague | vmaster: i suspect that it is the traces |
| 19:24.22 | prpplague | vmaster: i'm gonna experiment with running the system with the clocks and sdram enabled and see what the difference in performance is |
| 19:25.37 | prpplague | vmaster: if i use the sdram and give it more working_area, would that improve performance? |
| 19:27.47 | vmaster | iirc i'm using up to 32kb, but it shouldn't make much of a difference if it's 4 or 32 |
| 19:27.56 | vmaster | less than 1kb might negatively affect performance |
| 19:28.49 | prpplague | okie dokie |
| 19:31.58 | prpplague | holy cow |
| 19:32.03 | prpplague | big big big difference |
| 19:33.36 | vmaster | hmm? |
| 19:34.14 | prpplague | yea seems to be running well after initing the clocks and sdram |
| 19:34.27 | vmaster | even at higher jtag speeds? |
| 19:35.22 | vmaster | strange, i could work with a at91rm9200 at 32khz with no problems (of course neither fast_memory_access nor dcc_downloads), but at 6mhz tck |
| 19:35.44 | prpplague | vmaster: no still at jtag_speed 6 |
| 19:35.51 | vmaster | ah, ok |
| 19:36.14 | prpplague | vmaster: but atleast at jtag_speed 6 it does a 64k flash in just a couple of seconds |
| 19:36.39 | vmaster | heh, i flash my 256kb str7 in less than 5 ;) |
| 19:37.21 | prpplague | vmaster: yea my target is erase 16mb flash, then flash a 4mb file |
| 19:37.30 | prpplague | s/target/goal |
| 19:38.34 | prpplague | [g2]: you gonna get one of those olimex jtag dongles? |
| 19:39.51 | [g2] | prpplague I would, but nobody is stocking them :( as olimex was on holiday |
| 19:40.17 | [g2] | My SAM7 boards are delayed due to that (I'm a little bummed about it) :( |
| 19:40.29 | prpplague | bummer |
| 19:40.47 | prpplague | hehe, save you money, there is a cool new s3c2410 board out soon, hehe |
| 20:00.38 | prpplague | 35 seconds |
| 20:01.03 | vmaster | at jtag_speed 6? |
| 20:01.07 | vmaster | not too bad |
| 20:02.48 | prpplague | yea |
| 20:02.59 | prpplague | vmaster: doing a 4mb test now |
| 20:03.38 | [g2] | prpplague which board ? |
| 20:03.45 | prpplague | vmaster: i got an error with "no enough working space" |
| 20:03.54 | prpplague | [g2]: which arm board or which jtag dongle? |
| 20:04.08 | [g2] | arm board |
| 20:04.44 | prpplague | [g2]: the one i'm working with is the dev board for the M5900 |
| 20:04.52 | prpplague | [g2]: one sec, url |
| 20:05.43 | prpplague | [g2]: http://www.elinux.org/wiki/M5900 and http://www.linuxdevices.com/articles/AT5552849613.html |
| 20:06.23 | prpplague | vmaster: Warning: target.c:535 target_alloc_working_area(): not enough working area available |
| 20:06.33 | vmaster | prpplague: that might mean i have a bug that the working area isn't marked as free again |
| 20:06.42 | vmaster | the code keeps the algorithm, but frees the buffer |
| 20:06.44 | vmaster | or at least it should |
| 20:06.46 | vmaster | let me check |
| 20:06.50 | prpplague | vmaster: the working area need to be bigger than the file you are transfering? |
| 20:06.56 | vmaster | no |
| 20:07.04 | vmaster | up to 32kb + a few byte for the algorithm |
| 20:07.56 | prpplague | hmm ok, i allocated 128kb so that shouldn't be a problem |
| 20:08.08 | prpplague | vmaster: 171 seconds for 4mb |
| 20:08.21 | [g2] | prpplague that looks quite nice |
| 20:08.40 | [g2] | I'd offer to do some work on those if you sent me a few :) |
| 20:08.46 | prpplague | hehe |
| 20:08.58 | prpplague | [g2]: well we have a hobby board coming out soon |
| 20:09.24 | [g2] | when and how much ? |
| 20:09.49 | prpplague | hehe |
| 20:09.55 | prpplague | next 45 days |
| 20:10.02 | [g2] | 45 days... that's forever |
| 20:10.14 | prpplague | we'll have 10 freebies for devrs that will post to a wiki with projects and code |
| 20:10.43 | [g2] | s3c2410 based ? |
| 20:10.47 | prpplague | yea |
| 20:11.06 | prpplague | [g2]: see the sodim for the m5900 dev board on that elinux page? |
| 20:11.41 | vmaster | prpplague: in cfi.c at line 688 |
| 20:11.42 | vmaster | + target_free_working_area(target, source); |
| 20:11.42 | vmaster | + |
| 20:12.01 | prpplague | [g2]: picture that with 80-pin .1" headers |
| 20:13.03 | prpplague | vmaster: right before the destroy_reg_parms ? |
| 20:13.14 | vmaster | yeah |
| 20:13.48 | vmaster | you'll have to re-test at least 4 times to have it fail |
| 20:14.06 | vmaster | with a 128kb working area and 32kb+a bit per write operation |
| 20:14.50 | prpplague | ahh |
| 20:16.04 | prpplague | just wish i could get it to work at jtag_speed 2 |
| 20:16.22 | prpplague | right now i'm getting between 25-30kbps |
| 20:17.57 | prpplague | oh shoot, forgot to enable fast_memory_access |
| 20:20.59 | prpplague | still, getting apex on there in less than 5 seconds is great |
| 20:24.42 | prpplague | vmaster: wonder if i put a shorter heavier shield cable connecting the board |
| 20:26.48 | prpplague | vmaster: wow that one fix did nicely |
| 20:26.59 | prpplague | vmaster: droped about 40 seconds off |
| 20:28.11 | vmaster | shorter cable? |
| 20:29.01 | prpplague | vmaster: no the free_working_area |
| 20:30.26 | vmaster | fast_memory_access or free_working_area? not forgetting that it may reuse the on-target buffer shouldn't affect target |
| 20:31.10 | vmaster | ... performance, not target |
| 20:31.26 | prpplague | vmaster: btw, not that i'm complaining, for the flash erase, it might be nice to have a similiar results statement, i.e. "erased flash bank 0 at sectors 0 thru 60 in 27s 78665us" |
| 20:31.47 | prpplague | vmaster: after adding the fix you suggested for the "target_free_working_area" |
| 20:32.00 | prpplague | vmaster: i got a 40 second drop in transfer time |
| 20:32.10 | vmaster | strange |
| 20:32.22 | vmaster | well, i'm glad it got faster, i'm just not sure why, but hey :) |
| 20:32.37 | vmaster | one doesn't need to know everything, i guess |
| 20:33.05 | vmaster | ah, yeah, the result statement could be added |
| 20:34.27 | prpplague | ok so 72 seconds to erase 16mb, and then 138 seconds to program 4mb |
| 20:34.40 | prpplague | plus about 10 seconds of misc |
| 20:35.58 | prpplague | vmaster: hmm, i keep wondering if those buffers on the jtag dongle are creating a problem |
| 20:36.14 | prpplague | i've had bad luck with alot of buffers lately |
| 20:37.36 | vmaster | the datasheet lists worst-case switching times of less than 3ns |
| 20:37.48 | vmaster | but then i'm no ee |
| 20:39.13 | prpplague | me either, i'm just a wannabie |
| 20:39.32 | prpplague | or should i say, wannabi-ee |
| 20:39.37 | vmaster | heh ;) |
| 20:50.38 | prpplague | vmaster: yea consistantly at 138 seconds |
| 20:50.44 | prpplague | lovely |
| 20:50.51 | prpplague | now if i can trace down the speed issue |
| 20:50.56 | prpplague | that would be great |
| 20:51.53 | prpplague | vmaster: thanks for the help, heading home for the day |
| 20:51.56 | prpplague | !! later |