Skip to main content
Topic: Bus Pirate Firmware 6.3 BETA development (Read 20307 times) previous topic - next topic

Re: Bus Pirate Firmware 6.3 BETA development

Reply #15
I found the line and change that causes the $ command to fail, see http://code.google.com/p/dangerous-prot ... il?id=5#c1

Is the dangerous-prototypes-open-hardware Google Code the right place to report bugs? I also found the 'the-bus-pirate' Google Code page, which says downloads and SVN have moved but doesn't mention the issue list?

Re: Bus Pirate Firmware 6.3 BETA development

Reply #16
STOP PRESS!

The info/conclusion here is not completely correct (but it got us closer so nice work anyway...)
http://http://code.google.com/p/dangerous-prototypes-open-hardware/issues/detail?id=5#c1

The real cause for this problem is this in baseIO.c

unsigned char UART1TXRdy(void) {
      return  U1STAbits.UTXBF;
}

The returned TRUE/FALSE polarity is wrong (inverted.) 

Previously I had advised that this:

    while (UART1TXRdy == 0); //wait untill TX finishes

should be this:

    while (0 == UART1TXRdy()); //wait untill TX finishes

While this test was incorrect UART1TXRdy() was never called so the bug in it never appeared.

Now with the above fix-up it does and needs to be corrected to:

unsigned char UART1TXRdy(void) {
      return  !U1STAbits.UTXBF;
}


This appears in TWO places inside baseIO.c. Both need to be corrected.

As best I can see the only functions in the BPv3 that this will affect (fix!) are the entry to the bootloader and the baudrate setting for the UART mode.

Before finalizing on the above solution I would recommend that people try it and double check my theory then push the correction to the SVN.

Re: Bus Pirate Firmware 6.3 BETA development

Reply #17
[quote author="JTR"]STOP PRESS!

The info/conclusion here is not completely correct (but it got us closer so nice work anyway...) [/quote]

I did not mean to suggest that simply removing the loop was a solution, just that removing the loop fixes the problem and thus the real cause was in the loop somewhere, as you confirmed.

However, looking more closely at the UTXBF bit that is checked by UART1TxRdy shows that it indicates whether the (four byte) UART TX buffer is full. This means that with the current code (along with your fix), the while loop waits until the TX buffer is not full (as opposed to waiting until the TX buffer is _empty_). Additionally, the code for the UART1TX function which does the actual transmission is:

Code: [Select]
void UART1TX(char c) {
    if (bpConfig.quiet) return;
    while (U1STAbits.UTXBF == 1); //if buffer is full, wait
    U1TXREG = c;
}
So this means it already waits for room in the buffer during the queuing of bytes. In particular, this means that after sending a line, the buffer could be full and the while loop will wait at most one bit time. However, if the overhead of sending a byte (e.g. function returns) is more than a bit time, the current while loop doesn't actually do anything.

In any case, wouldn't it make more sense to use WAITTXEmpty instead of the while loop as it is now? This would actually wait for the last byte from the buffer to be fully transmitted, which seems like a better plan?

Re: Bus Pirate Firmware 6.3 BETA development

Reply #18
On an unrelated note: Is there any reason this topic is not in the "Development" subforum and is not an announcement like the 6.1 and 6.2 development topics? Now it's easy to miss this topic for newcomers and make them think that 6.2 is the most recent version under development...

Re: Bus Pirate Firmware 6.3 BETA development

Reply #19
[quote author="matthijs"][quote author="JTR"]STOP PRESS!

The info/conclusion here is not completely correct (but it got us closer so nice work anyway...) [/quote]

I did not mean to suggest that simply removing the loop was a solution, just that removing the loop fixes the problem and thus the real cause was in the loop somewhere, as you confirmed.

However, looking more closely at the UTXBF bit that is checked by UART1TxRdy shows that it indicates whether the (four byte) UART TX buffer is full. This means that with the current code (along with your fix), the while loop waits until the TX buffer is not full (as opposed to waiting until the TX buffer is _empty_). Additionally, the code for the UART1TX function which does the actual transmission is:

