hackdabetty

[cheristi]

Die englischsprachigen Kollegen von hackdaworld haben sich auch schon ein bisschen ans auseinanderschrauben gemacht.

http://www.hackdaworld.org/cgi-bin/awki.cgi?edit=true&page=BettyTV

Da is zwar die gleiche Nummer wie auf meinem Display angegeben, aber ansonsten finde ich dazu nix im Netz.

Hat jmd dazu schon was rausgefunden?

[cheristi]

Nachdem das mit dem bearbeiten bei mir nich tut,
hier der echte link
http://www.hackdaworld.org/cgi-bin/awki.cgi/BettyTV

#grs

[Spessi]

Hab ich das richtig verstanden? Er kann jetzt Firmware über den TX und RX Pin in den RAM der Fernbedienung laden, wenn er den Bootloader-Pin kurzschließt?
Jetzt müssen die nurnoch das Format der Firmware rauskriegen und können dann 'ne eigene Firmware schreiben? Na dann..!

[theborg]

Hi das Format der Firmware ist das standad intel HEX Format welches für jeden protzi benutzt wird.

Hab mir die Tools mal runter geladen und compiliert 3 Dateien davon sind fast lehr nur das Programm zum Flaschen läuft ich werde mir mal von NXP nen testcode runter laden und versuchen den zu flaschen.

[cheristi]

Ähm, ich glaube die Dateien sind nur Platzhalter.


Man bekommt die compilierten Datein ja im Moment gar nich auf die Betty, dank dem Bootloader..

#grs

[theborg]

jo leider ich denke ich werde mir nochmal nen usb-JTAG bauen und versuchen den direkt an den prozi anschlissen mal sehn ob das wenigstens klapt

[kackhart]

hallo!

Ähm, ich glaube die Dateien sind nur Platzhalter.

ja genau! die werden schon noch gefuellt ... hoffentlich.

Man bekommt die compilierten Datein ja im Moment gar nich auf die Betty, dank dem Bootloader..

also mit dem lpcload.c kann ich nun (seit gestern!) in den ram schreiben. hatte noch ein paar probleme mit dem uuencoden. man sollte nicht nur einfach schnell den algo aus wikipedia nach c uebersetzen, sondern mal genauer lesen .

man haette es sich sicher auch einfacher machen koennen. selbst fuer linux gibt es ja schon einige firmware loader ...

das lpcload tool liest nur intel hex files.

ich moechte nun doch erstmal die original fw auslesen. die fwbc firmware soll dies tun. leider schaffe ich es zz nichtmal dass sie mir einfach immer 0x23 bei 9600 baud 8n1 via uart0 ausgibt. sollte das problem in naechster zeit mal bewaeltigt sein, muss man hoffentlich nur noch einen init() fuer das externe memory interface schreiben und kann dann anfangen auszulesen (das geht ja im gegensatz zum schreiben wahrscheinlich noch sehr einfach) und das zeug via uart raushauen. fwdump soll den kram dann in ein file auf den pc schreiben. (die leeren files ersetzen einfach nur meine todo :p)

wer ideen hat warum der arm code (fwbc.c) nicht tut ... bin sehr dankbar!

gru3,

frank

[kackhart]

Hab ich das richtig verstanden? Er kann jetzt Firmware über den TX und RX Pin in den RAM der Fernbedienung laden, wenn er den Bootloader-Pin kurzschließt?

ja genau. aber wieso so verwundert? steht ja auch so in der lpc2220 doku, oder?

habe noch nicht so viel lesen koennen, aber generell wird hier ein bisschen viel panik gemacht.

ist doch alles wohldefiniert! auch wie man mit dem bootloader reden muss steht da drin!

gru3,

frank

[kackhart]

3 Dateien davon sind fast lehr nur das Programm zum Flaschen läuft ich werde mir mal von NXP nen testcode runter laden und versuchen den zu flaschen.

also in den flash schreiben kann der bootloader nicht. du kannst eine firmware in den ram hauen, diese kann dann den flash schreiben oder lesen. steht auch in der doku.

wenn ihr windows habt, solltet ihr einfach mal diesen keil kram ausprobieren. damit sollte das egtl funktionieren. selbst fuer linux gibt es wie gesagt auch schon schoenere tools die man wahrscheinlich nur minimal umhacken muss (part id hinzufuegen). ich bin mir sicher, die keil software hat bestimmt auch schon firmware dabei, die dann den code ins flash schreiben kann.

