First of all - my Bus Pirate is working! Thanks everyone who was helping.
[quote author="Arkku"] Did you do “Clean and build” after changing the setting? It has no effect if you just “Export hex”. I had the exact same problem with the same error message, but solved by following the steps I gave in the MPLAB X thread.[/quote]
I did. I would like to get it compiled properly with MPLABX so I will test it again, 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="Arkku"] Change the 0xa7fa to 0xa6ff to get rid of the warning.
(I struggled with this same issue earlier. I am now using MPLAB X to compile the firmware with no issues.)[/quote]
I was trying to recompile the firmware yesterday with all available settings - 0xa7fa, 0xa6ff, 0xa7ff. In all the cases the hex file was the same - no diff. And uploading gave the same error -
I have switched off most of the features except i2c (commenting in base.h) and hex file was shrinked from about 190K to 124K - no different. How to check that Program Memory End setting is applied to the build?
MPLABX 1.0 under debian. Optimization is set to -O1. Bus Pirate svn code.
[quote author="AndThen"] 2. You will want the (from memory) BPv3_firmware, not the bootloader [/quote] I saw bootloader's hex files with header and footer like in my compilation but surely i was compiling firmware code not bootloader.
Quote
Now the useless background out of the way. In the 39881D.pdf page 4 has the Pin outs, CNx are listed here. RB2 is CN6.
They are also listed in the BP schematic, http://dangerousprototypes.com/wp-conte ... 04/cct.png , Looking at this Is RB2 a bad choice? if RB3/CN7 is used you still have the other TP and ground, unsure if the hardware comparator is used
What should I change this setting to if I remap MOSI to RB2 pin?
Also I compiled firmware but when making exporting for bootloader in MPLABX the setting of 0xa7fa was prefixed with "!!!". And it looked like a warning. Compiled hex file head looked like this:
Installed software but not yet sure what pin to remap. I can use this buspirate mostly as i2c tester so any decrease in other functionality would be ok.
I have burnt my buspirate connecting MOSI (SDA) line to + of a battery pack. It is a pure ground on pin 18 of the PIC chip now, so I assume this pin is out of work completely. Other things work according to self test.
So my question is how to recover from this? - if buy new one - would you recommend to try v4, even if it's not yet officially released? - may I order somewhere new pic chip with firmware preloaded? - is it possible to rearrange the problem pin to another one, recompile and update firmware and rewire a little bit on the board?
Interesting, some other device (EV2300 from TI) was connected in parallel to buspirate when it happened. And it survived due to ESD protection gl05t diodes on signal lines. Was it discussed to add some protection into a buspirate?
I have found BusPirateGui when searching for I2C EEPROM programming support for the BusPirate. I was able to build it under linux but did not find a way to load eeprom image file for upload. Was it dropped at the time spi flashrom support was dropped over to flashrom project?
