Hello,
I just got a bus pirate a few days ago and wanted to get my hands in the firmware.
But current IDE is MPLAB8, not supported under linux.
So Ian told me to have a look to MPLABX, the release-to-come from Microchip, currently in beta but supporting amongst other OSes Linux & Mac :-)
It could be of interest also for Windows folks as MPLABX promises whistles & bells compared to MPLAB8.
See http://devupdates.microchip.com/mplab/F ... PLAB-X.pdf (http://devupdates.microchip.com/mplab/Files/Getting_Started_with_MPLAB-X.pdf)
Apparently it's a rather new topic within the bus pirate community so I'm starting this thread to share experiences & tips on that matter, to become a howto on the wiki once things will be sorted out I presume...
1) MPLABX Installation:
Visit http://devupdates.microchip.com/mplab/ (http://devupdates.microchip.com/mplab/) and get the following components for your preferred OS:
* MPLAB X IDE
* MPLAB C Compiler for dsPIC DSCs and PIC24 MCUs (Lite)
1.1) Under a Debian Squeeze 64-bit here is the command I had to execute:
$ chmod 755 mplabxidebeta32.bin mplabc30.bin
$ sudo su -
# GTK_PATH=/usr/lib32/gtk-2.0 exec ./mplabxidebeta32.bin
# GTK_PATH=/usr/lib32/gtk-2.0 exec ./mplabc30.bin
Note that I had still a couple of "wrong ELF class: ELFCLASS64" errors because some GTK components (gio modules) were not available in 32-bit libraries but it seems to not having hurt the installation.
Under a 32-bit distribution you don't need to worry about the GTK_PATH and you can simply do
$ sudo ./mplabxidebeta32.bin
$ sudo ./mplabc30.bin
Files will be installed in /opt/microchip
2) Project migration:
We'll need a bit of discipline now as Linux is case-sensitive and only Windows accepts paths with "" while all OSes accept paths with "/".
Most (all?) changes were already done yesterday thanks to Stephan (see https://code.google.com/p/the-bus-pirat ... tail?id=55 (https://code.google.com/p/the-bus-pirate/issues/detail?id=55)) so it should be ok by now (but maybe some of the child projects has still to be converted...)
To migrate the existing MPLAB8 project to MPLABX, one needs to use the included wizard:
* New project> Microchip Embedded> Existing MPLAB IDE v8> busPirate.mcp
** Device: PIC24FJ64GA002
** Select Header: AC162088
** HW tool: PICkit3
** Compiler: C30
** Keep files in place
3) Compilation:
It could compile properly the ADDONS firmware but failed on the MAIN firmware by lack of space, which is according to Ian a known problem in the current SVN, so unrelated to MPLABX.
4) HEX file:
Current wiki notes on firmware compilation mention that we need to export the firmware as Intel HEX file.
But "Export" is currently documented as known unsupported feature in MPLABX (remember, it's a beta...)
Nevertheless one can find it in the new project structure as busPirate.X/busPirate/dist/default/production/busPirate.production.hex
If I try the firmware as such with pirate-loader_lnx, it gives a checksum error.
When I compared it with the released firmwares I see it's using small a-f while released firmware use capitalized A-F.
So I simply converted it:
$ cat busPirate.production.hex |tr a-f A-F> busPirate.production2.hex
And I could successfully flash the bus pirate with it.
For this last point, I don't know what is the proper way to get rid of this case-sensitivity problem.
Make pirate-loader_lnx robust to the new HEX format?
How MPLABX is doing on the other OSes?
How the firmware loaders are doing on the other OSes?
Should we push the migrated MPLABX project to SVN too?
Do other people have experience to share with MPLABX?
Phil
My installation on a Linux system went much smoother than yours; I did not have any issues. However I had problems building the Bus Pirate project with MPLAB X under both Linux and Windows.
See also this thread. (http://http://dangerousprototypes.com/forum/index.php?topic=754.0)
-Eric
I removed case sensitivity from pirate-loader source, and the Windows version, but I guess it hasn't been recompiled for Linux yet.
Is it ok to post this on the wiki under the development section? This topic is really heating up.
It would be fine (and great) to include a mplabx project in the source. Would you like SVN access?
Thanks for the links Eric!
So to be complete in this thread, MPLABX installation was also discussed ath the following places:
* http://dangerousprototypes.com/2010/10/ ... linux-mac/ (http://dangerousprototypes.com/2010/10/24/beta-microchip-ide-for-linux-mac/)
* http://dangerousprototypes.com/forum/in ... 1#msg11831 (http://dangerousprototypes.com/forum/index.php?topic=1129.msg11831#msg11831)
* http://dangerousprototypes.com/forum/in ... 1#msg12051 (http://dangerousprototypes.com/forum/index.php?topic=754.msg12051#msg12051)
And there was a ref to the beta wiki of Microchip: http://microchip.wikidot.com/start (http://microchip.wikidot.com/start)
Ian it would be great indeed to have a wikipage to consolidate all the meaningful info about this matter.
Maybe 2 pages, one for general MPLABX installation & experience and one specific for Bus Pirate compilation under MPLABX?
I can push the mplabx project of bus pirate under SVN, I'll send you my Google ID by mail. Thanks.
You're added.
Feel free to edit the wiki. I one general page:
http://dangerousprototypes.com/docs/MPLAB_X (http://dangerousprototypes.com/docs/MPLAB_X)
and a section for MPLAB X in the Bus Pirate developer wiki page:
http://dangerousprototypes.com/docs/Com ... .2C_Mac.29 (http://dangerousprototypes.com/docs/Compile_the_Bus_Pirate_firmware#MPLAB_X_.28Win.2C_Linux.2C_Mac.29)
You can move your previous notes there, or I can do it with your permission.
Thanks Ian!
http://dangerousprototypes.com/docs/MPLAB_X (http://dangerousprototypes.com/docs/MPLAB_X) populated.
Once everything is settled in the bus pirate SVN I guess we won't need to explain much in the bus pirate specific section ;-)
Nice, thank you.
[quote author="doegox"]
# GTK_PATH=/usr/lib32/gtk-2.0 exec ./mplabxidebeta32.bin
# GTK_PATH=/usr/lib32/gtk-2.0 exec ./mplabc30.bin
[/quote]
There is this thing called "linux32" which should change the envirnoment to 32bit. (At least it is on gentoo 64bit :-) ) Have a look at man linux32 page.
Thanks robots but that didn't help.
There is also a linux32 under Debian (which claims to only modify uname -m output).
So using linux32 doesn't solve this GTK issue.
See same bug on Ubuntu & all gory details here: https://bugs.edge.launchpad.net/ubuntu/ ... bug/369498 (https://bugs.edge.launchpad.net/ubuntu/+source/ia32-libs/+bug/369498)
Migrating a discussion started in the bugreport page (https://code.google.com/p/the-bus-pirat ... tail?id=55 (https://code.google.com/p/the-bus-pirate/issues/detail?id=55))
There are now two working Makefile for linux in the source tree:
The one of Stephan in source/Makefile and the one generated by MPLABX in source/busPirate.X/busPirate/Makefile
Stephan had the great idea to try out the space optimization and it seems to work (but requires more tests of all modes)
Now both use the space optimization flag and I can see still the following differences:
* Stephan's Makefile compiles also ee.c & eetext.S objects, which are currently not used (commented out in procMain)
* MPLABX's is using elf format as intermediate format (-omf=elf)
* MPLABX defines a few internal symbols (-Wa,--defsym=__MPLAB_BUILD=1 & -Wl,--defsym=__MPLAB_BUILD=1)
* Stephan's Makefile output is neat, contrary to the verbose MPLABX Makefile output
Question is, what do we do?
Keep both Makefiles or get rid of the first one? (MPLABX IDE generated anyway the second one)
Or make another Makefile in source/ to encapsulate MPLABX Makefile, with neater output?
For those who want to try, there is a firmware image built with MPLABX comprising all modes:
http://the-bus-pirate.googlecode.com/sv ... MPLABX.hex (http://the-bus-pirate.googlecode.com/svn/trunk/firmware/v5-nightly/BPv3&v2go/BPv3-Firmware-v5.9RC-r556-MPLABX.hex)
I'll do a post on this and try to get some more testers.
Hi everybody,
a few observations:
- On such a small processor, we should definitely use -Os to conserve space. It might be a good idea to look at other GCC options, see http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html (http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html) . AFAIK the Windows IDE also uses GCC, so there should be some way to enable size optimization
- I like to enable all warnings with -Wall, this helps to catch some errors.
- The use of ELF or COFF intermediate format should have no effect on the final HEX file.
- I don't mind using the MPLABX Makefile. I managed to get a HEX file, although I always get an error at the end of the build.
So you can delete my Makefile, but then we should probably improve the MPLABX settings a bit.
Ian: you offered to give me SVN access. I'll be glad to help with this project, and of course I won't do large changes without discussing them first. My Google Code user name is xxxxxxxxx . Thanks!
-Stephan
Thanks, I added you and removed your email from the post.
Options for Controlling Optimization
The following options control compiler optimizations.
-O0 Do not optimize. (This is the default.)
Without -O, the compiler's goal is to reduce the cost of compilation and to make debugging produce the expected results. Statements are independent: if you stop the program with a breakpoint between statements, you can then assign a new value to any variable or change the program counter to any other statement in the function and get exactly the results you would expect from the source code.The compiler only allocates variables declared register in registers.
-O
-O1 Optimize. Optimizing compilation takes somewhat longer, and a lot more host memory for a large function. With -O, the compiler tries to reduce code size and execution time. When -O is specified, the compiler turns on -fthread-jumps and -fdefer-pop. The compiler turns on -fomit-frame-pointer.
-O2 FULL VERSION ONLY
Optimize even more. The compiler performs nearly all supported optimizations that do not involve a space-speed trade-off. -O2 turns on all optional optimizations except for loop unrolling (-funroll-loops), function inlining (-finline-functions), and strict aliasing optimizations (-fstrict-aliasing). It also turns on force copy of memory operands (-fforce-mem) and Frame Pointer elimination (-fomit-frame-pointer). As compared to -O, this option increases both compilation time and the performance of the generated code.
-O3 FULL VERSION ONLY
Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the inline-functions option.
-Os FULL VERSION ONLY
Optimize for size. -Os enables all -O2 optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size.
This is from hlpMPLABC30.chm (windows), so you can only use options higher than -O1 while you are evaluating the compiler, then it reverts to the lite version
I guess it's only a limitation of the IDE, do you know if it's still possible to use the option directly for pic30-gcc?
In that case we would need a separate Makefile...
Pfff I hate this non-free mentality.
I can only speak from the windows point of view and I've not yet tried this new IDE, but as far as I'm aware the IDE just passes command lines to the compiler tools and they decide what to do with them, after a set time (60 days i think) they inform you in the build window the evaluation period is over and just compile with lite options, with the little fiddling I did with optimizations, the -O1 option produces smaller/faster code
Delivering a limited gcc, what a shame
Here are some numbers just to get an idea (using MPLABX), compiling all modules
* -: does not fit
* -O1: 195924
* -O2: 214052
* -O3: does not fit
* -O4: does not fit
* -O5: does not fit
* -Os: 181508
So we can live with -O1 for a while...
I still hope that new MPLABX gcc can be used more freely... at least I don't thing there is any limitation in the beta version.
Hmm, from those numbers, it looks like -On optimization favors speed over size. Since -Os is supposed to give the best size (without making the code slower), I'm not surprised that it wins.
Did you try -O (without a number)? That is supposed to reduce code size and execution time (in standard gcc).
-O gives same results as -O1
And, quite obviously if it's same as -O1: -O is not an option available per se in the IDE
Guyzz
I Just got 2 BusPirates , and wanted to see if i could build the firmware on Ubuntu 10.04LTS
I read about the -O1 limit on the compiler , and wanted to see if i could circumvent that :-)
I maintain the Linux avr-gcc buildscript @ AvrFreaks , so i had to try to build a pic toolchain.
I followed this recipe
http://code.google.com/p/pic30/ (http://code.google.com/p/pic30/)
And ended up with a compiler , that was "almost working" ....
I just needed to make 2 symlinks , and rename a few of the binaries
See build-hints
I did a svn checkout : svn checkout http://the-bus-pirate.googlecode.com/svn/trunk/ (http://the-bus-pirate.googlecode.com/svn/trunk/)
And had to modify the makefile a little bit ...It complained about the .inc file in OpenOCD_asm.S
I had to help gcc (well AS in the end) a bit ... the -Wa part
See makefile.
CFLAGS = -v -Wall $(OPTIMIZE) $(DEFS) $(INCLUDES) -mcpu=$(CPU) -mlarge-code -mlarge-data -Wa,-I$(C30_PATH)/support/PIC24F/inc
I also added a neat makefile trick , i snipped from the net ...
Now it lists the individual size of each .o module.
Here is the result of the build
Maybe someone can check against an "official" compiler
rm -rf *.o *.coff *.hex
CC 1wire.o
CC AUXpin.o
CC base.o
CC baseIO.o
CC baseUI.o
CC basic.o
CC binIO.o
CC binIOhelpers.o
CC binwire.o
CC bitbang.o
CC busPirateCore.o
CC dio.o
CC ee.o
CC eetext.S.o
CC HD44780.o
CC I2C.o
CC m_1wire_213.o
CC main.o
CC OpenOCD.o
CC OpenOCD_asm.S.o
CC pc_at_keyboard.o
CC pic.o
CC procMenu.o
CC raw2wire.o
CC raw3wire.o
CC selftest.o
CC SPI.o
SPI.c: In function ‘SPIwrite’:
SPI.c:129: warning: control reaches end of non-void function
CC SUMP.o
CC uart2io.o
CC UART.o
LINK main.coff
text data bss dec hex filename
2952 516 224 3692 e6c ./1wire.o
1188 0 0 1188 4a4 ./eetext.S.o
5916 140 2256 8312 2078 ./basic.o
1252 0 0 1252 4e4 ./raw2wire.o
3164 80 16 3260 cbc ./UART.o
52 0 0 52 34 ./dio.o
988 0 4 992 3e0 ./raw3wire.o
1916 0 36 1952 7a0 ./AUXpin.o
1196 0 44 1240 4d8 ./SUMP.o
560 0 0 560 230 ./baseUI.o
1520 0 8 1528 5f8 ./binIO.o
972 36 0 1008 3f0 ./base.o
2548 0 20 2568 a08 ./binwire.o
1264 4 0 1268 4f4 ./ee.o
1040 0 4 1044 414 ./OpenOCD.o
140 0 0 140 8c ./binIOhelpers.o
2764 0 16 2780 adc ./I2C.o
3844 24 12 3880 f28 ./SPI.o
10104 0 848 10952 2ac8 ./procMenu.o
1212 0 4 1216 4c0 ./selftest.o
0 0 0 0 0 ./pc_at_keyboard.o
1264 0 20 1284 504 ./bitbang.o
264 0 0 264 108 ./OpenOCD_asm.S.o
0 0 0 0 0 ./pic.o
192 828 0 1020 3fc ./busPirateCore.o
1952 0 32 1984 7c0 ./baseIO.o
1124 0 4 1128 468 ./HD44780.o
1236 0 8 1244 4dc ./m_1wire_213.o
304 0 0 304 130 ./uart2io.o
252 36 8244 8532 2154 ./main.o
51180 1664 11800 64644 fc84 (TOTALS)
Final Size:
pic30-size main.coff
text data bss dec hex filename
63564 1664 11800 77028 12ce4 main.coff
BIN2HEX main.hex
writing main.hex
section PC address byte address length (w/pad) actual length (dec)
------- ---------- ------------ -------------- --------------------
.reset 0 0 0x8 0x6 (6)
.text 0x200 0x400 0xa84 0x7e3 (2019)
.ivt 0x4 0x8 0x1f8 0x17a (378)
.aivt 0x104 0x208 0x1f8 0x17a (378)
.const 0x742 0xe84 0x6bc 0x50d (1293)
.text 0xaa0 0x1540 0xa74c 0x7d79 (32121)
.dinit 0x5e46 0xbc8c 0x5b0 0x444 (1092)
.text 0x611e 0xc23c 0x3614 0x288f (10383)
.isr 0x7c28 0xf850 0x4 0x3 (3)
Total program memory used (bytes): 0xba39 (47673)
I have attached the hex & coff files in the main package.
As i don't have a PIC burner , i don't dare to upload it to the BP.
But maybe someone else can check , (if it even fits) .. Isn't there a bootloader also ?
Well it has been fun to try , and i never thought i would ever have a PIC compiler on my machine :-)
/Bingo
Thanks for the outline, it's great to hear it's compiling on MPLABX. If you have any patches against the SVN I can apply them and do a test compile.
As i don't have a PIC burner , i don't dare to upload it to the BP.
I think it will be ok. The bootloader is very well protected in the Bus Pirate.
But maybe someone else can check , (if it even fits) .. Isn't there a bootloader also ?
The bootloader source is located here in SVN:
http://code.google.com/p/the-bus-pirate ... mware-v4.3 (http://code.google.com/p/the-bus-pirate/source/browse/#svn%2Ftrunk%2Fbootloader-v4%2Ffirmware-v4.3)
It is all in ASM.
@Ian
I haven't used MPLABX yet ...
I have just build a PIC toolchain , with -Os support "forever" , and tested it with the "Makefile" included in svn (well the adapted one i attached)
Will prob. try MPLABX later on ...
For now i'm just fooling around with the "homemade" toolchain on an Ubuntu 10.04LTS 32-bit machine.
I'm trying to build the above script on an x64 machine but i'm having some trouble.
The linker complains about some files are build in 32-bit mode.
Will look into it.
/Bingo
Would I still need a PICKIT 2 or Sureelectronics PICKIT 2 mini to update the firmware on Bus Pirate 3.5b with MPLABX?
I have several OS's Mac OSX 10.7, Mac OSX 10.6, MAc OSX 10.5.8, Fedora Linux 15 64 bit, Fedora 13 32bit, windows 7 64 bit and two vmware OS's windows XP 32 bit and windows 7 64 bit.
I would like to get MPLABX running on MAc OSX 10.5.8 and Fedora Linux 15 64 bit and windows 7 64 bit right now. Will it run on all 3 OS's and support firmware upgrade on the BP 3.5b without the PICKIT 2?
Thanks
That bus pirate has a usb bootloader. If you can get it compiled, you should be able to load it with the bootloader and no programmer.,
I got MPLABX running on a 32 bit linux. It does work reasonable well.. You can import a mplab8x project using a wizard. Why don't you give it a try?
If you have bought your BP commercially it is equipped with a bootloader so you don't need a PICKIT to programm it. The bootloader should withstand lots of abuse and still survive. You still need MPLAB(X) to compile the sourcecode.
I just execute $ in xterm and it flashes BOOTLOADER. In OSX 10.5.8
Then what is the procedure to burn the new firmware onto the BP in MPLABX? DO I need to cnvert the HEX file as said here then go from there? Is there a short protocol on the procedure to upload the new firmware to the BP?
I want to try Firmware version 5.9 but cannot find the firmware files inbetween my currently installed version 5.10 and the latest 5.9 version.
It has to be on SVN correct? I just could not find them.
Anyhow what is the procedure after I install MPLABX?
Thanks
[quote author="pcfr33k"]Then what is the procedure to burn the new firmware onto the BP in MPLABX? DO I need to cnvert the HEX file as said here then go from there? Is there a short protocol on the procedure to upload the new firmware to the BP?
[/quote]
To upload a new firmware here are the direction in our wiki: http://dangerousprototypes.com/docs/Pir ... c,_Windows (http://dangerousprototypes.com/docs/Pirate-Loader_console_upgrade_application_(Linux,_Mac,_Windows))
[quote author="pcfr33k"]
I want to try Firmware version 5.9 but cannot find the firmware files inbetween my currently installed version 5.10 and the latest 5.9 version.
It has to be on SVN correct? I just could not find them.
[/quote]
The latest version in our svn, but you can get an older revision. Version 5.9 was svn version 540 i guess. http://code.google.com/p/the-bus-pirate ... tail?r=540 (http://code.google.com/p/the-bus-pirate/source/detail?r=540)
[quote author="pcfr33k"]
Anyhow what is the procedure after I install MPLABX?
[/quote]
I guess you should write PIC code :)
If you want to compile your own buspirate firmware, get the code from the svn, import a mplab8 project into it and start your own fantasy. You can upload your fimrware with a pickit directly from mplabx or get the .hex from the build directory and upload it with the ds30 upload utility.
I should have mentioned I am in OSX 10.5.8 right now.
For now I want to upload the stock firmware not my own.
I cannot get ds30 to work in OSX 10.5.8 using mono so I have to try another method.
I tried to use pirate-loader_mac and it is also not working I left a post on the message I get when I launch it.
sh-3.2# ./pirate-loader_mac
dyld: unknown required load command 0x80000022
Trace/BPT trap
sh-3.2#
Also that link you posted is not working below
To upload a new firmware here are the direction in our wiki: http://dangerousprototypes.com/docs/Pir (http://dangerousprototypes.com/docs/Pir) ... c,_Windows)
EDITED ABOUT AN HOUR LATER:
I figured out the link missing a ")". Anyhow I followed that tutorial the I get the message above. I will try this in OSX 10.6 to see if the Pirate-Loader_Mac application was written for 64 bit or Snow Leopard rather than Leopard.
If not I suppose I could try it in Fedora Linux 64 bit.
I have to assume that I cannot upload the STOCK firmware in MPLABX which is what I was asking before.
Thanks
EDITED ABOUT ANOTHER HOUR LATER:
Well all my issues had to do with OSX 10.5.8. Got everything working in OSX 10.6.8. By everything I mean Bus Pirate Gui, Pirate-loader_mac to upload the stock firmware. So now its time to learn coding etc which I have little experience just some MSSQL and Power Builder.
After the firmware upgrade I was a bit confused on how to verify? After the firmware upgrade do I need to disconnect the BP then do the verify or do the verify right after the update and exactly what is the exact script below gives me a blank screen.
Firmware updated successfully :)!
Use screen /dev/tty.usbserial-A900F57B 115200 to verify
After upgrading you should unplug the buspirate to be sure it got properly reset. Use the'i' command to verify the current firmware.
Yes and it displays the new firmware properly. So I cannot run any verify command before reseting the BP I assume? That message about use screen what is that all about? Thanks
[quote author="pcfr33k"]That message about use screen what is that all about? Thanks[/quote]
screen is a command to connect to the serial port (usb) that the buspirate is on. then you could use the 'i' command to print out the firmware version.
Thanks for all the help. Now to some obscure questions that to some of you may sound stupid but I am new to this. Can I use MPLAB X with the Bus Pirate to read and write DATA to an SPI device connected to to BP but using MPLAB X or do I still have to use the terminal to do this? I was unable to get BusPirategui for Mac to work in OSX 10.6. I can execute the Open Pirate command in that Gui however when I try to read the SPI it fails. I cannot generate the voltages on the GUI Application either and that is probably why its not reading the SPI device. I like the frontend on MPLAB 8 using MPLAB stater kit to read write verify etc using that front end. Its just kinda neat to see the entire address and working with the SPI in MPLAB 8.
Anyhow I know there is another GUI lurking around but its for Linux not Mac.
Hi pcfr33k,
I'm not aware of anything that will allow the Bus Pirate to be used directly in MPLAB.
You can write your own firmware using MPLAB X and then use a PICkit or other MPLAB debugger to download the code to the PIC on the Bus Pirate and run your firmware. This would not be interactive, though - not like the terminal. There is no way to interactively input data from MPLAB X to the Bus Pirate. You could change the data in your source code, recompile, and run again, but that's a lot slower than using the terminal. MPLAB X is for firmware developers, but you need some other source of data for interactive control.
I've been trying to compile the firmware on Linux in MPLABX, and while it compiles just fine, I cannot get [tt:]pirate-loader[/tt:] to upload it correctly. With my firmware, everything seems to go fine until:
Writing page 26 row 215, 6b80...OK
Erasing page 41, a400...OK
Writing page 41 row 328, a400...OK
…
Erasing page 42, a800...ERROR [50]
With the released v6.1 firmware there is no “page 42”, and so it works fine:
Writing page 40 row 327, a380...OK
Erasing page 41, a400...OK
Writing page 41 row 328, a400...OK
…
Writing page 41 row 335, a780...OK
I would assume that the problem is because I'm running out of space on the device (i.e, there is no page 42 available?), but no matter what optimizations I try or features I disable, my firmware file always seems to extend to page 41 and 42. Note that in the official firmware release the pages were contiguous from 1 to 41, but in mine they skip from page 26 to 41.
If I try without [tt:]-Os[/tt:], as is the default, and don't disable any normal features like the LCD support that I don't need, my firmware [tt:].hex[/tt:] file is about the same size as the official firmware, but it still exhibits this “page gap” which causes the end to extend to the problematic page 42.
What am I doing wrong, i.e. what makes something want to be on page 42 even if there are over 10 pages free before then?
Or, has anyone been able to compile this succesfully on Linux or OS X with MPLABX, and could they upload their source directory with the MPLABX project? The X-project in SVN does not compile (refers to some obsolete files that don't exist anymore), so I needed to import the MPLAB 8 -version.
P. S. My Bus Pirate is hardware v3.5, bootloader v4.4, [tt:]pirate-loader[/tt:] from the 6.1 binary distribution. After each failed attempt I've always been able to re-upload the official 6.1 firmware.
Page 42 is where the bootloader and configuration bits are, they protect themselves from overwriting and throw error P (0x50?) for protected. You need to export the .hex from 0x00=0xa7fa and exclude the config bits. Then it should work:
http://dangerousprototypes.com/docs/Com ... bootloader (http://dangerousprototypes.com/docs/Compiling_PIC_projects#Export_for_bootloader)
Yes, I actually figured that out when I finally got tired of fighting with MPLAB X and installed MPLAB 8 in a Windows XP virtual machine. However, I cannot find where in MPLAB X I could set the same configuration; export does not present the pictured dialog.
Hum, I assume someone in this thread will know because some have done it successfully.
I finally found it in MPLAB X. Instructions for future reference:
First one needs to select a PIC programmer device ([tt:]File -> Project properties[/tt:], then [tt:]Conf: default[/tt:], then select, e.g., [tt:]PICKit3[/tt:] from the list on the right). Then click [tt:]Apply[/tt:] and select the programming device ([tt:]PICKit3[/tt:]) from the list on left. Select [tt:]Memories to Program[/tt:] from the menu on the right, and for the option [tt:]Auto select memories and ranges[/tt:] choose [tt:]Manually select memories and ranges[/tt:]. Tick the box for [tt:]Program Memory[/tt:] and below that enter [tt:]0xa6ff[/tt:] as the end value. (Now wasn't that an obvious place to configure exported hex files? =)
Note that the value [tt:]0xa7fa[/tt:] used for MPLAB 8 is not accepted; MPLAB X requires the value to be either [tt:]0xabfb[/tt:] (which overlaps the bootloader area as described above) or of the form ([tt:]0x100 * n - 1[/tt:]); the largest suitable value of this form is [tt:]0xa6ff[/tt:] (a loss of 251 bytes of program space?).
Nice research!
My guess is 0xa7ff is also ok. AFAIK the pirateloader is overwriting the last bytes with the correct jump address before sending it to the bootloader.
I edited the wiki page to include the MPLAB X instructions.
Thanks for the edit Arkku :) I was just about to do it myself, what a pleasant surprise, thanks!
[quote author="Arkku"]I finally found it in MPLAB X. Instructions for future reference:
...
Note that the value [tt:]0xa7fa[/tt:] used for MPLAB 8 is not accepted; MPLAB X requires the value to be either [tt:]0xabfb[/tt:] (which overlaps the bootloader area as described above) or of the form ([tt:]0x100 * n - 1[/tt:]); the largest suitable value of this form is [tt:]0xa6ff[/tt:] (a loss of 251 bytes of program space?).[/quote]
I used this info to recompile the firmware but whatever value for Program Memory End I set - the hex file was the same - no diffs.
What other options could be in affect?
MPLABX 1.0 under debian, optimization is set to -O1, Bus Pirate svn code.
[quote author="beeduino"]I used this info to recompile the firmware but whatever value for Program Memory End I set - the hex file was the same - no diffs. What other options could be in affect?[/quote]
Well, the only thing I can think of is that this change did not take effect, e.g., you only tried to “Export hex” and did not “Clean and build”, or maybe the setting did not get saved for some reason. (Did you click “Apply”?)
Unfortunately the MPLAB user interface is so bad that I cannot even guess what other settings I might have touched that could possibly affect this. If the above suggestions don't work, I would perhaps try re-importing the MPLAB 8 project and redoing the configuration without ever compiling with the incorrect settings.
[quote author="beeduino"]
MPLABX 1.0 under debian, optimization is set to -O1, Bus Pirate svn code.[/quote]
I'm using the same configuration, except I use [tt:]-Os[/tt:] optimization.
If anyone is interested I started from scratch and got BPv4 source with Microchip USB compiled using the latest tools:
IDE:
MPLAB X (v1.6).
CC:
XC16 (v1.11)
OS:
Mac OS X 10.6.8
Java: 1.6.0_37
USBI chose the Microchip USB source since I
a) wanted at least one bit reliable :-)
b) haven't yet found the open source USB source (
location anyone?)
Apart from some Microchip/include files I used:
- USB/CDC Device Driver/usb_function_cdc.c
- USB/usb_device.c
- a local copy of CDC Basic Demo/Firmware/usb_descriptors.c (as yet unmodified)
MPLAB X IDE notesI don't like the idea of dumping my project source code inside the mplab source tree just to get it to compile so I found out how to handle includes and source outside the bus-pirate tree.
Bit long to explain here in detail but in short:
- Add remote .c files using a (new) logical folder (I called mine 'USB') in projects window (optionally add remote .h files but not required).
- under "project properties" -> categories: xc16-gcc (compiler) -> Option categories: preprocessing and messages -> C include dirs: path_to_microchip_apps_lib_source..../Microchip/Include
Talk about obscure....
And it should all compile....
Haven't tried bootloader.
Newcomer FeedbackAlso some feedback as a new comer there isn't really a PBv4 status page and roadmap so I/we don't know overall what is in the pipeline (and by who) what works and what doesn't, what won't ever work (seen a comment or two) and maybe a simple user-contributed test matrix each major platform.
The issues list is unfortunately also confusing for outsiders because there are BPv4 items added to at least 3 different lists....
- http://dangerousprototypes.com/track/vi ... g_page.php (http://dangerousprototypes.com/track/view_all_bug_page.php)
- http://code.google.com/p/the-bus-pirate/issues/list (http://code.google.com/p/the-bus-pirate/issues/list)
- http://code.google.com/p/dangerous-prot ... are/issues (http://code.google.com/p/dangerous-prototypes-open-hardware/issues)
I understand that the top one may be the definitive one, in which case perhaps the others should be closed as all have been added to in the last 6ish months...
QuestionNot sure what to do next as I can't get my hands on a PBv4c board + parts. Any suggestions or should I just wander off buy a v3 and forget trying to get the v4 working (better)?
best regards
Kim
the opensource USB stack is in our svn. it should reside in the directory ./dp_usb
You are using the right svn? we switched some time ago to one where all our projects reside.
Link to the latest sources: http://code.google.com/p/dangerous-prot ... 2FFirmware (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/#svn%2Ftrunk%2FBus_Pirate%2FFirmware)
@Sjaak
Oh .. ok thanks ...
The svn source tree I found was this:
http://code.google.com/p/the-bus-pirate/source/browse/ (http://code.google.com/p/the-bus-pirate/source/browse/)
a seemingly older archive with no warning that it is presumably out of date...?
Couldn't someone archive and trash the old tree. If I found that then others can too and it wastes time and causes confusion :-(
cheers
Kim
I'm sorry about the confusion. I have been meaning to clean it for a while so I:
*Updated front page, added warning, removed old links and stuff
*Made a snapshot of v5.10 firmware
*Added warning text files to SVN with link to new address
[quote author="beeduino"]
I used this info to recompile the firmware but whatever value for Program Memory End I set - the hex file was the same - no diffs. What other options could be in affect?[/quote]
I had the same issue with MPLAB X 1.85 and XC16 1.11. I eventually resorted to going through every setting in the Project Properties dialog and messing with the ones that looked relevant. As Arkku said, you need to choose [tt:]PICkit3[/tt:] as the hardware target and configure it to export only program memory from [tt:]0x0[/tt:] to [tt:]0xa7ff[/tt:]. In order for that to take effect I also had to enable [tt:]Remove unused sections[/tt:] under [tt:]xc16-ld[/tt:]. I don't know whether that also works with C30, and there may be other necessary settings which for me were serendipitously correct. YMMV.
[quote author="Sjaak"]Link to the latest sources[/quote]
Latest sources are now available there - http://http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498
Firmware v7.0 ;) Need to expose this link more, so that everyone could easily get a new firmware for their BPv4