buspirate / bus_pirate Goto Github PK
View Code? Open in Web Editor NEWThis project forked from dangerousprototypes/bus_pirate
Community driven firmware and hardware for Bus Pirate version 3 and 4
This project forked from dangerousprototypes/bus_pirate
Community driven firmware and hardware for Bus Pirate version 3 and 4
I have been trying to update the boot loaderwith this file, but the ds30 updoader says I will overwrite the bootloader on my bus pirate.
What's more, when I try to proceed, it just says that it has nothing to do. How can I fix these errors?
I removed support for Bus Pirate v1A with e0f0d3b, which was for a device that is almost six years old now. I don't know how many Bus Pirate v2 users are out there, and therefore whether to remove support for it or not.
This question should probably be read as "Should we focus only on V3 and V4?", though. I personally only have one v4 unit and when performing cleanups or changes I cannot validate anything involving v3 devices. If somebody has such a thing and is willing to help out in testing, then please speak up...
Migrated from #10, original description follows:
What does this warning mean? I am trying to build a firmware from the latest revision of this repository. It builds successfully with the changes I have shared through my pull requests. However:
- it tells me this warning - regardless on what optimization level I use
- if I ignore a warning and upload this firmware to my BPv4:
HiZ>~
Disconnect any devices
Connect (ADC to +3.3V)
Space to continue <--- it freezes here!My build environment: Ubuntu Linux 16.04.1 x64, MPLAB X v3.40 and MPLAB XC v1.26 compiler with PRO mode enabled (60 days free evaluation license, so that I could enable "3" level optimization for speed) When I build a BPv4 bootloader it does not give me this warning, boots flawlessly and feels to be more stable than previous (you could download it here)
I suspect this problem is because of incorrect linker settings or caused by configuration of a linker script, some functions code is overlapping, but still could not figure out what stuff exactly is overlapping!!
From the report on #7:
Seems that DIO does not work.
Bus Pirate v3.5 Community Firmware v7.0 - goo.gl/gCzQnW [HiZ 1-WIRE UART I2C SPI 2WIRE 3WIRE DIO] Bootloader v4.4 DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8) http://dangerousprototypes.com HiZ>m 1. HiZ 2. 1-WIRE 3. UART 4. I2C 5. SPI 6. 2WIRE 7. 3WIRE 8. DIO x. exit(without change) (1)>8 ERROR: command has no effect here Clutch disengaged!!! To finish setup, start up the power supplies with command 'W' Ready Syntax error at char 2 DIO>
When I define BP_ENABLE_PIC_SUPPORT and/or BP_ENABLE_PC_AT_KEYBOARD_SUPPORT, I get many messages like BPMSG1237 undeclared (first use in this function)
. This happens because messages_v4.h/messages_v4.s have more messages than messages_v3.h/messages_v3.s
I tried replacing v3 message files with v4 to add the missing messages. However there are new errors:
build/BusPirate_v3/production/_ext/1472/openocd_asm.o(.text+0x1e): In function `.L0�':
: Link Error: Cannot access symbol (_UART1RXRecvd) with file register addressing.
Value must be less than 8192. Suggest large-data model.
build/BusPirate_v3/production/_ext/1472/openocd_asm.o(.text+0x60): In function `.L0�':
: Link Error: Cannot access symbol (_UART1TXAvailable) with file register addressing.
Value must be less than 8192. Suggest large-data model.
build/BusPirate_v3/production/_ext/1472/openocd_asm.o(.text+0x68): In function `.L0�':
: Link Error: Cannot access symbol (_UART1TXAvailable) with file register addressing.
Value must be less than 8192. Suggest large-data model.
build/BusPirate_v3/production/_ext/1472/openocd_asm.o(.text+0x6c): In function `.L0�':
: Link Error: Cannot access symbol (_UART1TXBuf) with file register addressing.
Value must be less than 8192. Suggest large-data model.
make[2]: *** [dist/BusPirate_v3/production/busPirate.X.production.hex] Error 255
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2
As mentioned in #7 (comment) - the Bus Pirate can, in theory, have more than just the four SPI speeds it supports at the moment. This task is supposed to track development for such a thing.
From http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=8546 mentioned in #7:
hello,
i have a big problem using i2c whit the buspirate.
it seems there is a long delay after a start condition and any ACK/NACK.
IT IS ALMOST 2mS long.
and it is getting even longer when the baud rate of the buspirate is set to a lower rate.
normal i2c devises do not seem to care, sofar i could test it.
but i am trying to talk whit a smbus device, and that one does not like those long timeouts.
As mentioned in #19, the string packer tool right now brings everything in, regardless of the configuration settings being chosen. Something smarter would be to update the string packer to read a series of flags from the command line and selectively include/exclude strings from being merged in the .s file and referenced in the .h. A quick and dirty approach for this would be to include the #defines in the .txt and let them pass through in the generated .h/.s files.
Hello there.
I'm trying to compile the firmware from source since my BP v4 came without the UART mode.
I'm using xc16 version 1.33 with MPLAB v4.05 . When I try to build & Clean (like it says on dangerous prototypes documentation) the following is shown on display:
CLEAN SUCCESSFUL (total time: 58ms)
.
.
.
"/opt/microchip/xc16/v1.33/bin/xc16-gcc" ../dp_usb/cdc.c -o build/BusPirate_v4/production/_ext/1241334144/cdc.o -c -mcpu=24FJ256GB106 -MMD -MF "build/BusPirate_v4/production/_ext/1241334144/cdc.o.d" -g -omf=elf -DXPRJ_BusPirate_v4=BusPirate_v4 -no-legacy-libc -mlarge-code -mlarge-data -O0 -I"../../microchip/include" -I".." -mcci -msmart-io=1 -Werror -Wall -msfr-warn=off -finline -save-temps -finline
nbproject/Makefile-BusPirate_v4.mk:337: recipe for target 'build/BusPirate_v4/production/_ext/1472/base.o' failed
../base.c:42:9: error: unknown configuration setting: 'COE'
make[2]: *** [build/BusPirate_v4/production/_ext/1472/base.o] Error 255
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory ''
nbproject/Makefile-BusPirate_v4.mk:90: recipe for target '.build-conf' failed
make[1]: Leaving directory ''
nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2
BUILD FAILED (exit value 2, total time: 3s)
Hi guys.
Now something a bit hard that I know nothing if it is possible to do or not.
Something that would be an enhancement.
Perhaps this is not the right place to put it, however here is what it is.
Into the dangerousprototypes forum at this link it started a discussion about possible improvements for the Logic Analyzer side of the Bus Pirate (http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=6210&view=unread#p56802).
In the course of that discussion it was provided a working solution with these features:
a) sampling rates up to 16 MHz
b) additional samples when using fewer channels (up to 32k for 1 channel)
c) trigger location anywhere in the buffer
d) backward compatible with previous Logic Analyzer modes
Known Limitations:
-Selecting a trigger position of 100% will set the position at 0%. Workaround is to use 99% instead.
-Due to quirks at 4 and 8 MHz sampling, there is jitter in the samples but the long term rate is exact.
For example, 4 MHz samples should be every 250 nanoseconds, but it is actually between 187 nanoseconds
and 375 nanoseconds between samples.
-If compiled without optimization, 1 MHz sample timing is off prior to the trigger.
Possible Future Improvements:
-Allow selection of channel(s) to be recorded at higher sample sizes
Enhanced Logic Analyzer (latest).zip
All the improvements are into the SUMP.c that is inside the released package of this Enhanced Logic Analyzer release which has too the hexadecimal compiled with option 1 ready to use, the ols.profile-buspirate-enhanced.cfg file to put into the analyzer client and some instructions on how use the thing.
I wonder if could be possible to merge the content of the SUMP.c of the Enhanced Logic Analyzer into the one inside the current repository so that new features are available.
I know nothing but I understand this must to be very hard to reach.
Thanks.
Hi guys.
Is there somebody here who know the differences between SOFTWARE and HARDWARE mode in I2C protocol?
I thought the only one was about how synchronization is generated for the bus, but I am not sure it is just that.
In fact in the recent past thanks to agatti it was possible to free the HARDWARE mode for the I2C protocol also with Bus Pirate v3 (#39) but although in my device I have a silicon revision B8 (DEVID:0x0447 REVID:0x3046 = 24FJ64GA002 B8) I noticed a weird behavior.
The weird thing is that while doing thing on a I2C serial EEPROM via HARDWARE mode I can hit the chip only the first time, performing new access the answers are always wrong (0xFF).
So, for example, while performing read of data from a given block of memory I get them right only the first time because by repeating the command I get wrong data as 0xFF.
Take a look at this:
Bus Pirate v3.5
Community Firmware v7.1 - goo.gl/gCzQnW [HiZ 1-WIRE UART I2C SPI 2WIRE 3WIRE KEYB LCD PIC DIO] Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA00 2 B8)
http://dangerousprototypes.com
HiZ>m
(1)>4
I2C mode:
(1)>2
Set speed:
In order to fix I have to reset the Bus Pirate with command "#" and setting again all the I2C parameters.
Though 'Macro (1)' always works also by repeating it.
Despite the second and subsequent times it does not work while reading, it does while writing although on the terminal is showing wrong characters (0xFF).
Take a look at this:
I2C>[0xA0 0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15]%:20[0xA0 16 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31]%:20[0xA0 32 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47]%:20[0xA0 48 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63]%:20
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x00 ACK
WRITE: 0x00 ACK
WRITE: 0x01 ACK
WRITE: 0x02 ACK
WRITE: 0x03 ACK
WRITE: 0x04 ACK
WRITE: 0x05 ACK
WRITE: 0x06 ACK
WRITE: 0x07 ACK
WRITE: 0x08 ACK
WRITE: 0x09 ACK
WRITE: 0x0A ACK
WRITE: 0x0B ACK
WRITE: 0x0C ACK
WRITE: 0x0D ACK
WRITE: 0x0E ACK
WRITE: 0x0F ACK
I2C STOP BIT
DELAY 20ms
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x10 ACK
WRITE: 0x10 ACK
WRITE: 0x11 ACK
WRITE: 0x12 ACK
WRITE: 0x13 ACK
WRITE: 0x14 ACK
WRITE: 0x15 ACK
WRITE: 0x16 ACK
WRITE: 0x17 ACK
WRITE: 0x18 ACK
WRITE: 0x19 ACK
WRITE: 0x1A ACK
WRITE: 0x1B ACK
WRITE: 0x1C ACK
WRITE: 0x1D ACK
WRITE: 0x1E ACK
WRITE: 0x1F ACK
I2C STOP BIT
DELAY 20ms
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x20 ACK
WRITE: 0x20 ACK
WRITE: 0x21 ACK
WRITE: 0x22 ACK
WRITE: 0x23 ACK
WRITE: 0x24 ACK
WRITE: 0x25 ACK
WRITE: 0x26 ACK
WRITE: 0x27 ACK
WRITE: 0x28 ACK
WRITE: 0x29 ACK
WRITE: 0x2A ACK
WRITE: 0x2B ACK
WRITE: 0x2C ACK
WRITE: 0x2D ACK
WRITE: 0x2E ACK
WRITE: 0x2F ACK
I2C STOP BIT
DELAY 20ms
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x30 ACK
WRITE: 0x30 ACK
WRITE: 0x31 ACK
WRITE: 0x32 ACK
WRITE: 0x33 ACK
WRITE: 0x34 ACK
WRITE: 0x35 ACK
WRITE: 0x36 ACK
WRITE: 0x37 ACK
WRITE: 0x38 ACK
WRITE: 0x39 ACK
WRITE: 0x3A ACK
WRITE: 0x3B ACK
WRITE: 0x3C ACK
WRITE: 0x3D ACK
WRITE: 0x3E ACK
WRITE: 0x3F ACK
I2C STOP BIT
DELAY 20ms
I2C>[0xA0 0][0xA1 r:256][0xA2 0][0xA3 r:256][0xA4 0][0xA5 r:256][0xA6 0][0xA7 r:256][0xA8 0][0xA9 r:256][0xAA 0][171 r:256][0xAC 0][0xAD r:256][0xAE 0][0xAF r:256]
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x00 ACK
I2C STOP BIT
I2C START BIT
WRITE: 0xA1 ACK
READ: 0x00 ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF
NACK
Instead by using SOFTWARE mode I have not any problem performing all the commands I want without getting wrong answers.
I know that due the different PIC used the Bus Pirate v4 has always had the HARDWARE mode unlocked as opposed to v3, which also depends on the silicon revision (http://ww1.microchip.com/downloads/en/D ... 00470j.pdf).
Is there someone who owns the v4 and can confirm that it is the intended behavior?
Otherwise it is very likely to be a bug.
Thanks!
Right now, BPv4's bootloader will hang after checking the state/version via pirate-loader --hello
, and the only way to recover from that situation is to either power cycle the board or press the reset button on the board itself.
A script-driven approach has been tried here: http://www.willdonnelly.net/blog/bus-pirate-serial-wire/ . Something worthwhile would be to reimplement this natively without the need for bit-banging data lines.
Right now there are two separate pirate-loader codebases, one for each model. Ideally there should be only one tool to be used for uploading both firmware types.
Seems like that ds30 gui is the only option for updating bootloaders but there are three issues that need to be addressed:
The plan here is to find a cross-platform alternative for flashing bootloaders that's not MPLAB-X IPE with a PicKit adapter.
Really hoping someone can help, I am able to sniff in console mode and send and receive commands no problem with binary mode and the python scripts, but how do I go about reading the sniffed output in python ??
I know that 0x0f (15) calls the sniffer mode, but how can I read (and subsequently decode & format) the returned data packets ?
def sniff():
i2c.port.write(b"\x0F")
while True:
print(i2c.response())
I tried the above but it only outputs loads of lines of a single zero, followed by carriage return ?
Okay, so I'm having issues with flashing my BP3. Of course, the PGC/PGD trick works, but I'm trying to do this automated from with an app. The pirate-loader does the following in "fixJumps" sets the jump address to 0xa800, which is the beginning address of the DS30 bootloader. However, the DS30 bootloader sets a vector at 0xabf8 (the last 8 bytes of program memory).
Which should be used?
As an aside, I can't compile the DS30 loader to save my life. The linker does not want to put 6 bytes at 0xabf8.... I'm currently using ASM30 (v3_31), can not tell the linker version.... :<
Finally, the pirate-loader fails on all the 7.00 fw, it appears to be about the last page erase.
Want all these as separate issues????
Might be an issue with the bootloader after upgrading to v7+ (it could be just me though, I was really hacking on mine early on in the fork)
HiZ>$
Are you sure? y
BOOTLOADER
(1)> <disconnect> <reconnect>
HiZ>
Now that Microchip made available its full-featured USB stack available under a compatible licence for inclusion in Bus Pirate's code, it's time to get things up to date on that front.
As mentioned by @andersm in #37 the code is available at https://github.com/MicrochipTech/mla_usb - which makes it sort of suitable for adding the code as a git submodule to make things easier to handle.
Since Signal11's M-Stack USB library is also available under the same licence as Microchip's, if the new USB stack proves to take up too much space or creates unnecessary issues during integration things can be moved over to that one if needed.
What is the status of the firmware for the Bus Pirate v3b (the sparkfun model)? Does the newest version load into the chip, and am I missing any features? Running i lists version 5.10 and these modes:
uart.c line ~524:
uint32_t uart_get_baud_rate(const bool quiet) {
size_t samples;
uint32_t current_sample;
uint32_t bit_sample;
BP_MISO = LOW;
bit_sample is not initialized.
Warning at compilation:
../uart.c: In function 'uart_run_macro':
../uart.c:524:12: warning: 'bit_sample' may be used uninitialized in this function
Used at line 658:
if ((samples > 0) && ((bit_sample == 0) || (bit_sample > current_sample))) {
bit_sample = current_sample;
}
A more precise way to perform delays should be implemented as this might mess with timing-sensitive protocols such as 1-Wire. Unfortunately I bricked my v4 and I'm away for a week so I can't really work on this at the moment, but before the bricking I made 1-Wire work more reliably by changing the amount of time being waited, and my logic analyser all of a sudden would detect the protocol state changes.
Something that on paper should be more accurate would be this (assuming the number of milliseconds is in W0 and that it's running on a v4 board, which means it can execute 16 instructions each microsecond):
sub #1, w0 /* 1 / 16 */ /* Compensate for first batch of NOPs */
nop /* 2 / 16 */
nop /* 3 / 16 */
nop /* 4 / 16 */
nop /* 5 / 16 */
nop /* 6 / 16 */
nop /* 7 / 16 */
nop /* 8 / 16 */
nop /* 9 / 16 */
nop /* 10 / 16 */
nop /* 11 / 16 */
nop /* 12 / 16 */
nop /* 13 / 16 */
nop /* 14 / 16 */
nop /* 15 / 16 */
nop /* 16 / 16 */
.loop:
nop /* 1 / 16 */
nop /* 2 / 16 */
nop /* 3 / 16 */
nop /* 4 / 16 */
nop /* 5 / 16 */
nop /* 6 / 16 */
nop /* 7 / 16 */
nop /* 8 / 16 */
nop /* 9 / 16 */
nop /* 10 / 16 */
nop /* 11 / 16 */
nop /* 12 / 16 */
nop /* 13 / 16 */
sub #1, w0 /* 14 / 16 */
bra z, .end /* 15 / 16 */
bra .loop /* 16 / 16 */
.end:
nop /* 16 / 16 */ /* Align to 16 cycles for when W0 is 0 */
However I can't really try this out at the moment, if somebody with a logic analyser or a PIC simulator or a PicKit and a spare board wants to get wild with this, that'd be awesome!
Now that the firmware can build for v3, it would be nice to know whether it actually works or not. Unfortunately I only have a v4 board here...
Would it be possible, to make (all, even older) firmware versions available via fwupd? This way, we Linux users could update/downgrade firmware VERY easily and comfortable! :D
I was looking for feature in BPv3 hardware that enable one to configure AUX pin as an H->L or L->H interrupt i/p pin and use that modify the binary bit bang protocol to generate an protocol EVENT on the interrupt arrival. This will help in scripting several h/w devices. An exact same feature was already asked in
0x90/the-bus-pirate#5
Is this feature very difficult to implement, extending the binary bit bang protocol of BP.
Thanks in Advance
To automate testing, something useful would be an Arduino sketch that would exercise the protocols support on the Bus Pirate board. The only drawback would be having to plug and unplug cables from the Bus Pirate to the breadboard where the Arduino is placed, but that isn't supposed to be done every time after all.
I am sorry to keep annoy but while compiling for Bus Pirate v3 using the current November 07, 2017 repository still I have same problems as I wrote here:
Plus a dangerousprototypes' forum user noticed that some message into SPI protocol are wrong:
http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498&p=67167#p67164
In detail the thing is that by performing some commands while in SPI mode then the Bus Pirate v3 use wrong messages on the terminal:
SPI>[0x9f r r r]
/CS ENABLED
WRITE: 0x9F
READ: 0xC2
READ: 0x20
READ: 0x14
\CS ENABLED
SPI>
It is only a cosmetic issue because actually, despite the wrong message, everything works as expected, but it is really annoying
For what I know the problem started with repositories dated after the April 10, 2017 because some custom firmware I build starting from that repository and I released on the dangerousprototypes' forum do not have it:
http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498&p=67167#p67167
Thanks.
Hello, I need a JTAG programmer, and I want to know if I could use the buspirate in this case or I have to get a programmer
I am struggling to understand bulk_trans, I thought that I could use it to read multiple bytes by repeatdly calling read_byte() in a loop but it only returns the first 3 values and then repeats the 3rd value and does not appear to read any more.
Would appreciate if anyone can help with this ?
def get_bytes():
i2c.send_start_bit()
i2c.bulk_trans(2, [0x16, 0x19]) ## WR ADDRESS
i2c.send_stop_bit()
out = []
i2c.send_start_bit()
i2c.bulk_trans(1, [0x17]) ## RD ADDRESS
data_len = 20
while(data_len):
out.append(ord(i2c.read_byte()))
if data_len > 1:
i2c.send_ack()
data_len-=1
i2c.send_nack()
i2c.send_stop_bit()
print(out)
The output is:
[232, 28, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11]
But I know for sure that the value 11 is not the actual value in 17 consecutive addresses !
Maybe migrating the USB stack from the hacked up version that is currently running (and has not been updated in a few years now) to something a tad more modern and still supported could be beneficial to the project.
M-Stack is a GPL/Apache2 licensed USB stack for PIC microcontrollers that allows for a whole lot of options, and more importantly it is being currently maintained. It is available at http://www.signal11.us/oss/m-stack/ (or https://github.com/signal11/m-stack for the source code).
Dangerous Prototypes' original firmware did not use hardware I2C due to hardware bugs in PIC24FJ64GA004 chips with revision A3 or A4.
Now that hardware I2C is enabled again and the appropriate workarounds detailed here have been applied, we need to test those on real hardware.
The catch: the code is experimental and it may or may not mess up with your hardware, just in case.
To test it, find out if your board is running one of those chips by using the i
command, and if so make sure that BP_I2C_USE_HW_BUS
is defined for Bus Pirate v3 in your copy of configuration.h, rebuild, and stress test I2C read/write/etc capabilities on the board.
Deprecate DS30's bootloader and use something that follows Microchip's AN1157 application note allowing for potentially better integration with fwupd and interoperability with existing PIC flashing programs.
Right now lots of small bits and pieces inside Firmware/scripts
are accumulating bit rot, and possibly do not work any longer. It's time to rescue what can be saved, give it a new coat of paint, and get rid of the rest.
I brought this up over on the forum, but not much came from it (no ones fault). Perhaps we could start taking the completed builds that @USBEprom puts up on the forum, and start placing them under the releases function within github. This would allow for people to quickly see all of the newest releases, instead of having to dig through the forum posts.
The main issue with this is that @USBEprom is not sure how this is done on github (totally understandable), so doing this would require some collaboration between him and someone with more github experience.
The binary protocol hasn't changed with the introduction of the BPv4, which is just fine but it means that the two extra AUX pins cannot be controlled or interacted with via said protocol.
Changing this would mean bump up the revision on the protocol identifier (when there is one) and add/modify commands in a slightly more sensible way than the organically-grown set that is currently available.
As usual, there are some pros and cons to consider:
Pros:
Cons:
This is not set to any milestone as I guess it'll take a bit of time to reach a consensus on how this should be carried out, as at the moment there is no clear way forward.
Right now we've got BusPirate/Bus_Pirate, BusPirate/hardware, and BusPirate/bp-cases. Maybe a bit more consistency won't hurt in the long run, so I guess we should migrate to one single repo naming scheme. Any ideas on that?
Would it make sense to move the hardware schematics, gerber files, and CAD models to another repository? There is plenty of stuff in there that is of limited usage for whoever wants to grab an updated firmware, after all.
OpenJTAG support is currently only enabled for v3. There were some earlier attempts at porting said code to v4 but nothing stable ever came out of it, as far as I know.
From the report in #7:
MACRO(1) and MACRO(2) in 2WIRE protocol they do not work.
For what I can understand MACRO(1) fails due a wrong order in the lsb/MSB of the emitted bytes.
Also MACRO(2) fails but I do not know why, perhaps for the same reason of MACRO(1).
Hello,
I just loaded the latest firmware today (commit id: feb479a) and when I open up the terminal I am getting mostly garbage characters returned from a BPv4.
I am running the screen terminal emulator on Mac OSX El Capitan.
Any idea what might be causing this? Rolling back to the 7.0 release seems to make everything happy again.
Thanks,
Ryan
I have just built a firmware for the BP3 by compiling from the current repository (February 4, 2017) with MBLAB 3.50 - XC16 1.30 putting flag only on "Do not override 'inline'" leaving the rest of its settings empty or disabled.
For Bus Pirate revision 3 optimizations 0, 2 and 3 are run out of space, the only valid ones are 1 and s, so i built by using them.
This report is about firmware optimized option 1.
My configuration.h is this:
configuration.h.TXT
(Pay attention at the fact that "github" does not allow me to attach configuration.h, not even by compressing it as zip, so I had to change its extension as txt.)
As check I began to test the SPI protocol trying to retrieve the JEDEC of different SPI chips discovering that the SPI protocol no longer works.
On all speed always I get wrong JEDEC on the terminal while actually it is totally correct on the bus as I verified by using a logic analyzer.
So timing and data exchange on the bus are always correct while the reads printed on the terminal are always wrong.
I have tried many chips and speeds but the result is always the same, SPI protocol does not work anymore in this latest firmware where the patch #23 is applied.
As countercheck I have repeated the same tests with a firmware built by compiling the repository issued immediately before the application of the patch #23 and everything works perfectly as supposed.
For what I know the only differences between the firmware that does work and the one that does not are:
The functioning firmware has not the patch #23
The functioning firmware has not the workarounds in order to unlock hardware I2C protocol
Here is the log of the terminal:
TERMINAL LOG.txt
(Note that it is not a terminal problem because I have tried different ones and the result is always the same, it does not matter the terminal program used, JEDEC is always wrong)
While here is a shot taken with the logic analyzer
I must add that in addition to the SPI memory chips the new firmware fails also with MMCs on SPI bus:
https://nada-labs.net/2010/using-the-buspirate-with-a-sd-card/
As reference, seems that with firmwares built starting from repository dated July 16, 2017 and July 20, 2017, then is not possible to gain BOOTLOADER by issuing command "$".
By doing it then Bus Pirate v3 has a reset but it does not enter into the BOOTLOADER mode.
Firmwares built using option '1' and option 's'.
Work had been started to migrate protocol usage documentation from Dangerous Prototypes' wiki to a set of markdown pages to be put in the repo, there are a few more to be migrated.
First to explain the facts I have to make a premise.
I know nothing if this is the right place neither the contents are pertinent, since actually what I will describe is not directly related with the firmware for the Bus Pirate or its developing.
My purpose is not even to solve the matter, the only goal is to report the thing as reference for all.
So said, in order to investigate the weird behavior in the I2C protocol while using HARDWARE mode (#54 and http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=8760), I tried to use I2CEEPROMWIN whose its source code is inside the Bus_Pirate-master.zip archive at the path \Bus_Pirate-master\scripts, where exactly there is the C source named I2CEEPROMWIN.c (https://github.com/BusPirate/Bus_Pirate/blob/master/scripts/I2CEEPROMWIN.c and https://github.com/mkschreder/the-bus-pirate/blob/master/scripts/I2CEEPROMWIN.c) from which I built the executable for Windows.
Seems to me I2CEEPROMWIN.exe does not work as expected since always it fails while reading the starting address simply by omitting him and shifting up all the bytes towards the high putting in the end a dummy 0x00 value.
(Follow-up to http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=8763)
Here is an example.
This is the real content of the chip:
0x01 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x1F
0x02 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x2F
0x03 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x3F
0x04 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x4F
and this is what I2CEEPROMWIN.exe actually read:
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x1F 0x02
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x2F 0x03
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x3F 0x04
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x4F 0x00
Also seems to me I2CEEPROMWIN.exe does not work while writing because although no alarm is displayed and indeed in the end it is stated that everything is successfully done, actually the content of the chip has not been changed in any way.
From the source (I2CEEPROMWIN.c) the syntax is this:
pc_serial [com?] [chip addr 0-8] [R/W] [file] (read len) (mem addr)
That it is not clear as it states that the address must be 2 bytes, while actually using
I2CEEPROMWIN.exe com3 0 R TEST 2048 0000
I2CEEPROMWIN.exe com3 0 W TEST 2048 0000
or
I2CEEPROMWIN.exe com3 0 R TEST 2048 00
I2CEEPROMWIN.exe com3 0 W TEST 2048 00
it does not make any difference for the result.
More, [chip addr 0-8] seems to make no sense because available blocks should be from 0 to 7, not from 0 to 8.
In fact 24xx64 has a memory capacity of 8 contiguous blocks (0-7) and data bus allow for only 8 chip (0-7) for contiguous addressing across multiple devices.
That is really weird at me.
Maybe the fault is due the syntax I use that is wrong, maybe it does not work anyway.
I think that I2CEEPROMWIN can be useful for debug simplifying it through the automation of test procedures, for instance by writing and reading of massive amount of data.
In order to deeper the matter I wrote at the beginning of this message I needed to make the chip content unequivocally so that it was easy to detect anomalies.
I2CEEPROMWIN would be a great choice but instead I had to fold on BusPirate_Control and scripting in order to reach the goal.
Hi guys, sorry for disturbing.
As mere curiosity, wanting to set a different customized default baud rate for the terminal how is it supposed to do it?
Normally the default baud rate for the Bus Pirate is set at 115200bps to communicate via terminal.
Now, if for instance wanting to set it to 2000000bps, what should be done to achieve the goal?
I have tried to build a custom firmware that has 2000000bps as default speed for the terminal, sadly without success though.
I have seen that the necessary parameters are inside source code in line 171 of main.c and line 247 of base_io.c, so I changed the latter as follow:
247 1 /* 2000000 bps */
I do not care that labels into the menu of the Bus Pirate are consistent (it would be better if they were but right now I can wait for that), only that the Bus Pirate starting itself at 2000000bps as default setting instead of the usual 115200bps, but my edit does not work.
The firmware is compiled correctly but then it is not possible to communicate with the Pirate Bus through the terminal even though the COM port is recognized right.
Luckily enough it was possible to put the right firmware by tying PGD and PGC on the Bus Pirate!
Any hint?
Thanks in advance!
As stated. I'm intending to grab a flyswatter2 from tincan tools as a more 'proper'
jtag interface for u-boot development, but wish to at least test I've got the right pinout.
I wished to update my firmware to support openocd/jtag, and cloned the repo, and
attempted to flash via
./BPv3-firmware/pyrate-loader_lnx --dev=/dev/ttyUSB0 --hex=bootloader/BPv3-Bootloader-v4.4.hex
It all goes well until it hits here: Erasing page 42, a800...ERROR [50]
As it currently stands my bus pirate is unusable. Tips for recovery/getting this done?
What does this warning mean? I am trying to build a firmware from the latest revision of this repository. It builds successfully with the changes I have shared through my pull requests. However:
HiZ>~
Disconnect any devices
Connect (ADC to +3.3V)
Space to continue <--- it freezes here!
My build environment: Ubuntu Linux 16.04.1 x64, MPLAB X v3.40 and MPLAB XC v1.26 compiler with PRO mode enabled (60 days free evaluation license, so that I could enable "3" level optimization for speed) When I build a BPv4 bootloader it does not give me this warning, boots flawlessly and feels to be more stable than previous (you could download it here)
I suspect this problem is because of incorrect linker settings or caused by configuration of a linker script, some functions code is overlapping, but still could not figure out what stuff exactly is overlapping!!
Memory regions - beginning part of p24FJ256GB106.gld linker script:
MEMORY
{
data (a!xr) : ORIGIN = 0x800, LENGTH = 0x4000
reset : ORIGIN = 0x0, LENGTH = 0x4
ivt : ORIGIN = 0x4, LENGTH = 0xFC
aivt : ORIGIN = 0x104, LENGTH = 0xFC
program (xr) : ORIGIN = 0x2000, LENGTH = 0x289F8
config4 : ORIGIN = 0x2ABF8, LENGTH = 0x2
config3 : ORIGIN = 0x2ABFA, LENGTH = 0x2
config2 : ORIGIN = 0x2ABFC, LENGTH = 0x2
config1 : ORIGIN = 0x2ABFE, LENGTH = 0x2
}
__CONFIG3 = 0x2ABFA;
__CONFIG2 = 0x2ABFC;
__CONFIG1 = 0x2ABFE;
__IVT_BASE = 0x4;
__AIVT_BASE = 0x104;
__DATA_BASE = 0x800;
__CODE_BASE = 0x200;
... ... ...
Below is a memory map info that I receive in the end of build process:
(seems normal on the first glance, but maybe it conflicts with a linker script?)
xc16-ld 1.26 (A)
Program Memory [Origin = 0x2000, Length = 0x289f8]
section address length (PC units) length (bytes) (dec)
------- ------- ----------------- --------------------
.text 0x2000 0x8a2 0xcf3 (3315)
.const 0x28a2 0x5de 0x8cd (2253)
.text 0x2e80 0x13914 0x1d59e (120222)
.dinit 0x16794 0x280 0x3c0 (960)
.text 0x16a14 0x7f6 0xbf1 (3057)
.isr 0x1720a 0x4 0x6 (6)
.shared.dinit 0x1720e 0x2 0x3 (3)
Total program memory used (bytes): 0x1fb18 (129816) 52%
Ivt Memory [Origin = 0x4, Length = 0xfc]
section address length (PC units) length (bytes) (dec)
------- ------- ----------------- --------------------
.ivt 0x4 0xfc 0x17a (378)
Aivt Memory [Origin = 0x104, Length = 0xfc]
section address length (PC units) length (bytes) (dec)
------- ------- ----------------- --------------------
.aivt 0x104 0xfc 0x17a (378)
Data Memory [Origin = 0x800, Length = 0x4000]
section address alignment gaps total length (dec)
------- ------- -------------- -------------------
.bss 0x800 0 0x1004 (4100)
.bss.end 0x1804 0 0x1000 (4096)
.bss 0x2804 0 0x468 (1128)
.data 0x2c6c 0 0x210 (528)
usb_data3 0x2e7c 0 0x100 (256)
.bss 0x2f7c 0 0x76 (118)
.data 0x2ff2 0 0xe (14)
usb_bdt 0x3000 0 0x200 (512)
.bss 0x3200 0 0x1a8 (424)
.bss 0x33a8 0 0x62 (98)
.data 0x340a 0 0x76 (118)
.bss 0x3480 0 0x7a (122)
.bss 0x34fa 0 0xa (10)
usb_data 0x3504 0 0xa (10)
.bss 0x350e 0 0x30 (48)
.data 0x353e 0 0x4 (4)
.bss 0x3542 0 0x6 (6)
Total data memory used (bytes): 0x2d48 (11592) 70%
Dynamic Memory Usage
region address maximum length (dec)
------ ------- ---------------------
heap 0 0 (0)
stack 0x3548 0x12b8 (4792)
Maximum dynamic memory (bytes): 0x12b8 (4792)
I have just built a firmware for the BP3 by compiling from the current repository (February 4, 2017) with MBLAB 3.50 - XC16 1.30 putting flag only on "Do not override 'inline'" leaving the rest of its settings empty or disabled.
For Bus Pirate revision 3 optimizations 0, 2 and 3 are run out of space, the only valid ones are 1 and s, so i built by using them.
This report is about firmware optimized option 1.
My configuration.h is this:
configuration.h.TXT
(Pay attention at the fact that "github" does not allow me to attach configuration.h, not even by compressing it as zip, so I had to change its extension as txt.)
As check I began to test the 2WIRE protocol trying to retrieve the ATR of a SLE4442 chip card discovering that the 2WIRE protocol no longer works.
Always I get wrong ATR both by performing macros and by inserting directly the commands.
As countercheck I have repeated the same tests with a firmware created by compiling the repository issued immediately before the application of the patch #23 and everything works perfectly as supposed.
For what I know the only differences between the firmware that does work and the one that does not are:
The functioning firmware has not the patch #23
The functioning firmware has not the workarounds in order to unlock hardware I2C protocol
Here is the log of the terminal:
TERMINAL LOG.txt
(Note that it is not a terminal problem because I have tried different ones and the result is always the same, it does not matter the terminal program used, ATR is always wrong)
The real and right ATR actually it is the usual 0xA2 0x13 0x10 0x91 of that kind of cards, while this latest firmware always reads 0xAA 0x11 0x11 0x99 which is totally wrong.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.