Bug report v6.3-beta1 r2151 Bootloader v4.4.

Bus Pirate firmware and hardware development.

Bug report v6.3-beta1 r2151 Bootloader v4.4.

Postby sre71 » Tue Jan 07, 2014 2:31 pm

Hi there,
I hope is the right place and 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.
Those don't be annoying but remove them would be better IHMO.

Thanks in advance.

Kindest regards,
sre71
sre71
Jr. Member
Jr. Member
 
Posts: 62
Joined: Sat Aug 06, 2011 3:29 pm

Re: Bug report v6.3-beta1 r2151 Bootloader v4.4.

Postby sre71 » Thu Jan 09, 2014 4:39 pm

Hi there,
I have to add this.
While I was playing around with sle4442 smart card perhaps I have found another little bug.
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 this can help.
Thanks in advance.

Kindest regards,
sre71
sre71
Jr. Member
Jr. Member
 
Posts: 62
Joined: Sat Aug 06, 2011 3:29 pm

Re: Bug report v6.3-beta1 r2151 Bootloader v4.4.

Postby Xykon » Sat Feb 22, 2014 8:08 pm

Regarding the LSB/MSB bug, I found this comment in the code:

from: raw2wire.c
// R2W macros

//ISO 7813-3 Answer to reset macro for smartcards
// syntax: a0%255@^a
// **depricated, some cards are MSB first** forces LSB format for easy use
// now uses CS pin instead of AUX pin because 1,2,3 have build in pullups on CS but not AUX


So the source code acknowledges that it is always using LSB format instead of the user setting.

from: bitbang.c

Code: Select all
unsigned int bbReadByte(void){
   unsigned int i,di,dat=0;

   //bbi();//prepare for input
   bbR(MOSI); //setup for input

   for(i=0;i<modeConfig.numbits;i++){
      bbH(CLK,bitbang.delayClock);//set clock high
      di=bbR(MOSI); //same as MISO on 2-wire
      bbL(CLK,bitbang.delayClock);;//set clock low

[b]      //get MSB first
      dat=dat<<1;//shift the data input byte bits
      if(di)dat++;//if datapin in is high, set LBS[/b]
   }
   return dat;
}


The code here always returns the data in MSB format and doesn't check the MSB/LSB setting.

I'm not very familiar with bitwise operations yet, but after reading this Wikipedia article, I think this should theoretically work. Due to lack of hardware, I cannot try this myself at the time.

Code: Select all
unsigned int bbReadByte(void){
   unsigned int i,di,dat=0;
   //bbi();//prepare for input
   bbR(MOSI); //setup for input


   for(i=0;i<modeConfig.numbits;i++){
      bbH(CLK,bitbang.delayClock);//set clock high
      di=bbR(MOSI); //same as MISO on 2-wire
      bbL(CLK,bitbang.delayClock);;//set clock low

                //get LSB first
                if (modeConfig.lsbEN==1){
                   dat |= (di << modeConfig.numbits-(i+1));
                }
                else{
                //get MSB first
                dat=dat<<1;//shift the data input byte bits
                if(di)dat++;//if datapin in is high, set LBS
                }
   }
   return dat;
}


I have attached a compiled version... maybe you can give it a try and let me know if this works... and if it doesn't work maybe someone smarter than me can post the correct code to make it work :)
Attachments
BPv3-firmware-v6.2-r2162.zip
(58.89 KiB) Downloaded 272 times
Xykon
Jr. Member
Jr. Member
 
Posts: 78
Joined: Mon Apr 16, 2012 1:34 pm

Re: Bug report v6.3-beta1 r2151 Bootloader v4.4.

Postby sre71 » Sun Feb 23, 2014 10:04 am

Hello Xykon.
Thank you very much for your attempt to fix the bug, you are very kind.
Unluckily I can't test it because when I try to load it in the BP I have this message:
**********************************************************
Parsing HEX file [BPv3-firmware-v6.2-r2162.hex]
Checksum does not match, line 4
Could not load HEX file, result=-1
**********************************************************
Maybe something wrong in your archive which perhaps may be corrupted or however bad.
I don't know.
One time more thank you!
I appreciate very much your work!
Many, many thanks!
Hope to read you soon.

Kindest regards,
sre71
sre71
Jr. Member
Jr. Member
 
Posts: 62
Joined: Sat Aug 06, 2011 3:29 pm

Re: Bug report v6.3-beta1 r2151 Bootloader v4.4.

Postby LAtimes » Sun Feb 23, 2014 10:26 am

The checksum error is due to hex file being in lowercase. Here is a Windows batch file I use to convert files to upper case:

