Hi Wanhedaking. Unfortunately as things are now I guess you need to use a programmer like PICKit (http://http://dangerousprototypes.com/docs/Bus_Pirate_v4_and_Pickit2_(bootloader_and_firmware_updates)), ICD2, or something similar to that in order to rewrite the bootloader, since your Bus Pirate is no longer able to communicate with the computer. I think that even a different working Bus Pirate can be used to program the bootloader into the PIC of your bricked Bus Pirate. Anyway about the firmware the latest one is v7.1, do not v6 (http://http://dangerousprototypes.com/forum/viewtopic.php?f=28&p=65284#p65290) and the latest bootloader is the v4.5 (http://http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498&start=75). Am I pushy if I ask you if when you ran P24QP.exe did you put flag on the "Program Memory" and "Preserve Flash Configuration Words on Erase" items? P24QP.exe application (or Python script) erases the whole chip, including the 'configuration words' that determine how the PIC behaves on start-up. The v4 firmware does not contain replacement "configuration words", so the Bus Pirate will not start from the correct clock after programming a v4 firmware to a v2 bootloader with a not correctly set P24QP.exe or the Python script p24qp.py (with P24QP.PY only Upload v2 firmware or BPv3-v2blupdaterVa3-v4.1.hex):
Hi tony77. How did you performed the upgrade, with jumper between PGC and PGD or using command "$"? What is the operating system are you running while upgrading? I can suggest you to use pirate-loader.exe for the upgrade instead of DS30 loader. Please let us know.
Hi guys. While I was checking what the user Lincon wrote here in the forum about an issue that concerns the LSb/MSb setting is not honored when sending data in script mode:
I found that something is wrong with BASIC script mode because with the latest firmwares 09032019_OPT1_SAFE.hex and 09032019_OPT1_UNSAFE.hex (viewtopic.php?f=28&t=8498&start=120#p68332) based on the current repository the Bus Pirate resetting itself while running scripts, so that BASIC does not work anymore:
Hi Lincon. Thank you very much for your posting, very much appreciated! I made some tests with my Bus Pirate v3 using latest firmwares 09032019_OPT1_SAFE.hex and 09032019_OPT1_UNSAFE.hex (viewtopic.php?f=28&t=8498&start=120#p68332) built with the current repository and sadly it is like you wrote (actually I have even spotted another very severe bug that I have described as a separate issue on github), so I opened a dedicate issue on github:
In order to dig deeper the matter I would like to know more, especially about how you managed to evaluate the bit pattern sent while in script mode, hence how exactly you did set your Bus Pirate and the exact syntax you used in order to send data. I write this because in SPI mode with the syntax "[163]" I can decode the data traffic sent by the Bus Pirate over the bus using a logic analyzer and confirming what you wrote, but in BASIC mode by running the script "10 SEND 163" I can not trigger. Thanks a lot!
Hi guys. Thanks to coelner, tofurky, Rondom and andersm, agatti fixed the issue with AVRDUDE when using buspirate syntaxes (http://https://github.com/BusPirate/Bus_Pirate/issues/122) and he has released a new repository of the firmware v7.1 for the Bus Pirate (http://https://github.com/BusPirate/Bus_Pirate) so that I was able to build new firmwares v7.1 for the Bus Pirate revision 3 (http://https://github.com/BusPirate/Bus_Pirate/archive/master.zip). andersm also corrected spi.c for bytes_to_write tested twice by mistake (http://https://github.com/BusPirate/Bus_Pirate/pull/127). I made two versions that i named 09032019_OPT1_SAFE.hex and 09032019_OPT1_UNSAFE.hex. Both of them have all the features enabled, BASIC too, the command line allows up 256 characters. The first one (09032019_OPT1_SAFE.hex), the so called SAFE version (S=SAFE), is built on the configuration.h changed as follow. Into configuration.h I changed lines from 316 to 331 in order to enable all the features available, BASIC too.
Then I changed the line 425 too in this way in order to make room for BASIC scripting:
#define BP_BASIC_PROGRAM_SPACE 512
Finally I had to set line 571 for up 256 characters into the command line by changing it in this way:
/** * How big the serial command buffer can be, in bytes. * * @warning This must be set to a power of two, ie. 256, 128, 64, 32, etc. */ #ifdef BUSPIRATEV3 #define BP_COMMAND_BUFFER_SIZE 256 #else #define BP_COMMAND_BUFFER_SIZE 256 #endif /* BUSPIRATEV3 */
Delay code provided by Christopher Sam Soon to the main branch is currently enabled by default, but can be switched off by undefining BP_USE_HARDWARE_DELAY_TIMER in line 586 of configuration.h.
In order to match the real speeds now used for I2C SOFTWARE, 2-WIRE and 3-WIRE in messages_v3.s line 1457 I changed ~400kHz to ~240kHz and more in general I changed all the terms KHz, which is wrong as a unit of measure, in kHz which is the right word.
The result that I have achieved I have called it 09032019_OPT1_SAFE.hex. 09032019_OPT1_SAFE.hex was obtained by using the compression option "1" of MPLAB so to be in fully accordance with the latest recommendations issued about the compilation of the new repositories using MPLAB in order to build new firmwares for the Bus Pirate v3 and v4. Compression option "1" assure right timing that option "s" may not ensure. For me it works great. Thanks a lot to agatti for having fixed the matter by changing things into spi.c! http://https://github.com/BusPirate/Bus_Pirate/issues/122 Now AVRDUDE works again with both buspirate_bb and buspirate syntaxes. Many thanks also to andersm for correcting spi.c for bytes_to_write tested twice by mistake. http://https://github.com/BusPirate/Bus_Pirate/pull/127
The second one (09032019_OPT1_UNSAFE.hex) is the same as 09032019_OPT1_SAFE.hex but also it has the HARDWARE mode unlocked for the I2C protocol. Indeed in the past agatti taught how to free the HARDWARE mode inside I2C protocol (http://https://github.com/BusPirate/Bus_Pirate/issues/39). Please read the above link carefully! As agatti wrote: "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 (http://http://ww1.microchip.com/downloads/en/DeviceDoc/80000470j.pdf) 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." U_1-05112018.hex, the so called UNSAFE version (U=UNSAFE) is built on the configuration.h changed as follow. Into configuration.h I changed lines from 316 to 331 in order to enable all the features available, BASIC too.
Then I changed the line 425 too in this way in order to make room for BASIC scripting:
#define BP_BASIC_PROGRAM_SPACE 512
And then I had to set line 571 for up 256 characters into the command line by changing it in this way:
/** * How big the serial command buffer can be, in bytes. * * @warning This must be set to a power of two, ie. 256, 128, 64, 32, etc. */ #ifdef BUSPIRATEV3 #define BP_COMMAND_BUFFER_SIZE 256 #else #define BP_COMMAND_BUFFER_SIZE 256 #endif /* BUSPIRATEV3 */
Then I had to put a remark sign ("//") inside line 382 and 391 in order to unlock the HARDWARE mode for the I2C protocol:
382 // #ifdef BUSPIRATEV4
391 // #endif /* BUSPIRATEV4 */
Delay code provided by Christopher Sam Soon to the main branch is currently enabled by default, but can be switched off by undefining BP_USE_HARDWARE_DELAY_TIMER in line 586 of configuration.h.
And finally in order to match the real speeds now used for I2C SOFTWARE, 2-WIRE and 3-WIRE in messages_v3.s line 1457 I changed ~400kHz to ~220kHz and more in general I changed all the terms KHz, which is wrong as a unit of measure, in kHz which is the right word.
The result that I have achieved I have called it 09032019_OPT1_UNSAFE.hex. 09032019_OPT1_UNSAFE.hex was obtained by using the compression option "1" of MPLAB so to be in fully accordance with the latest recommendations issued about the compilation of the new repositories using MPLAB in order to build new firmwares for the Bus Pirate v3 and v4. Compression option "1" assure right timing that option "s" may not ensure.
For me it works great, but you use it at your own risk, I do not take any responsibility about the possibility of damaging your Bus Pirate or whatever! Thanks a lot to agatti for having fixed the matter by changing things into spi.c! http://https://github.com/BusPirate/Bus_Pirate/issues/122 Now AVRDUDE works again with both buspirate_bb and buspirate syntaxes. Many thanks also to andersm for correcting spi.c for bytes_to_write tested twice by mistake. http://https://github.com/BusPirate/Bus_Pirate/pull/127
Attention please! First to attempt to use 09032019_OPT1_UNSAFE.hex (UNSAFE version of the firmware) you have to evaluate what is the silicon revision of the PIC used in your device, paying much attention to the fact that you might damage your device or whatever! By doing it you must to assume all the responsibility for your action. You use it at your own risk, I do not take any responsibility about the possibility of damaging your Bus Pirate or whatever!
With the firmwares I also provide a pre configured environment that anyone can use with minimal changes to simplify the upgrade of the only firmware or together the bootloader and the firmware in a single step. The archive also provides further improved instructions on how to use the whole thing under any operative system (Window, Linux and Apple), simply follow them :
"How to use UPGRADE_TO_BL_v4.5.bat.rtf" (specific instructions for Windows users) "How to update with pirate-loader.rtf" (generic cross-platform instructions for Windows, Linux and Apple users)
Please note that the package is a 7z (7zip) archive because the maximum allowed size in the forum is 1 MiB.
Hi guys. Thanks to coelner, tofurky, Rondom and andersm, agatti fixed the issue with AVRDUDE when using buspirate syntaxes (http://https://github.com/BusPirate/Bus_Pirate/issues/122) and he has released a new repository of the firmware v7.1 for the Bus Pirate (http://https://github.com/BusPirate/Bus_Pirate) so that I was able to build new firmwares v7.1 for the Bus Pirate revision 3 (http://https://github.com/BusPirate/Bus_Pirate/archive/master.zip). andersm also corrected spi.c for bytes_to_write tested twice by mistake (http://https://github.com/BusPirate/Bus_Pirate/pull/127). I made two versions that i named 09032019_OPT1_SAFE.hex and 09032019_OPT1_UNSAFE.hex. Both of them have all the features enabled, BASIC too, the command line allows up 256 characters. The first one (09032019_OPT1_SAFE.hex), the so called SAFE version (S=SAFE), is built on the configuration.h changed as follow. Into configuration.h I changed lines from 316 to 331 in order to enable all the features available, BASIC too.
Then I changed the line 425 too in this way in order to make room for BASIC scripting:
#define BP_BASIC_PROGRAM_SPACE 512
Finally I had to set line 571 for up 256 characters into the command line by changing it in this way:
/** * How big the serial command buffer can be, in bytes. * * @warning This must be set to a power of two, ie. 256, 128, 64, 32, etc. */ #ifdef BUSPIRATEV3 #define BP_COMMAND_BUFFER_SIZE 256 #else #define BP_COMMAND_BUFFER_SIZE 256 #endif /* BUSPIRATEV3 */
Delay code provided by Christopher Sam Soon to the main branch is currently enabled by default, but can be switched off by undefining BP_USE_HARDWARE_DELAY_TIMER in line 586 of configuration.h.
In order to match the real speeds now used for I2C SOFTWARE, 2-WIRE and 3-WIRE in messages_v3.s line 1457 I changed ~400kHz to ~240kHz and more in general I changed all the terms KHz, which is wrong as a unit of measure, in kHz which is the right word.
The result that I have achieved I have called it 09032019_OPT1_SAFE.hex. 09032019_OPT1_SAFE.hex was obtained by using the compression option "1" of MPLAB so to be in fully accordance with the latest recommendations issued about the compilation of the new repositories using MPLAB in order to build new firmwares for the Bus Pirate v3 and v4. Compression option "1" assure right timing that option "s" may not ensure. For me it works great. Thanks a lot to agatti for having fixed the matter by changing things into spi.c! http://https://github.com/BusPirate/Bus_Pirate/issues/122 Now AVRDUDE works again with both buspirate_bb and buspirate syntaxes. Many thanks also to andersm for correcting spi.c for bytes_to_write tested twice by mistake. http://https://github.com/BusPirate/Bus_Pirate/pull/127
The second one (09032019_OPT1_UNSAFE.hex) is the same as 09032019_OPT1_SAFE.hex but also it has the HARDWARE mode unlocked for the I2C protocol. Indeed in the past agatti taught how to free the HARDWARE mode inside I2C protocol (http://https://github.com/BusPirate/Bus_Pirate/issues/39). Please read the above link carefully! As agatti wrote: "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 (http://http://ww1.microchip.com/downloads/en/DeviceDoc/80000470j.pdf) 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." U_1-05112018.hex, the so called UNSAFE version (U=UNSAFE) is built on the configuration.h changed as follow. Into configuration.h I changed lines from 316 to 331 in order to enable all the features available, BASIC too.
Then I changed the line 425 too in this way in order to make room for BASIC scripting:
#define BP_BASIC_PROGRAM_SPACE 512
And then I had to set line 571 for up 256 characters into the command line by changing it in this way:
/** * How big the serial command buffer can be, in bytes. * * @warning This must be set to a power of two, ie. 256, 128, 64, 32, etc. */ #ifdef BUSPIRATEV3 #define BP_COMMAND_BUFFER_SIZE 256 #else #define BP_COMMAND_BUFFER_SIZE 256 #endif /* BUSPIRATEV3 */
Then I had to put a remark sign ("//") inside line 382 and 391 in order to unlock the HARDWARE mode for the I2C protocol:
382 // #ifdef BUSPIRATEV4
391 // #endif /* BUSPIRATEV4 */
Delay code provided by Christopher Sam Soon to the main branch is currently enabled by default, but can be switched off by undefining BP_USE_HARDWARE_DELAY_TIMER in line 586 of configuration.h.
And finally in order to match the real speeds now used for I2C SOFTWARE, 2-WIRE and 3-WIRE in messages_v3.s line 1457 I changed ~400kHz to ~220kHz and more in general I changed all the terms KHz, which is wrong as a unit of measure, in kHz which is the right word.
The result that I have achieved I have called it 09032019_OPT1_UNSAFE.hex. 09032019_OPT1_UNSAFE.hex was obtained by using the compression option "1" of MPLAB so to be in fully accordance with the latest recommendations issued about the compilation of the new repositories using MPLAB in order to build new firmwares for the Bus Pirate v3 and v4. Compression option "1" assure right timing that option "s" may not ensure.
For me it works great, but you use it at your own risk, I do not take any responsibility about the possibility of damaging your Bus Pirate or whatever! Thanks a lot to agatti for having fixed the matter by changing things into spi.c! http://https://github.com/BusPirate/Bus_Pirate/issues/122 Now AVRDUDE works again with both buspirate_bb and buspirate syntaxes. Many thanks also to andersm for correcting spi.c for bytes_to_write tested twice by mistake. http://https://github.com/BusPirate/Bus_Pirate/pull/127
Attention please! First to attempt to use 09032019_OPT1_UNSAFE.hex (UNSAFE version of the firmware) you have to evaluate what is the silicon revision of the PIC used in your device, paying much attention to the fact that you might damage your device or whatever! By doing it you must to assume all the responsibility for your action. You use it at your own risk, I do not take any responsibility about the possibility of damaging your Bus Pirate or whatever!
With the firmwares I also provide a pre configured environment that anyone can use with minimal changes to simplify the upgrade of the only firmware or together the bootloader and the firmware in a single step. The archive also provides further improved instructions on how to use the whole thing under any operative system (Window, Linux and Apple), simply follow them :
"How to use UPGRADE_TO_BL_v4.5.bat.rtf" (specific instructions for Windows users) "How to update with pirate-loader.rtf" (generic cross-platform instructions for Windows, Linux and Apple users)
Please note that the package is a 7z (7zip) archive because the maximum allowed size in the forum is 1 MiB.
Hi LaForge. The difference betwhen PICkit 2 and PICkit 3 is that PICkit 2 do not work with newer chip products (i.e. PIC32MX, PIC32MZ, PIC18[L]FxxK22 and so on). However some of these may be programmed with PICkit 2 and its standalone programming application may be updated with modified device files to handle additional devices, but debugging is much more difficult to handle with devices not supported with debugging in MPLAB by Microchip. PICkit 2 allows itself to be use as logic analyzer and to monitor diagnostic messages when debugging complicated code, PICkit 3 too can do it but for what I know Microchip never implemented the PICkit 2 style UART mode in the PICkit 3 so it is not possible to use it in a something way like with Logic Tool and UART Tool in PICkit 2. Bitbanging SPI via HID with the PICkit 3 loaded with the PICkit 2 emulation firmware may be possible but is likely to be very slow. It would not be able to meet the timing requirements for bitbanged asynch serial at any normal baudrate. So among the two programmer there is the tiny limitation that untill now for what I know the PICkit 3 does not include UART support while using it as logic analyzer. In the case of the Bus Pirate the PIC which is welded on the device is supported by both, the PICkit 2 and the PICkit 3, so for that kind of use there is no difference in using one rather than the other.
One last thing. With the firmware v7.x flashrom is fully working, unless you have for some reason specifically need version v6.2 there is no reason to use such an old firmware.
Hi djsb. I own a Bus Pirate v3, not the v4, so I know very little about it. However for what little I know through USB should be possible to upgrade both firmware and bootloader by using pirate-loader.exe in command line fashion. The same thing can be done by using an hardware programmer like the PicKit2 or other like that. Here it is explained how to do it via USB:
Hi Coldblackice. I asked simply because I know of cases of external hard drives in which it is actually the power supply to have problems, not the mass storage unit. Good luck!
