Skip to main content
Topic: Bus Pirate firmware v6.1 development (Read 61178 times) previous topic - next topic

Bus Pirate firmware v6.1 development

Bus Pirate v6.1 development thread

Would like to:
[s:]*Detect v3b/v3.5/eBay versions (uses different chip/id) and show in v3[/s:]
[s:]*V4 firmware doesn't detect chip revision correctly[/s:] seems ok
*OpenOCD to v4?
*XSVF integrated to v4?
[s:]*Do we need the USB updates from IR Toy for 8 and 48 byte errors[/s:]
[s:]*Add autobaud to macro too
*Trim the autobaud text a little for size
*Move SVN completely to DP, update old SVN with forwarder[/s:]
*EEPROM use in v4?

---
v4 fixes
*read bootloader version info
[s:]*Correct version detect (this should be A1 I think)[/s:] seems ok
*update bootloader jump. Should disable USB pullups and pause 10 seconds so computer sees it go away
*UART bridges, etc should match the virtual serial port setting (or offer to)
*Put easter egg back
*Something useful with EEPROM
*Add STK500 mode, make stick with EEPROM setting
*NORMAL button overrides any EEPROM settings for rescue
[s:]*Bus Pirate bitbang mode IO fix:[/s:] viewtopic.php?f=28&t=3403&p=34198#p34196 Thanks tes!
---
Pietja:
[s:]*Fix the USB led[/s:]
*Support for a passive LCD adapter
----

[s:]Make baud detection sample 10 bit samples x 3 calculation samples before submitting baud
Make the 'Nearest Common Baud' function smarter[/s:]
Fix translation files names (eg BPv4*.h & BPv3*.h instead of how they are now, as they are confusing)
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate firmware v6.1 development

Reply #1
[quote author="ian"]*The self-test expects a connection between ADC and +5V "Connect (ADC to +5V)" however you cant fit a jumper between those pins, you can fit a jumper between ADC and +3.3V.
So change the expected voltage from 5v to 3.3v.[/quote]
I have already submitted a code for this, is it still the old one? It was basically a change of 2 lines.

BTW, shall I continue developing code for SMPS board (pic programming adapter)?

Re: Bus Pirate firmware v6.1 development

Reply #2
Quote
I have already submitted a code for this, is it still the old one? It was basically a change of 2 lines.
Probably, this is a to-check list from an old thread that I unstickied. Don't put too much stock in it.
Quote
BTW, shall I continue developing code for SMPS board (pic programming adapter)?

Please, that would be great, and means v4 can program also the new chips.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate firmware v6.1 development

Reply #3
YAY :D This should be fun. Im starting to know PICs much better, so this should be really fun!

Also add:

Make baud detection sample 10 bit samples x 3 calculation samples before submitting baud
Make the 'Nearest Common Baud' function smarter
Fix translation files names (eg BPv4*.h & BPv3*.h instead of how they are now, as they are confusing)

Whats the 'Autobad' macro too? So instead of just saying the baud there should also be a macro to set the baud rate?

 

Re: Bus Pirate firmware v6.1 development

Reply #4
I was thinking a macro that does the autobaud measurement in addition to the autobaud setting in the setup menu. That way you could do (5) and it will run the measurement routine and report (but not set...) the baud of the serial traffic.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate firmware v6.1 development

Reply #5
[quote author="ian"]Bus Pirate v6.1 development thread

Would like to:
*OpenOCD to v4?
[/quote]

?? I looked at the what I had here and the port appeared to be done AFAIK. I mean the USB part of it. What am I missing?

[quote author="ian"]
*Do we need the USB updates from IR Toy for 8 and 48 byte errors
[/quote]

No, the BPv4 enters double buffer mode and stays there unlike the IR TOY pre IR TOY 2012 that switched modes leaving its left flank open for a surprise attack by phantom zombie non-existent bytes.

[quote author="ian"]
*Move SVN completely to DP, update old SVN with forwarder
[/quote]

Would be great if it could be intergrated with MPLAB X sub version.

[quote author="ian"]
*read bootloader version info
[/quote]

I thought you had done that already. I seem to remember it was the last hold up with the V1 dp30 bootloader.


[quote author="ian"]
Make the 'Nearest Common Baud' function smarter
[/quote]

Personally, I would trust the auto baud detect to find the best baud rate. That way if it is connected to something running from an internal RC oscillator any error is adjusted for.

Re: Bus Pirate firmware v6.1 development

