Beiträge anzeigen
Diese Sektion erlaubt es ihnen alle Beiträge dieses Mitglieds zu sehen. Beachten sie, dass sie nur solche Beiträge sehen können, zu denen sie auch Zugriffsrechte haben.
Nachrichten - brainwash
1
Ok, maybe someone can edit the wiki and add the entries (I don't have the rights) to add BusPirate to supported hardware. The only thing that needed change was the base communication baudrate from the default 115200.
Cookbook:
- connections: GND to GND, Betty TX to MISO, Betty RX to MOSI. I also connected the 3.3V lines together, but it might not be needed
- open the terminal to BusPirate, press 'b' (baudrate), '7' (38400), close the terminal
- open a new terminal but with the baudrate set to 38400, press space
- to enter the UART transparent bridge macro type: 'm' '3' '7' '1' '1' '1' '2' '(1)' 'y' (everything should be default except last item which is 2)
- download the lpctool version with the fixed 38400 baud rate (
http://bettyhacks.com/forum/index.php?topic=241.msg1667#msg1667 )
- flash as usual: lpctool -d /dev/com4 -e -i -a boop_rom.bin
2
I'm sorry to be answering to my own messages (in English nonetheless) but this is a problem that's very common and not properly described anywhere on the Internet.
During 2007-2010 a lot of USB-RS232 cables based on a FAKE Prolific PL2303HX chip circulated around. It seems that I am also the unhappy owner of one.
The syndrome is that you cannot get it to work in Windows 7/8 with the official drivers, it just shows an Error 10 in the device manager and something with 'insufficient virtual memory'. The solution for this is to search for something like Prolific AllInOne GPS driver from 2008.
Under normal operation everything works fine but in some cases (like lpctool) software compiled with cygwin libraries and not the .NET ones from Microsoft exhibit a flushing problem. This manifests itself as the application missing the last one or sixteen characters on RX or not transmitting the last ones on TX. There is a discussion thread somewhere with Prolific acknowledging the problem and fixing it in later driver revisions. The serial libraries from .NET have also been updated (as far as I know) to flush earlier or after a time-out. Don't quote me on that.
However, the fake chips cannot be updated to any driver after 2008 because it causes the error 10 "device cannot start" in Device Manager. So you are pretty much stuck and having to buy another cable if you depend on this flushing functionality.
Again, under normal use - serial println debugging, flashing firmwares for routers and oscilloscopes, null-modem - you shouldn't see this problem. I have been using the cable for the past 5 years and haven't noticed any problems until now.
3
I think I've traced at least one problem to the chipset & software combination.
printInfoS(2,"initiating auto-baud",0);
sendBuf(sprintf(buf, "?\r\n"), buf);
printInfoS(2,"awaiting autobaud response",0);
On my scope I can see that braking the program with Ctrl+C during this waiting loop the characters get transmitted, but not before. This means that the PL 2303 [fake?] chipset buffers the TX characters and does not flush them.
4
I took apart a USB-Serial cable based on Prolific PL2303HX and manually soldered the RX, TX, RTS, DTR signals to the chipset.
In RealTerm I can trigger the RTS and DTR pins to bring the device into bootloader mode, if I press "?" I get back "Synchronized". However, lpctool gets stuck at "awaiting autobaud response", NXP tool cannot open the port, BettyHeaven does not list the serial port at all. Under a WinXP Virtual Machine lpctool behaves the same, NXP times out, BettyHeaven again does not list the port, RealTerm works.
I can see that lpctool pulls the DTR line low, so reset works. I manually bridge the BL pin to ground before running the tool. I tried both the normal version of lpctool and the one limited to 38400 baud.
Is there any other way to flash the chip? I will download a Linux VM and try with that but I assume the Prolific chip is not properly supported by any of these tools.
Maybe I have a different bootloader?
BettyHHUbootloader 00006420 00B770ED 1MByte
BIOS 00006420 000179B4 617EE0AD
no new BIOS
BIOS 000179B4 617EE0AD
starting BIOS...
Betty HHU BIOS 00B770ED 1MB
Current build 25632, last build 25632
*** FONT 25632 F
*** WAVE 12900
*** HW V2
This is the final firmware for Betty. There will be no further updates.
*** FLASH 1C5B
*** System up and running
5
Sorry for hijacking this thread in English, please feel free to respond in German, I will try to understand.
I'm trying to program the remote using the Bus Pirate and cannot get anywhere. What I've tried so far:
- UART bridge in 38400 baud using the recompiled lpctool. It gets stuck at "awaiting autobaud response"
- avrdude with "buspirate" device configuration and ATTiny13 (as shown in wiki). It receives a 0x000000 chip signature
- avrdude with STK500 clone firmware on the bus pirate (communication error)
- a standard USB-UART cable I had lying around (I think it requires a level inverter)
I'm putting the remote in BL mode as described in the Wiki: put batteries into remote, it boots into normal mode, connect BL to GND, connect RST to GND, wait two seconds, disconnect RST, disconnect BL. The remote is showing a blank screen and in the UART terminal (38400 baud) I see that upon pressing the enter key I get some kind of echo (but it does not look like \r\n) and another character like "Ü".
For the avrdude I connected CS to RST and CLK to BL, everything else normal. The RX and TX are not reversed because I see the boot traces.
Can someone advise me how to proceed with this? I have ordered a USB-TTL transceiver but it will take a while until I receive it.