@echo off
setlocal EnableDelayedExpansion
for /F "delims=" %%a in (%1) do (
set "line=%%a"
for %%b in (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z) do (
set "line=!line:%%b=%%b!"
)
echo !line!
)

To use it, run the batch file and pipe output to a temp file, for example, to_upper.bat BPv3-firmware-v6.2-r2162.hex > temp.hex
LAtimes
Newbie
Newbie
 
Posts: 6
Joined: Sat Feb 22, 2014 11:58 am

Re: Bug report v6.3-beta1 r2151 Bootloader v4.4.

Postby Xykon » Sun Feb 23, 2014 12:07 pm

Alternatively use the ds30 Loader GUI to program the BP. I normally program the BP directly from MPLAB-X using a PicKit2 or PicKit3 clone so I didn't even notice there was a problem.

So I programmed the bootloader from the BusPirate.package.v6.2-beta1, closed PGC/PGD with a jumper and opened "ds30 Loader GUI.exe" and selected the .hex file after unpacking it. It was programmed without any problems.

Screenshot 2014-02-23 17.03.54.png


P.S. At least according to the source code, pirate loader should be case insensitive:
+2010-06-28 - Made HEX parser case-insensative


Unfortunately I don't have the means to re-compile the pirate-loader package at the moment, so I cannot check if the latest source file really incorporates this change or if something is still buggy.
Xykon
Jr. Member
Jr. Member
 
Posts: 78
Joined: Mon Apr 16, 2012 1:34 pm

Re: Bug report v6.3-beta1 r2151 Bootloader v4.4.

Postby Xykon » Sun Feb 23, 2014 12:25 pm

Either way please find attached a new .hex file that also works with pirate-loader.exe under windows...
Attachments
BPv3-firmware-v6.2-r2162.zip
(58.89 KiB) Downloaded 245 times
Xykon
Jr. Member
Jr. Member
 
Posts: 78
Joined: Mon Apr 16, 2012 1:34 pm

Re: Bug report v6.3-beta1 r2151 Bootloader v4.4.

Postby sre71 » Sun Feb 23, 2014 3:19 pm

Hello Xykon.
Thank you very, very much for your hard work!
You are really very kind.
OK for your kind explanation about the culprit which it's by lowercase used in the hex file.
I don't knew it and for me it's useful to know.
Well also for the script you wrote in order to convert lowercase to uppercase file which I don't know how to use though because I'm not involved in these kind of matters, sorry about that.
About the hex file I used the last one you sent because it was already ready to use.
So I downloaded it onto the BP and started the testing.
Unluckily it doesn't work as it should.
Using the same settings like before in the past, I get the same wrong values when performing macro (1):

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

Macro (2) doesn't work too, but it was the same in the past when I wrote about this matter.
Another thing that perhaps may be help is that now performing command "i" (info) I get this:

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 O I
GND 3.31V 4.95V 0.00V 5.02V L L H L 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 )
*----------

which it's a kinda different from what I obtained in the past using the original v6.3-beta1 r2151 firmware and namely:

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 )
*----------*

notwithstanding I've always used the same settings.
I never tire of saying thank you for the commitment and the excellent work although for now it doesn't work as expected.
I know it's only the beginning, take no care about the result because without your work there may still be no improvement.
It is better a failed attempt than the to do nothing, IMHO.
So thanks and thanks again Xykon!
I really appreciate very much your work!
Many, many thanks!

Kindest regards,
sre71
sre71
Jr. Member
Jr. Member
 
Posts: 62
Joined: Sat Aug 06, 2011 3:29 pm

Re: Bug report v6.3-beta1 r2151 Bootloader v4.4.

Postby Xykon » Sun Feb 23, 2014 4:23 pm

Thanks for giving it a try.... I'm not really an expert on BP (or PIC in general) programming but was planning to do some work on SIM cards in the near future which is why I got interested in this bug.

I guess the only way to troubleshoot this further for me is to do some debugging with real hardware. As I moved from France to the UK not too long ago, I haven't been able to unpack all my electronics yet, so it'll take me some time to find my Smart Card breakout board to do some tests. I'll certainly keep working on this but don't expect anything in the next few days as I have some busy days at work ahead of me and was also planning to re-install my Windows PC from scratch as its starting to act up really strange. I hope some of the more qualified experts will also be able to offer some hints as to where exactly things are going wrong.

And from what I understand you are actually managing to work with your cards manually without the use of macros, and the problems you mentioned above are rather cosmetical and not blocking whatever you are working on. If you do get stuck on something though please let us know and we can hopefully help give you more tips on how to achieve your goals.
Xykon
Jr. Member
Jr. Member
 
Posts: 78
Joined: Mon Apr 16, 2012 1:34 pm


Return to Bus Pirate Development