wie oben schon gesagt, die leeren files werden hoffentlich bald voller.

gru3,

frank

[Spessi]

Hab deine Datei lpcload.c eben mal unter Cygwin compiliert und die Exe ausgeführt - allerdings bekomm ich

Code: [Auswählen]

boot loader init ...
  >> ? | 3f | (1)
txrx read: bad return byte '3f'
zurückgeliefert. Liegt es daran, dass mein TTL-Wandler ab und zu mal rumspinnt oder liegt es einfach daran, dass das Programm unter Windows garnicht gehen KANN?

gruß

[kackhart]

hi

Hab deine Datei lpcload.c eben mal unter Cygwin compiliert und die Exe ausgeführt - allerdings bekomm ich

Code: [Auswählen]

boot loader init ...
  >> ? | 3f | (1)
txrx read: bad return byte '3f'
zurückgeliefert. Liegt es daran, dass mein TTL-Wandler ab und zu mal rumspinnt oder liegt es einfach daran, dass das Programm unter Windows garnicht gehen KANN?

komisch. er scheint das '?' zu echo'en. das sollte er nicht tun. er muesste mit "Synchronized" antworten. kann es sein, dass du eint1 nicht mit gnd verbunden hast?

tx und rx an max232, gnd von max232 an gnd und eint1 vom arm, dann batterien rein. danach das lpcload starten. sollte dann sowas kommen:

Code: [Auswählen]


$ sudo ./lpcload -d /dev/ttyS0 -f fwbc.hex -v
boot loader init ...
  >> ? | 3f | (1)
  << Synchronized.. | 53 79 6e 63 68 72 6f 6e 69 7a 65 64 0d 0a | (14)
  >> Synchronized.. | 53 79 6e 63 68 72 6f 6e 69 7a 65 64 0d 0a | (14)
  << OK.. | 4f 4b 0d 0a | (4)
  >> 10000.. | 31 30 30 30 30 0d 0a | (7)
  << OK.. | 4f 4b 0d 0a | (4)
write firmware to ram ...
writing 0x10 bytes to 0x40000200
  >> W 1073742336 16.. | 57 20 31 30 37 33 37 34 32 33 33 36 20 31 36 0d 0a | (17)
  << 0.. | 30 0d 0a | (3)
  >> ##<"@.. | 23 23 3c 22 40 0d 0a | (7)
  >> #X0#8.. | 23 58 30 23 38 0d 0a | (7)
  >> #+>D$.. | 23 2b 3e 44 24 0d 0a | (7)
  >> #L$SB.. | 23 4c 24 53 42 0d 0a | (7)
  >> #!-!-.. | 23 21 2d 21 2d 0d 0a | (7)
  >> !X@  .. | 21 58 40 20 20 0d 0a | (7)
  >> 2081.. | 32 30 38 31 0d 0a | (6)
usw ...


ausserdem natuerlich schauen das lpcload aktuell ist. wurde ja gestern noch gefixed (fast, aber wenigstens sowas wie hier solltest du sehen*). ob windoes probleme macht kann ich leider nicht sagen ...

*) wer schon weiter gekommen ist und spaeter probleme beim daten schreiben bekommt, moege die note in meinem wiki beachten:

note: funnily enough (sometimes) the tool just works properly after having started minicom ... (maybe some serial port config issue, dunno!)

dann geht es aber! ja ich weiss, alles sehr unsauber. war aber nie fuer enduser gedacht.

gru3

frank

[Spessi]

Du arbeitest mit dem Max232? Ist der nicht nur für 5V ausgelegt?

PS: du hast ne PN

[theborg]

mal ne blöde frage das makefile geht bei mir nicht wie kommt ihr zum hex file ?

ah habs jetzt fehlt mir nur die blöde header datei finde die mit googel net

EDIT: habs

[kackhart]

Du arbeitest mit dem Max232? Ist der nicht nur für 5V ausgelegt?

die 3v(?) von tx genuegen anscheinend. rx scheint auch 5v auszuhalten. an vcc des max232 selbst lege ich 5v an. gnd von der 5v spannungsquelle und vom arm muss man natuerlich kurz schliessen.

[kackhart]

hi theborg!

EDIT: habs

hast evtl schon eine idee was ich bei dem fwbc verbockt habe, dass da nur muell vom uart kommt?

muell = À€øø€€ø€xü€x€ usw.

wenn man von dem 10mhz quarz ausgeht sollte die baudrate mit 65 als divisor doch 9k6 baud sein ...

mfg, frank