Reply #6
Quote
?? I looked at the what I had here and the port appeared to be done AFAIK. I mean the USB part of it. What am I missing?

I need to double check, but I recall noting that the Open OCD mode robots wrote used the UART interrupt and UART hardware directly, I thought that part had not been ported yet. I believe I also noted an error changing into that mode on Bus Pirate v4. I would be happy to be mistaken :)


Thanks for clarifying that we don't need updates to the USB part.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate firmware v6.1 development

Reply #7
[quote author="ian"]I was thinking a macro that does the autobaud measurement in addition to the autobaud setting in the setup menu. That way you could do (5) and it will run the measurement routine and report (but not set...) the baud of the serial traffic.[/quote]

oh thats still there.

Re: Bus Pirate firmware v6.1 development

Reply #8
[quote author="ian"]
Quote
?? I looked at the what I had here and the port appeared to be done AFAIK. I mean the USB part of it. What am I missing?

I need to double check, but I recall noting that the Open OCD mode robots wrote used the UART interrupt and UART hardware directly, I thought that part had not been ported yet. I believe I also noted an error changing into that mode on Bus Pirate v4. I would be happy to be mistaken :)
[/quote]

Sadly, you are not mistaken, even sadder, I am. Indeed there is an interrupt driven aspect that is not ported. Is the source code for V6 in the SVN?

Re: Bus Pirate firmware v6.1 development

Reply #9
Possible changes required to openOCD.c. Not tested but it is a starting point and by some fluke it may actually work.

Note the the asm code will need to be changed so as to NOT transmit the TX data, instead just buffer it until it RETURNS.

Code: [Select]
            case CMD_TAP_SHIFT:
                inByte = UART1RX();
                inByte2 = UART1RX();

                IFS0bits.U1RXIF = 0; // reset the RX flag

                j = (inByte << 8) | inByte2; // number of bit sequences

                // this fixes possible buffer overflow
                if (j > 0x2000)
                    j = 0x2000;

                i = (j + 7) / 8; // number of bytes used
                buf[0] = CMD_TAP_SHIFT;
                buf[1] = inByte;
                buf[2] = inByte2;
                binOpenOCDAnswer(buf, 3);

                UART1RXBuf = (unsigned char*) bpConfig.terminalInput;
                UART1RXToRecv = 2 * i;
                UART1RXRecvd = 0;

                UART1TXBuf = (unsigned char*) (bpConfig.terminalInput + 2100); // 2048 bytes + 3 command header + to be sure
                UART1TXSent = 0;
                UART1TXAvailable = 0;

#ifdef BUSPIRATEV4
                do {
                    WaitOutReady();
                    UART1RXRecvd += getsUSBUSART((bpConfig.terminalInput + UART1RXRecvd), CDC_BUFFER_SIZE); //JTR2
                } while (UART1RXRecvd != UART1RXToRecv);
#else
                // prepare the interrupt transfer
                // enable RX interrupt
                IEC0bits.U1RXIE = 1;
#endif
                binOpenOCDTapShiftFast(UART1RXBuf, UART1TXBuf, j, OpenOCDJtagDelay);
#ifdef BUSPIRATEV4
                for (UART1TXSent = 2100; UART1TXSent < (2100 + UART1TXAvailable); UART1TXSent++) {
                    UART1TX(bpConfig.terminalInput[UART1TXSent]);
                };
#endif
                break;
            default:
                buf[0] = 0x00; // unknown command
                buf[1] = 0x00;
                binOpenOCDAnswer(buf, 1);
                break;

Re: Bus Pirate firmware v6.1 development

Reply #10
Thanks JTR, I will try to test, and also invite robots to give some feedback.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate firmware v6.1 development

Reply #11
[quote author="JTR"]Possible changes required to openOCD.c. Not tested but it is a starting point and by some fluke it may actually work.

Note the the asm code will need to be changed so as to NOT transmit the TX data, instead just buffer it until it RETURNS.
[/quote]

Just buffering will make it slow. The beauty of the original design is, that it can transfer data back to host while still receiving and processing incoming data. (not just buffering them).

I think the idea would be to put the data into the "output" buffer. When usb is ready it would just take the processed chunk.
This would require minimal changes to the asm routine.

Re: Bus Pirate firmware v6.1 development

Reply #12
If 0.03 seconds per 2100 bytes less time saved is blowing the budget then of course it would be easy enough to re arrange the code like that. It would be my instinct to do that even though I cannot agree (having done some basic math) that it will make the BPV4 "slow." Possibly marginally slower, like one second over 64kB.

