We've kicked BP development in high gear! For the last few days we've been clearing out the backlog of Issues, and I guess this is a good time as any to move to version 6.3 beta... as of SVN rev 2088... Find attached the hex files for BP version's 3 and 4.., or compile from the latest source code in the SVN..
Here's the link to the tracker http://dangerousprototypes.com/track/ (http://dangerousprototypes.com/track/)
Any feedback would be greatly appreciated.
I'll use this post to add links to the latest issue fixes as they come...
Issues fixed in 6.3
Issue #66 (http://http://dangerousprototypes.com/track/view.php?id=66)
In baseIO.c the function bpWlongdecf() fails to correctly print out some values when the mld or mil bits are set.
e.g.: 1.1million as 1,0100,000.
Issue #73 (http://http://dangerousprototypes.com/track/view.php?id=73)
The other problem appeared to be a resolution issue. As an example, while measuring a 2Hz frequency, the measurement was often 1Hz. So I decided to take a stab at improving frequency measurements. I decided to use the prescaler only when necessary. I also decided to measure the period and divide for low frequencies.
Isssue #65 (http://http://dangerousprototypes.com/track/view.php?id=65)
Bus Pirate V4 AUX1 and AUX2 fail to return to input/hi-z state.
A patch file is attached while corrects the problem.
Isssue #63 (http://http://dangerousprototypes.com/track/view.php?id=63)
Add onboard pullup resistor command to binary mode
Isssue #50 (http://http://dangerousprototypes.com/track/view.php?id=50)
New display change during reads added, comand rd reads digital, rx reads hex and rb reads binary
Isssue #51 (http://http://dangerousprototypes.com/track/view.php?id=51)
BP4: During I2C interaction in terminal '}' stop bit command always returns "ERROR: command has no effect here"
Isssue #24 (http://http://dangerousprototypes.com/track/view.php?id=24)
UART TX pin read as input during 'v' command
Isssue #57 (http://http://dangerousprototypes.com/track/view.php?id=57)
Clutch pedal added to all protocols. output pins are now only connected once the turn on power supplies 'W' command is issued. they are disconnected again if 'w' command is issued (power off)... multiple repeatitive engage/disengage are posible...
Hi Fillip :o)
On #50 i did not had the time to try your version, (currently im still using mine ) but i will try it soon :o
I also mentioned in the note that it could be fun to have also "rc" who can display the byte like an ANSI character, cool for reading strings :o)
Maybe when you have the time to tweak that on too :-)
sure no problem, but isn't that the raw mode where the byte is sent as is.. just need to incorporate it, it'll take 1-2 lines of code to add...
added to the latest SVN ... here is the patch to r2089
I think "r" read and display with the default global setting.
so if you set it to hex or dec, or bin it will be the default case...
Am i wrong ?
what a meant by "rc" is instead of reading
rx:6 0x48 0x65 0x6c 0x6c 0x6f 0x21
we will get with
rc:6 H e l l o !
where each byte read is display by it's ansi representation.
:-)
[quote author="voidptr"]I think "r" read and display with the default global setting.
so if you set it to hex or dec, or bin it will be the default case...
Am i wrong ?
what a meant by "rc" is instead of reading
rx:6 0x48 0x65 0x6c 0x6c 0x6f 0x21
we will get with
rc:6 H e l l o !
where each byte read is display by it's ansi representation.
:-)[/quote]
That's exacly how it's implemented. just r reads out the default setting and the rd rx rb rw read out decimal, hex, binary and raw...
in raw mode raw bytes are sent to uart, which is read by the serial terminal as ANSII characters...
[quote author="arakis"]
That's exacly how it's implemented. just r reads out the default setting and the rd rx rb rw read out decimal, hex, binary and raw...
in raw mode raw bytes are sent to uart, which is read by the serial terminal as ANSII characters...[/quote]
Cool ! :o)
since I made my patch I find this so useful for formatting registers reading in a more "human" "logical" form.
I'm sure it will be useful to alot of people :o)
BASIC scripting mode is back in the latest firmware in the SVN v6.3 r2012
Isssue #53 (http://http://dangerousprototypes.com/track/view.php?id=53)
BPv4 firmware 6.3 bug
In i2c.c
Lines 939 and 940
[s:]while(U1STAbits.URXDA == 0);[/s:]//wait for subcommand byte
[s:]inByte=U1RXREG;[/s:] //get byte
Change to:
inByte=UART1RX(); //get byte //JTR April 9, 2013 line altered
More fixes here: viewtopic.php?f=41&t=5380 (http://dangerousprototypes.com/forum/viewtopic.php?f=41&t=5380)
P.S. It seems to me that firmware 6.3 will be fully ported to the USB stack in the BPv4 after the above two fixes are added. Based on the nature all the bug reports in these forums, actually based on what is NOT being reported in these forums, I would conclude that the USB stack on the BPv4 is working smashingly well.
just some suggestions for the new firmware
1) contextual help, when i press ? i want to get only the commands i can use, when i start in HiZ and i press ? i get a list of commands and most of them cannot be used on that context. Will be better to see only the options that can be used.
2)connection reminders, when i select a mode would be nice to get a reminder of how i have to connect my bp.
- for example in UART mode i cannot know from the terminal how to connect my wires.
3) Add PWM and frequency counter directly into the mode menu
4)openOCD
This update also seems to increase the stability of the SUMP / logic analyzer mode. With the 6.1 firmware, I frequently got the bus pirate to lock up at the end of a capture (it stopped responding after two of the five reset commands sent by OLS), when using smaller sample rates (e.g, 4Mhz was ok, while 20Khz would break nearly every time). I haven't been able to reproduce this since upgrading to 6.3 beta1.
This update also seems to increase the stability of the SUMP / logic analyzer mode. With the 6.1 firmware, I frequently got the bus pirate to lock up at the end of a capture (it stopped responding after two of the five reset commands sent by OLS), when using smaller sample rates (e.g, 4Mhz was ok, while 20Khz would break nearly every time). I haven't been able to reproduce this since upgrading to 6.3 beta1.
I had a bug with the previous firmware but so far the update is MUCH more stable than before. I'll keep monitoring for improvements.
This USB stack fix for the BPv4 needs to be pushed to the svn.
http://code.google.com/p/dangerous-prot ... sb_stack.c (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/Bus_Pirate/Firmware/dp_usb/usb_stack.c)
Line 456 reads:
if (epbd->BDSTAT &= ~BSTALL)
This should be:
if (epbd->BDSTAT &= BSTALL)
This is only a minor issue and in practice has no effect other than to prevent the USB stack from passing the USB Chapter 9 compliance test. The same fx is required on all releases of the USB stack including from the IR TOY and free standing echo tests etc...
Thanks...
The '$' command is not working to enter bootloader mode somehow. Every time I tried it (and exited my serial session to free up the device), the pirate-loader could not talk to the bootloader. I finally had to use the short of PGD/PGC and was able to downgrade back to v6.1 The pirate-loader application has no trouble talking to the bootloader when using the '$' command in v6.1.
I just tried this and can confirm what link87 is reporting. When I give the $ command, it looks like the bootloader is entered:
HiZ>$
Are you sure? y
BOOTLOADER
But when I quit my terminal emulator and start the pirate loader, it doesn't work:
$ ./pirate-loader_lnx --dev=/dev/serial/pirate --hello
+++++++++++++++++++++++++++++++++++++++++++
Pirate-Loader for BP with Bootloader v4+
Loader version: 1.0.2 OS: Linux
+++++++++++++++++++++++++++++++++++++++++++
Opening serial device /dev/serial/pirate...OK
Configuring serial port settings...OK
Sending Hello to the Bootloader...ERROR
No reply from the bootloader, or invalid reply received: 0
Please make sure that PGND and PGC are connected, replug the devide and try again
The pirate does stop showing the regular prompt on the serial port (I need to unplug and replug the pirate to get it back), so the $ command at least does _something_.
I found the line and change that causes the $ command to fail, see http://code.google.com/p/dangerous-prot ... il?id=5#c1 (http://code.google.com/p/dangerous-prototypes-open-hardware/issues/detail?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?
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.
[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:
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?
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...
[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:
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.
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 (http://http://tapatalk.com/m?id=1)
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 (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.
'$' no longer causes bus pirate to reset to bootloader. Is there a fix for this
[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).
Can someone post a link for the latest source files
[quote author="Samual"]Can someone post a link for the latest source files[/quote]
All in our wiki: http://dangerousprototypes.com/docs/Bus_Pirate#Source (http://dangerousprototypes.com/docs/Bus_Pirate#Source)
Can you make a zip file. The one on google code is old and I don't want to install a svn client
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 (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 (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 (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