Skip to main content ↑ ↓

Show Posts

This section allows you to view all Show Posts made by this member. Note that you can only see Show Posts made in areas you currently have access to.

Messages - tnt

2
OpenOCD JTAG / Re: JTAG quite slow and ideas to make it go faster
Here are the 4 patches.

The loop is at 1MHz exactly. You can pull it to 1.33 MHz by dropping the support for the 'delay' by undefining USE_DELAY in the .S file. But there is not much point because the bitbanging loop is not the limiting factor anymore.

Even tough the loop is now ~8-10x faster than before, the transfers haven't sped up that much which is disappointing. Only ~ 2x speed up ( from 3.5 k/s -> 7 k/s in download and from 9.5 k/s -> 19 ko/s in upload)

The two main limiting factors are :
* The UART speed: Currently, while in a burst you can _clearly_ see the bitbanging for 16 bits, then a gap where it's waiting for the next 4 bytes ... If we could somehow make the UART go faster ... 2MBps would be nice.
* Space between commands: Open OCD has some giant hole where no data is xfered between commands. These take up about 50 % of the time. If we could somehow improve the openocd driver, this could speed up by another 1.5 -> 2 times.
3
OpenOCD JTAG / Re: JTAG quite slow and ideas to make it go faster
I have a working loop and it outputs bits at ~ 1.33 MHz, which is faster than the UART can provide them anyway.
I still need to clean up some stuff in the serial but it's going well so far.

Is there a procedure to post patches ?

I have to change some stuff in the linker script to put the terminal buffer at the end of the memory, so that all small variables are in the first 8192 bytes of memory (which ASM can access more easily and faster).
4
OpenOCD JTAG / Re: JTAG quite slow and ideas to make it go faster
I understand exactly what TMS is used for.

When I say 'sync it', I mean toggle it when needed. If you give control of the CLK / TDI / TDO to the SPI module you can no longer 'toggle' TMS when it needs to (during state change, but that's not a 'rare' event) and if you don't have a number of bits to shift compatible with SPI, you'd have to switch those pins function back and forth from SPI to GPIO and play like that, basically a big mess.
5
OpenOCD JTAG / Re: JTAG quite slow and ideas to make it go faster
Ok, I've refined a little my code and tried to compile it. (didn't test it in hw yet).

My current hope is to achieve ~ 700 kHz and use only about 1/3 of the program space previously used by the tap shift method (currently 288 bytes, going down to about 90 bytes)
I could push it up to 1 MHz (by unrolling the inner loop) but then the program space would be a little much to my taste.

Using the SPI Hw could provide a lot of speedup indeed, but that's a lot of hack to sync TMS and to make sure you don't generate glitches and stuff when going from SPI mode to normal IO mode (if not a multiple of 8 bits or so). Too bad the spi module isn't more flexible.
6
Bus Pirate Development / Re: Howto rebuild the firmware
Thanks to the both of you.

I was indeed using pirateloader. With the export, I get an hex that's the same length as the official one. I'll try flashing it tonight see if it works.
7
Bus Pirate Development / Howto rebuild the firmware
Hi,

I was wondering if there was something special needed to rebuild the firmware ?

I downloaded MPLAB and the C compiler evaluation, installed them. Then cloned the SVN and loaded the project file in source/ and build that.
Then I tried flashing the output/busPirate.hex resulting of this but the loaded doesn't even want to load the .hex file ...

    Sylvain
9
OpenOCD JTAG / JTAG quite slow and ideas to make it go faster
Hi,

Yesterday I had to dump the NOR from a target with JTAG. It took about 8 hours to dump 64 Mo of flash. That's pretty long !

When looking at the jtag bus, I notices that it is currently the limiting factor. (the with 'fast' uart mode, the uart keeps up but is slowed down by the bit-banging).

The JTAG bus is aroung 100-125 kHz  right now (with a very un-even duty cycle). I think that by using an optimized loop, we could bring that to 500 - 600 kHz. Which should provide a pretty nice speed up.

I haven't programmed PIC in a long time ... (back when the 16f84 was a new product), but I tried estimating what could be done by a quick look at the datasheet. Below is what I came up with (probably buggy but that's just to estimate the cycle count) :

Basically there would be several 'layers' of loop to avoid doing the uart test or handling #bits != 16 ... and you'd have one very fast function doing just the bit bang for a certain number of 16 bits words and for the 'end' and when uart flushes are needed, we'd just have an outer loop in C.


[tt:]params:
        W0      inBuffer
        W1      outBuffer
        W2      bits

                # Main full 16 bits loop
                # ----------------------

                SL      W2, #4, W3              # W3 = W2 >> 4;