However, the other side of the coin is that it is not "faster" like it could be. The BPv4 should blow the BPv3 away if the transfers are interleaved. The USB coms aught to be 2.5 - 3x faster plus time saved by dumping the UART ISR plus the extra 4MIPS to play with.

Everything else I have done with the IR TOY and the BPv4 goes to some length to double buffer and interleave all the transfers and there are plenty of examples showing the code. If that could be ported to within the ASM code that would be fantastic.

Re: Bus Pirate firmware v6.1 development

Reply #13
I am not really familiar with the USB and CDC code used in BP firmware. Is there some documentation of the USB stack implementation ? I have just briefly looked at the code and there are few things i don't understand:
- Why is the (fast)usb_handler called from user code ?
- is the timer T1 needed? The code could have been triggered by USB SOF interrupt.

The original Openocd code I have written is here (C implementation):
http://code.google.com/p/the-bus-pirate ... nOCD.c#310

This one can be easily modified to use UART1RX and UART1TX functions. (the new USB buffered functions, wouldn't work reliably with the UART peripheral). I just hope that JTAG won't mind the jitter introduced by the USB code.

Re: Bus Pirate firmware v6.1 development

Reply #14
[quote author="robots"]I am not really familiar with the USB and CDC code used in BP firmware. Is there some documentation of the USB stack implementation ? I have just briefly looked at the code and there are few things i don't understand:
- Why is the (fast)usb_handler called from user code ?
- is the timer T1 needed? The code could have been triggered by USB SOF interrupt.
[/quote]

The USB stack needs to be serviced periodically, to ensure that setup packets are not blocked as this is a requirement of the USB spec. We also need to clear the USB TRNIF flag that is set after every usb transaction otherwise the PICs USB FIFO will fill and then block any and all new transfers. That is why there is a sprinkling of calls to the USB handler that generally have a one to one relationship to each packet we send or receive. If we put the USB stack on interrupts we do not need to call the handler but the effect of this is that we surrender deterministic timing for our I/O routines and this is not desirable IMHO. By polling the usb stack we can interleave the stack servicing in "dead time."

Regarding the use of T1, this is simply a throw back to the way both early versions of the BPv4 and IR TOY were coded when they used the microchip stack. It is not necessary and indeed the SOF can be used. I have long removed the use of T1 from the IR TOY and the BPv4 will follow at some stage.

At this time the usb stack used on the BPv4 is an earlier version and somewhat outdated. However it works and I imagine that slowly over 2012 it will be updated to use the latest and greatest stack now that many niggles are understood and the differences in how the stack needs to work in different ways between the IR TOY and BPv4 are accounted for.
 
[quote author="robots"]
The original Openocd code I have written is here (C implementation):
http://code.google.com/p/the-bus-pirate ... nOCD.c#310

This one can be easily modified to use UART1RX and UART1TX functions. (the new USB buffered functions, wouldn't work reliably with the UART peripheral). I just hope that JTAG won't mind the jitter introduced by the USB code.[/quote]

I cannot see any grounds for your concerns. You seem to be overlooking that even on the BPv3 the comms goes through an FTDI chip and this also is going to turn a data stream into packets and introduce some amount of "jitter." Perhaps at this point I will point out that by default the FTDI chip wait 16ms before sending back short packets.

16ms!


Nowhere in any dangerous prototypes documentation is this even mentioned. Can't be that much of a problem now, can it?

As it is the BPv4 firmware will execute 160 instruction cycles in the time it takes the BPv3 to receive 1 (ONE!) byte via the UART. And the BPv4 is receiving packets of 64 Bytes and is double buffered. "Jitter" on the BPv4??

At worst on the BPv4 there is a one off 0.5ms average overhead cost for the whole block of data whether it is one byte or 1MB. Compare that to the accumulated overhead of having to send two extra bits per byte via the hardware UART, plus the ISR and at only 1Mb/s. Run the BPv4 through a USB 2.0 hub and that average overhead will be around 64us. Again, as for the FTDI latency timer setting, I have not seen anyone discuss the use of a USB 2.0 hub and its effects on transfer times.

I would suggest the best way to intergrate the OCD code into the BPv4 is to break the asm file up to handle chucks of 64 bytes and call it in between packet arrivals and departures in the C code. That way you don't need to worry about the usb part and the slight additional overhead may well be less than the overhead savings by the elimination of the ISR.