Skip to main content ↑ ↓

Messages

This section allows you to view all Messages made by this member. Note that you can only see Messages made in areas you currently have access to.

Messages - Arkku

16
Bus Pirate Support / Re: Firmware update on Linux ?
The STK500v2 firmware isn't supposed to give you anything on the terminal, it just speaks the STK500v2 protocol. That is, your Bus Pirate no longer works as a Bus Pirate but as an STK500v2 compatible AVR programmer that can be used from, e.g., AVR Studio. If you want to get it back to a Bus Pirate, you need to put in the Bus Pirate firmware again (and then it will not work with AVR Studio, but you can still use [tt:]avrdude[/tt:] from the Linux command line to program AVR devices).
17
Bus Pirate Support / Re: Firmware update on Linux ?
Oh, by the way, it looks like you're trying to upload the wrong firmware, the new file (in the 6.1 firmware release) should be called [tt:]BPv3-STK500v2-v0b.hex[/tt:].
18
Bus Pirate Support / Re: Firmware update on Linux ?
You can exit [tt:]screen[/tt:] by pressing Ctrl-a k. (i.e., hold down ctrl, press a, let go of both keys, press k)

If this is a problem for some reason, try this:

Code: [Select]
stty 115200 </dev/ttyUSB0
echo -e '$rny' >/dev/ttyUSB0

If that doesn't work, replace the [tt:]echo[/tt:] line with: [tt:]cat >/dev/ttyUSB0[/tt:] and type [tt:]$<enter>y<enter><Ctrl-d>[/tt:]
19
Bus Pirate Support / Re: 1-wire ROM search broken in binary mode? (Edit: No.)
Solved: The Bus Pirate is not broken; the serial port library I cargo-culted off the net is. Looking at the incorrect ids, I realized that each id beyond the first is in fact a bitwise OR of all ids seen thus far. The reason I encountered this only in reading the ROM ids is that this is the only place where I asked the library to read 64-bit integers instead of arrays of bytes (which would have worked fine).

I'm terribly sorry about the misplaced blame!

(However, the silver lining is that this mess made me learn how to compile the Bus Pirate firmware on Linux, so maybe that'll yield the community some benefits in the long run. =)
21
Bus Pirate Development / Re: Re: Compiling Bus Pirate firmware with MPLABX (under lin
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?).
23
Bus Pirate Support / Re: 1-wire ROM search broken in binary mode?
I finally managed to compile and upload a custom firmware for my Bus Pirate. I tried adding various delays, even ridiculously long ones, in between the 1-wire ROM searches and even in between the individual bytes written out, but to no avail—I still get the same wrong ids with more than 1 device on the bus, except in ASCII mode where it still works just fine. So, probably not a timing issue.

My next guess would be that the ASCII mode does some initialization of global variables and/or data structures used by the ROM search that is not done by the binary mode.
24
Bus Pirate Development / Re: Compiling Bus Pirate firmware with MPLABX (under linux,
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:

Code: [Select]
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:

Code: [Select]
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.
25
Bus Pirate Support / Re: 1-wire ROM search broken in binary mode?
Hi, thanks for replying!

I took a look at the firmware sources, and it does indeed seem like both modes use the same [tt:]OWSearch()[/tt:] function, which makes the problem all the more puzzling. The only difference I can spot is that the ASCII mode has far more extensive delays between calls to [tt:]OWSearch()[/tt:] due to additional printouts; could it be that there needs to be a slight delay before [tt:]OWSearch()[/tt:] can reliably be executed again?

On the other hand, if this was a simple timing-related issue, I am surprised by the consistency of the error; whenever I have the same combination of devices on the bus, they always get the same incorrect ids, even if I power down in between tests and/or move the devices around physically.
26
Bus Pirate Support / 1-wire ROM search broken in binary mode? (Edit: No.)
Hi,

I wrote a small library for myself to access the binary mode of Bus Pirate (v3.5, FW 6.1 r1676), and noticed that there seems to be a problem with the 1-wire ROM search function when there are multiple devices on the 1-wire bus. In ASCII mode everything works fine:

Code: [Select]
1-WIRE>(240)
SEARCH (0xF0)
Macro     1WIRE address
 1.0x28 0x28 0x65 0x91 0x02 0x00 0x00 0xEB
   *DS18B20 Prog Res Dig Therm
 2.0x28 0xA4 0xCE 0x91 0x02 0x00 0x00 0x3F
   *DS18B20 Prog Res Dig Therm
 3.0x28 0x2B 0x6B 0x91 0x02 0x00 0x00 0x10
   *DS18B20 Prog Res Dig Therm


However, in binary mode the search only works correctly when there is exactly one device on the bus:

Code: [Select]
1 alone) 0x28286591020000eb
2 alone) 0x28a4ce910200003f
3 alone) 0x282b6b9102000010

But when I have two or three devices on the same bus (exactly the same way as in ASCII mode), I get:

Code: [Select]
1+2) 0x28286591020000eb
     0x28acef91020000ff
1+3) 0x28286591020000eb
     0x282b6f91020000fb
2+3) 28a4ce910200003f
     28afef910200003f
1+2+3) 0x28286591020000eb
       0x28acef91020000ff
       0x28afef91020000ff

The results are consistently the same for each combination when I try multiple reads, but always incorrect for all but one device. Note that the error is not consistent across different combinations, e.g., device 3 has a different id in 1+3, 2+3, and 1+2+3 combinations.

I am fairly certain I am not reading the binary data incorrectly since I get the correct number of bytes and the beginning of each id always seems to match so reading does not seem to be out of sync there. Is there a bug in the firmware, and why would the Bus Pirate use a different ROM search method for ASCII vs binary mode?


Edit: Oh, by-the-way, the 1-wire binary mode works perfectly for actually accessing all three devices on the same bus once the correct ids are known. The problem is just with the binary mode search ROM command that returns incorrect ids.

( ! ) Fatal error: Uncaught exception 'Elk_Exception' with message 'Please try again. If you come back to this error screen, report the error to an administrator.' in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
( ! ) Elk_Exception: Please try again. If you come back to this error screen, report the error to an administrator. in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
Call Stack
#TimeMemoryFunctionLocation
10.01522385160session_write_close ( )...(null):0
20.01552516784ElkArte\sources\subs\SessionHandler\DatabaseHandler->write( )...(null):0
30.01552517560Database_MySQL->query( ).../DatabaseHandler.php:119
40.06042656320Database_MySQL->error( ).../Db-mysql.class.php:273