_loop_f16:                                      # do {

                #  Fetch & organize 2x16 bits
                MOV     [W0++], W5              #   W5 = *((uint16_t*)W0++);
                MOV     [W0++], W6              #   W6 = *((uint16_t*)W0++);

                        # W5 has one byte TMS and one byte TDO
                        # W6 has one btes TMS and one byte TDO
                        #  -> We must reorgonize that !
                SWAP    W6                      #   W6 = swap_bytes(W6);
                XOR     W5, W6, W7              #   W7 = W5 ^ W6;
                AND     #0xff, W7               #   W7 &= 0xff;
                XOR     W5, W7, W5              #   W5 = W5 ^ W7;
                XOR     W6, W7, W6              #   W6 = W6 ^ W7;
                SWAP    W6                      #   W6 = swap_bytes(W6);

                #  Clear destination register
                CLR     W7

                #  Inner loop
                MOV     #15, W4
_loop_f16_inner:

                #   Clear TCK
                BCLR    IOPOR, OOCD_TCK

                #   Set TDO & TMS
                MOV     IOPOR, W8
                BTST.Z  W5, W4
                BSW.Z   W8, OOCD_TDO
                BTST.Z  W6, W4
                BSW.Z   W8, OOCD_TMS
                MOV     W8, IOPOR1

                #   Set TCK
                BSET    IOPOR, OOCD_TCK

                #   Read TDI
                BTST    IOPOR, OOCD_TDI
                BSW.Z   W7, W4

                #   Loop condition
                DEC     W4
                BRA     NZ, _loop_f16_inner

                #  Store result
                MOV     W7, [W1++]

                #  Loop condition
                DEC     W3, W3
                BRA     NC, _loop_f16           # } while (W2--);



                # FIXME: Do the rest 0..15 bits[/tt:]
10
OpenOCD JTAG / Re: OpenOCD Broken with FW V5.0
I tested it but it doesn't work. Same problem as a standard v5.0

Another piece of information: depending if I put the bus pirate in 'normal' or 'fast' speed, the error changes slightly. The weird swap at the beginning is exactly the same, but there is no swap at the end.

Am I the only one with this problem ? Do some people use v5 successfully with openocd ? Because here, the problem is not random, it happens each time and exactly the same way.
11
OpenOCD JTAG / Re: OpenOCD Broken with FW V5.0
I tested V4.5 and it works fine too.

In attachement, there is the full 'debug_level 3' output of OpenOCD as well as logic analyzer logs in VCD format (GtkWave) for the three firmware versions.

Here's an extract where you see the DR scan for IDCODE and you clearly see the problem :

V4.5
[tt:]Debug: 92 489 core.c:1028 jtag_examine_chain(): DR scan interrogation for IDCODE/BYPASS
Debug: 93 489 core.c:318 jtag_call_event_callbacks(): jtag event: TAP reset
Debug: 94 489 buspirate.c:585 buspirate_tap_execute(): executing tap num bits = 655 scans = 1
Debug: 95 489 buspirate.c:911 buspirate_serial_write(): size = 167 ret = 167
Debug: 96 489 buspirate.c:968 buspirate_print_buffer(): 05 02 8f 80 17 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 97 489 buspirate.c:968 buspirate_print_buffer(): 00 00 00 80 00 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 98 489 buspirate.c:968 buspirate_print_buffer(): 00 00 00 80 00 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 99 489 buspirate.c:968 buspirate_print_buffer(): 00 00 00 80 00 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 100 489 buspirate.c:968 buspirate_print_buffer(): 00 00 00 80 00 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 101 489 buspirate.c:968 buspirate_print_buffer(): 00 00 00 80 00 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 102 489 buspirate.c:968 buspirate_print_buffer(): 00 00 00 80 00 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 103 489 buspirate.c:968 buspirate_print_buffer(): 00 00 00 80 00 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 104 489 buspirate.c:968 buspirate_print_buffer(): 00 00 00 80 00 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 105 489 buspirate.c:968 buspirate_print_buffer(): 00 00 00 80 00 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 106 489 buspirate.c:974 buspirate_print_buffer(): 00 00 00 00 40 00 7f
Debug: 107 495 buspirate.c:943 buspirate_serial_read(): should have read = 85 actual size = 85
Debug: 108 495 buspirate.c:968 buspirate_print_buffer(): 05 02 8f ff d4 31 c9 83 7f 00 00 80 7f 00 00 80
Debug: 109 495 buspirate.c:968 buspirate_print_buffer(): 7f 00 00 80 7f 00 00 80 7f 00 00 80 7f 00 00 80
Debug: 110 495 buspirate.c:968 buspirate_print_buffer(): 7f 00 00 80 7f 00 00 80 7f 00 00 80 7f 00 00 80
Debug: 111 495 buspirate.c:968 buspirate_print_buffer(): 7f 00 00 80 7f 00 00 80 7f 00 00 80 7f 00 00 80
Debug: 112 495 buspirate.c:968 buspirate_print_buffer(): 7f 00 00 80 7f 00 00 80 7f 00 00 80 7f 00 00 80
Debug: 113 495 buspirate.c:974 buspirate_print_buffer(): 7f 00 00 80 7f
Warn : 114 495 core.c:1129 jtag_examine_chain(): AUTO auto0.tap - use "jtag newtap auto0 tap -expected-id 0x079263a9 ..."[/tt:]