Code: [Select]
void UART1TX(char c) {
    if (bpConfig.quiet) return;
    while (U1STAbits.UTXBF == 1); //if buffer is full, wait
    U1TXREG = c;
}
So this means it already waits for room in the buffer during the queuing of bytes. In particular, this means that after sending a line, the buffer could be full and the while loop will wait at most one bit time. However, if the overhead of sending a byte (e.g. function returns) is more than a bit time, the current while loop doesn't actually do anything.

In any case, wouldn't it make more sense to use WAITTXEmpty instead of the while loop as it is now? This would actually wait for the last byte from the buffer to be fully transmitted, which seems like a better plan?[/quote]

Yes, I agree with all of this. The BP should wait for a complete UART flush before going to the bootloader (and entering the UART mode.) It seems the thinking here got confused somewhere, (Ready != Complete) and the whole thing only worked previously because two bugs mostly cancelled each other out.

Anyway, there is enough insight on the issue now for it to be fixed properly and pushed to the SVN by interested parties.

Bus Pirate Firmware 6.3 BETA development

Reply #20
how are we advancing on the bp4v firmware 6.3,  i believe 6.2 firmware has got an issue while connecting using uart mode :( ..


Sent from my iPhone using Tapatalk

Re: Bus Pirate Firmware 6.3 BETA development

Reply #21
Hi guys, I noticed this:

HiZ>m 4
I2C mode:
 1. Software
 2. Hardware

(1)>2
Set speed:
 1. 100KHz
 2. 400KHz
 3. 1MHz
(1)>2
Ready
I2C>i
Bus Pirate v4
Firmware v6.3-beta1 r2088
DEVID:0x1019 REVID:0x0004 (24FJ256GB106 UNK)
http://dangerousprototypes.com
CFG0: 0xFFFF CFG1:0xFFFF CFG2:0xFFFF
*----------*
Pinstates:
#12    #11    #10    #09    #08    #07    #06    #05    #04    #03    #02    #01
GND    5.0V    3.3V    VPU    ADC    AUX2    AUX1    AUX    -      -      SCL    SDA
P      P      P      I      I      I      I      I      I      I      I      I
GND    0.00V  0.00V  0.00V  0.00V  L      L      L      L      L      L      L
POWER SUPPLIES OFF, Pull-up resistors OFF, Open drain outputs (H=Hi-Z, L=GND)
MSB set: MOST sig bit first, Number of bits read/write: 8
a/A/@ controls CS pin
I2C (mod spd)=( 1 1 )
*----------*
I2C>

it's the same with SPI.

Re: Bus Pirate Firmware 6.3 BETA development

Reply #22
'$' no longer causes bus pirate to reset to bootloader. Is there a fix for this

Re: Bus Pirate Firmware 6.3 BETA development

Reply #23
[quote author="Samual"]'$' no longer causes bus pirate to reset to bootloader. Is there a fix for this[/quote]
Read the posts near the top of this pag on this thread, that issue has already been reported and diagnosed (but no official statement regarding a fix has been made, though).

Re: Bus Pirate Firmware 6.3 BETA development

Reply #24
Can someone post a link for the latest source files


Re: Bus Pirate Firmware 6.3 BETA development

Reply #26
Can you make a zip file. The one on google code is old and I don't want to install a svn client

 

Re: Bus Pirate Firmware 6.3 BETA development

Reply #27
Hi there,
apologize me for posting twice the same thing in two different place, but here it should be the most correct one.
I hope this can help.
 
---------------------------------------------------------------
 
Bus Pirate v3.6 using firmware v6.3-beta1 r2151 Bootloader v4.4, while performing b command:
 
Bus Pirate v3.5
Firmware v6.3-beta1 r2151 Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
http://dangerousprototypes.com
HiZ>
 
Enter raw value for BRG
 
(34)>8
Adjust your terminal
Space to conti
 
and pressing spacebar I get:
 
(34)>8
Adjust your terminal
Space to contiHiZ>
 
I guess "Space to conti" of course it mean "Space to continue".
 
---------------------------------------------------------------
 
Bus Pirate v3.6 using firmware v6.3-beta1 r2151 Bootloader v4.4, when performing # command (RESET) I get:
 
HiZ>#
REÿ
Bus Pirate v3.5
Firmware v6.3-beta1 r2151 Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
http://dangerousprototypes.com
HiZ>
 
I guess the word "REÿ" in the beginning should in reality be "RESET" like for previous versions.
 
Both cases it's a trunk/corrupted message.
I know it's need to use less space as possible in the inside memory of the Bus Pirate, so I guess would be better remove or shorten messages in order to improve the device.
 
---------------------------------------------------------------
 
Bus Pirate v3.6 using firmware v6.3-beta1 r2151 Bootloader v4.4, while I was playing around with sle4442 smart card.
Diagram for the smart card readers connections is the usual for SLE4442 cards:
 
MOSI DATA
CLOCK CLOCK
CS RESET
+5volts +5volts
Vpullup +5volts
GND GND
 
Bus Pirate was setted as follow:
 
2WIRE>i
Bus Pirate v3.5
Firmware v6.3-beta1 r2151 Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
http://dangerousprototypes.com
CFG1:0xFFDF CFG2:0xFF7F
*----------*
Pinstates:
1.(BR) 2.(RD) 3.(OR) 4.(YW) 5.(GN) 6.(BL) 7.(PU) 8.(GR) 9.(WT) 0.(Blk)
GND 3.3V 5.0V ADC VPU AUX SCL SDA - -
P P P I I I O I I I
GND 3.31V 4.94V 0.00V 5.03V L H H H H
POWER SUPPLIES ON, Pull-up resistors ON, Open drain outputs (H=Hi-Z, L=GND)
LSB set: LEAST sig bit first, Number of bits read/write: 8
a/A/@ controls CS pin
R2W (spd hiz)=( 1 1 )
*----------*
 
Wile performing "answer to reset" command, namely (1) macro of the Bus Pirate, I get:
 
2WIRE>(1)
ISO 7816-3 ATR (RESET on CS)
RESET HIGH, CLOCK TICK, RESET LOW
ISO 7816-3 reply (uses current LSB setting): 0x45 0xC8 0x08 0x89
Protocol: unknown
Read type: variable length
Data units: 32768
Data unit length (bits): 1
 
instead the dump of the SLE4442 smart card data returns this:
 
2WIRE>{0x30 0 0xff} r:255 r:10
(-/_-)I2C START BIT
WRITE: 0x30
WRITE: 0x00
WRITE: 0xFF
(_/-)I2C STOP BIT
CLOCK, 0
READ: 0xA2 0x13 0x10 0x91 0xFF 0xFF 0x81 0x15 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xD2 0x76 0x00 0x00 0x04 0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
READ: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
 
As you can see the ATR response at macro (1) "answer to reset" is 0x45 0xC8 0x08 0x89, while in the dump ATR is the usual and well known 0xA2 0x13 0x10 0x91.
Something weird I thought.
So I tried to retrieved ATR value by sending the @^rrrr sequence, getting this:
 
2WIRE>@^arrrr
AUX INPUT/HI-Z, READ: 0
CLOCK TICKS: 0x01
AUX LOW
READ: 0xA2
READ: 0x13
READ: 0x10
READ: 0x91
 
and that is correct.
Then I tried to invert LSB/MSB order by "l/L" command:
 
2WIRE>l
MSB set: MOST sig bit first
 
Now performing the @^arrrr sequence I get:
 
2WIRE>@^arrrr
AUX INPUT/HI-Z, READ: 0
CLOCK TICKS: 0x01
AUX LOW
READ: 0x45
READ: 0xC8
READ: 0x08
READ: 0x89
 
and changing again MSB/LSB order by "L/l" command I have this:
 
2WIRE>L
LSB set: LEAST sig bit first
2WIRE>@^arrrr
AUX INPUT/HI-Z, READ: 0
CLOCK TICKS: 0x01
AUX LOW
READ: 0xA2
READ: 0x13
READ: 0x10
READ: 0x91
2WIRE>
 
So, bingoo!
0x45 0xC8 0x08 0x89 as ATR response while performing the macro (1) "answer to reset" it's due a wrong order in the LSB/MSB of the bytes.
I guess that is a bug and I think it is due the fact macro (1) always perform reading using MSB order and not caring about settings because doesn't matter how "l/L" command was set in the Bus Pirate, reading doesn't care about it returning always the wrong result.
Again, I guess even the follow message
 
Protocol: unknown
Read type: variable length
Data units: 32768
Data unit length (bits): 1
 
all they are wrong because parsed starting by bytes not in the correct LSB order.
Hoping all this can help.
Thanks in advance.
 
Kindest regards,
sre71