v5.0
[tt:]Debug: 150 684 core.c:1028 jtag_examine_chain(): DR scan interrogation for IDCODE/BYPASS
Debug: 151 684 core.c:318 jtag_call_event_callbacks(): jtag event: TAP reset
Debug: 152 684 buspirate.c:585 buspirate_tap_execute(): executing tap num bits = 655 scans = 1
Debug: 153 684 buspirate.c:911 buspirate_serial_write(): size = 167 ret = 167
Debug: 154 684 buspirate.c:968 buspirate_print_buffer(): 05 02 8f 80 17 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 155 684 buspirate.c:968 buspirate_print_buffer(): 00 00 00 80 00 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 156 684 buspirate.c:968 buspirate_print_buffer(): 00 00 00 80 00 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 157 684 buspirate.c:968 buspirate_print_buffer(): 00 00 00 80 00 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 158 684 buspirate.c:968 buspirate_print_buffer(): 00 00 00 80 00 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 159 684 buspirate.c:968 buspirate_print_buffer(): 00 00 00 80 00 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 160 684 buspirate.c:968 buspirate_print_buffer(): 00 00 00 80 00 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 161 684 buspirate.c:968 buspirate_print_buffer(): 00 00 00 80 00 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 162 684 buspirate.c:968 buspirate_print_buffer(): 00 00 00 80 00 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 163 684 buspirate.c:968 buspirate_print_buffer(): 00 00 00 80 00 7f 00 00 00 00 00 80 00 7f 00 00
Debug: 164 684 buspirate.c:974 buspirate_print_buffer(): 00 00 00 00 40 00 7f
Debug: 165 690 buspirate.c:943 buspirate_serial_read(): should have read = 85 actual size = 85
Debug: 166 690 buspirate.c:968 buspirate_print_buffer(): 05 02 8f d4 31 ff c9 83 7f 00 00 80 7f 00 00 80
Debug: 167 690 buspirate.c:968 buspirate_print_buffer(): 7f 00 00 80 7f 00 00 80 7f 00 00 80 7f 00 00 80
Debug: 168 690 buspirate.c:968 buspirate_print_buffer(): 7f 00 00 80 7f 00 00 80 7f 00 00 80 7f 00 00 80 
Debug: 169 690 buspirate.c:968 buspirate_print_buffer(): 7f 00 00 80 7f 00 00 80 7f 00 00 80 7f 00 00 80
Debug: 170 690 buspirate.c:968 buspirate_print_buffer(): 7f 00 00 80 7f 00 00 80 7f 00 00 80 7f 00 00 7f
Debug: 171 690 buspirate.c:974 buspirate_print_buffer(): 00 80 00 80 7f
Info : 172 690 core.c:928 jtag_examine_chain_display(): JTAG tap: auto0.tap tap/device found: 0x0793fe63 (mfg: 0x731, part: 0x793f, ver: 0x0)
Warn : 173 690 core.c:966 jtag_examine_chain_end(): Unexpected idcode after end of chain: 576 0xfe0000ff
Warn : 174 690 core.c:966 jtag_examine_chain_end(): Unexpected idcode after end of chain: 608 0x00010000[/tt:]

If you look at the returned buffer, you can see some bytes have been weirdly swapped :

V4.5[font=courier:]Debug: 108 495 buspirate.c:968 buspirate_print_buffer(): 05 02 8f ff d4 31 c9 83 7f 00 00 80 7f 00 00 80[/font:]
V5.0[font=courier:]Debug: 166 690 buspirate.c:968 buspirate_print_buffer(): 05 02 8f d4 31 ff c9 83 7f 00 00 80 7f 00 00 80[/font:]
12
OpenOCD JTAG / [solved: use v5.1] OpenOCD Broken with FW V5.0
Hi,

I just tried the OpenOCD with the v5 firmware ( BPv3-Firmware-v5.0.hex ) and it doesn't work (not even the IDCODE)
Looking at it with a logic analyzer shows the the commands sent to the JTAG bus are correct, the TDO signal is correct on the bus but does _not_ match the bits received by openocd.

With the exact same setup and just reflashing to BPv3-Firmware-v4.2.OpenOCD.hex and things work fine.

Cheers,

   Sylvain

( ! ) Fatal error: Uncaught exception 'Elk_Exception' with message 'Please try again. If you come back to this error screen, report the error to an administrator.' in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
( ! ) Elk_Exception: Please try again. If you come back to this error screen, report the error to an administrator. in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
Call Stack
#TimeMemoryFunctionLocation
10.02262417632session_write_close ( )...(null):0
20.02312549208ElkArte\sources\subs\SessionHandler\DatabaseHandler->write( )...(null):0
30.02322549984Database_MySQL->query( ).../DatabaseHandler.php:119
40.07532688696Database_MySQL->error( ).../Db-mysql.class.php:273