Hackbarer(?) 21 EUR Quadcopter

Philipp E. schrieb:
> Ne, das wollte ich aber noch tun. Wollte aber vorher fragen, ob die
> Traces soweit vollständig sind. Wie war der Status als das Logging
> gestartet wurde und wie als es Endete? Also für das File: SPI traffic
> during binding.txt
> Vorher: Copter und RC angeschaltet, nichts gedrückt?
> Nachehr: Binding abgeschlossen?

Das Log fängt direkt mit dem Einschalten der FB an. Im ersten Teil sieht 
man daher schön, wie die Register des BK2423 initialisiert werden. Die 
Aufzeichnung endet noch während der Binding-Phase.

Tim    schrieb:
> Wir sollten uns tatsächlich mal Gedanken
> machen, wie man das ganze strukturiert angeht.

+1

Finde die Aufteilung sinnvoll. Wobei vermutlich jeder etwas 
unterschiedliche Prioritäten hat. Aber das macht ja nix, jeder kann sich 
das Schnappen worauf er Lust hat. Ich bin sehr an Punkt 2) bis 4) 
interessiert, wenn denn mein Copter endlich mal ankäme.

@Torsten: Gibt es eigentlich schon neues von den China Händlern bzgl. 
Mengenrabatt?

Tim    schrieb:
> 2) Endlich den Copter entsperren (Das BU-link müsste langsam mal
> angekommen)

Bin ja hin und her gerissen. Habe überlegt mir auch einen BU-Link zu 
bestellen, auf der anderen Seite wäre es für die Community sicher 
genial, wenn das auch ohne geht. Sobald er da ist, hängst du aber direkt 
den LA dran und schickst uns nen Trace vom Unlocken ;-)

Tim    schrieb:
> Wenn man einige Optionen nicht
> mitcompiliert passt die Firmware bereits jetzt in 16kb.

Kannst du noch einmal posten wo genau es den Arm Port gibt? Welche 
Optionen hast du ausgeschaltet?

Tim    schrieb:
> Die Aufzeichnung endet noch während der Binding-Phase.

Könntest du noch mal einen Trace aufzeichnen, der die gesamte Binding 
Phase abdeckt?

Ach ja, ich habe noch eine Frage zur IDE. Ihr verwendet alle Keil, oder? 
Damit kann man dann den SWD Port vom Discovery Board direkt mit dem 
Copter verbinden und Debuggen und Flashen (wenn er denn nicht mehr 
gelockt wäre). Ist das soweit korrekt? Welche Einstellungen haben sich 
dazu als korrekt rausgestellt? Und welche Keil Version?
Ist das, was in 
https://github.com/hackocopter/Examples/tree/master/Blinky-CMSIS
liegt als Grundlage (also vom Keil-Projekt her) geeignet?

Philipp E. schrieb:
> Tim    schrieb:
>> Wenn man einige Optionen nicht
>> mitcompiliert passt die Firmware bereits jetzt in 16kb.
>
> Kannst du noch einmal posten wo genau es den Arm Port gibt? Welche
> Optionen hast du ausgeschaltet?

https://github.com/trollcop/bradwii

Habe in den Defines alles deaktiviert, was sowieso nicht unterstützt 
wird und anschließend manuell das Konfigurationsinterface ausgebaut 
(Checkboxes, EEPROM code usw.).

Philipp E. schrieb:
> Tim    schrieb:
>> Die Aufzeichnung endet noch während der Binding-Phase.
>
> Könntest du noch mal einen Trace aufzeichnen, der die gesamte Binding
> Phase abdeckt?

Habe die Verbindungen leider schon wieder entfernt. Ich gehe aber davon 
aus, dass es da keine Überraschung gibt. Es wird einfach vom Binding in 
den normalen Modus umgeschaltet.

Philipp E. schrieb:
> Tim    schrieb:
>> 2) Endlich den Copter entsperren (Das BU-link müsste langsam mal
>> angekommen)
>
> Bin ja hin und her gerissen. Habe überlegt mir auch einen BU-Link zu
> bestellen, auf der anderen Seite wäre es für die Community sicher
> genial, wenn das auch ohne geht. Sobald er da ist, hängst du aber direkt
> den LA dran und schickst uns nen Trace vom Unlocken ;-)

Das wird das Allererste sein :)

Philipp E. schrieb:
> gelockt wäre). Ist das soweit korrekt? Welche Einstellungen haben sich
> dazu als korrekt rausgestellt? Und welche Keil Version?

µVision5 mit legacy device support.

> Ist das, was in
> https://github.com/hackocopter/Examples/tree/master/Blinky-CMSIS
> liegt als Grundlage (also vom Keil-Projekt her) geeignet?

Ich denke schon. Das sind die Einstellungen vom Beispielprojekt für den 
MINI54.

Philipp E. schrieb:
> Gibt es eigentlich schon neues von den China Händlern bzgl.
> Mengenrabatt?

Das Problem ist, dass bei einer Einfuhr von mehr als einem Stück in 
jedem Fall Einfuhrumsatzsteuer fällig wird. Dann muss der Händler 
mindestens 20% Rabatt einräumen, damit es pari ausgeht. Das Porto 
innerhalb Deutschlands ist auch nicht zu vernachlässigen (Warensendung € 
1.90). Und Torsten muss die Dinger auch einzeln neu verpacken (Karton € 
0.50). Nun sind wir schon bei weiteren gut 10% die der Händler 
nachlassen muss. Und Torsten hat noch immer keine Entschädigung für 
seine Arbeit. Wenn dann auch nur ein Copter defekt ankommt... ich will 
gar nicht weiter rechnen... aber ich freue mich, wenn es noch klappt 
(ich könnte direkt bei Torsten abholen, 15km Entfernung).

Neben den Daten auf den 16 Hopping-Kanälen schickt die Fernbedienung das 
Gleiche nochmal auf vielen anderen Kanälen. Lauscht man nur an einem 
Kanal erhält man in unregelmäßigen Abständen einen Datensatz (hier 
Channel 2):

1

 125  00 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 FA 

2

 261  00 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 FA  

3

 130  2F 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 29 

4

 512  C1 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 BB  

5

1813  DB 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 D5 

6

 774  1A 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 14  

7

 129  03 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 FD  

8

 126  00 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 FA 

9

 649  00 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 FA

Dann weiß der Empfänger einen Hopping-Kanal und ist schnell in Sync. Es 
gibt aber auch Kanäle (z.B. 0x1f) auf denen kommt nichts.

Wenn die Fernbedienung noch nicht gebunden(?) hat, gibts auf vielen 
Kanälen (auch 0x1f) etwa alle 125ms einen Datensatz:

1

 125  00 00 00 00 00 00 00 44 B0 46 00 00 00 00 C0 FA 

2

 133  00 00 00 00 00 00 00 44 B0 46 00 00 00 00 C0 FA 

3

 125  00 00 00 00 00 00 00 44 B0 46 00 00 00 00 C0 FA 

4

 129  00 00 00 00 00 00 00 44 B0 46 00 00 00 00 C0 FA

Auch hier kann der Empfänger dann die Kanäle ermitteln.

https://bitbucket.org/rivig/v202 schickt zum Binden mehrere 0-Sätze mit 
byte[14]=0xc0 und geht dann in den Normalbetrieb. Mein jd385 bindet aber 
auch wenn [14]==0 ist.

NB: Das Steuern des Helis über Tastatur ist deutlich schwieriger als 
über  die Fernbedienung :-)

Fernbedienung: Für den N79E814 gibt es die Header Files für Keil&Co auf 
der Nuvoton Seite. Man muss aber nach "Demo Code" suchen, nicht nach 
"Header". Die sind in dem Zip versteckt.

Falls der 814 ohne Bootlader in der FB ist (wovon ich ausgehe, auf den 
Pads ist ICP herausgeführt), brauchen wir den Stick von Nuvoton zum 
Programmieren (geschätzt € 30.-). Ich frage bei Nuvoton mal an, ob sie 
das ICP Protokoll herausrücken. Die Hardware wäre simpel.

Georg G. schrieb:
> Das Problem ist...

Stimmt. Sehe ich ähnlich. Allerdings wollen die meisten von uns 
vermutlich mehr als einen Copter (damit werden die Versandkosten pro 
Stück schon einmal geringer). Außerdem könnte ja die Fernbedienung und 
der Lader weggelassen werden, dürfte auch noch mal ein klein bisschen 
was bringen. Abschließend kann ich das nicht beurteilen.
Aber wenn es tatsächlich 100 Stück für 900 € inkl. Versand geben sollte, 
dann ergibt sich bei Abnahme von 5 Stück pro Person:
9 € * 1,25 (Zoll + Ust.) = 11,25 € + 0,75 € (Versand und Verpackung 
[3,75 € / 5]) = 12,00 € pro Stück. Das wäre schon Attraktiv. Wenn 
Torsten jetzt noch 2 € als Profit / Puffer draufschlägt ist es immer 
noch 10 € billiger als bei eBay und damit wären locker 15 Defekte Copter 
abgedeckt. Weiterhin sollte klar sein, dass Torsten nicht dafür 
verantwortlich ist, wenn die Dinger defekt sind.

Auf der anderen Seite ist das natürlich alles mit Aufwand und Risiko für 
Torsten verbunden. Auch weiß ich nicht, ob sich wirklich 9 € pro Stück 
erzielen lassen. Und ob hier wirklich so viel Nachfrage besteht ist auch 
fraglich.
Vielleicht kann Torsten kurz mal schreiben, wie seine Pläne 
diesbezüglich sind, andernfalls würde ich mir einfach 5 von den Dingern 
direkt bei eBay klicken.

Bei 100 Stück könnte man vielleicht auch direkt beim Hersteller 
anfragen:

http://www.jxdtoys.com/en/aboutus.asp

Jetzt wird der BU-Link plötzlich nicht mehr angeboten:

http://www.aliexpress.com/store/product/Free-Shipping-NuLink-BuLink-Compatible-Cortex-M0-M051-ISP-ICP-Program/213957_674565728.html

Ich hoffe doch, dass meiner auch wirklich geliefert wird. Langsam 
bekomme ich den Eindruck, dass es vielleicht sinnvoller wäre, die 
Chip-Erase von einem original Nu-Link zu grabben.

Tim    schrieb:
> von einem original Nu-Link zu grabben

Etwas Geduld noch, Bettelbrief um Infos an Nuvoton ist raus. Leider 
kenne ich niemanden, der deren ICs kommerziell einsetzt.

Georg G. schrieb:
> Tim    schrieb:
>> von einem original Nu-Link zu grabben
>
> Etwas Geduld noch, Bettelbrief um Infos an Nuvoton ist raus. Leider
> kenne ich niemanden, der deren ICs kommerziell einsetzt.

Mal schauen, ob Du erfolgt hast. Es gab schon einige Anfregen über das 
Nuvoton-Forum, die leider abgelehnt wurden.

Tim    schrieb:
> Langsam
> bekomme ich den Eindruck, dass es vielleicht sinnvoller wäre, die
> Chip-Erase von einem original Nu-Link zu grabben.

Oh no. Naja, damit muss ich mich wenigstens nicht mehr entscheiden, ob 
ich auch einen bestelle ;-) Hier gab es doch jemanden, der das Original 
hat und damit auch ein Erase durchgeführt hat. Vielleicht könnte er dir 
sein original ausleihen? Oder wir schmeißen hier zusammen und kaufen 
einen "gemeinsam".


Davis schrieb:
> Für das Binding werden keine besonderen Kanäle verwendet. Die
> Fernbedienung sendet einfach in ihrem 16 Kanalraster die Pakete.

Genau. So wie es auch in der Deviation implementiert ist. Habe mein Tool 
minimal angepasst und den anderen Trace ausgewertet. Am Anfang passiert 
ne Menge (Register Set, etc.) Das wird nicht umbedingt alles korrekt 
geparst, aber nach ein paar ms geht es los mit immer dem gleichen 
Packet:

1

0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x1F 0xE4 0x75 0x00 0x00 0x00 0x00 0xC0 0x38

Also alles wie zu erwarten. Nun bin ich etwas verwirrt (mangels Copter) 
wie genau die "Bedienung" ist. Also RC Einschalten und dann Stick nach 
ganz oben? Damit sendet sie das Binding Packet solange bis der Stick auf 
0 geschoben wird?

Und am Copter? Schaut der einfach nach dem Einschalten nach dem ersten 
binding packet oder speichert er an welchen Sender er gebindet ist und 
es gibt am Copter ne Taste o. Ä. um das Binding zu starten?

Davis schrieb:
> Keine Taste. Der Copter schaut nur auf die Pakete die da kommen.

Ah verstehe. Also muss der Copter bei jedem Akku wechsel neu gebindet 
werden?

Jap.

Philipp E. schrieb:
> Genau. So wie es auch in der Deviation implementiert ist. Habe mein Tool
> minimal angepasst und den anderen Trace ausgewertet. Am Anfang passiert
> ne Menge (Register Set, etc.) Das wird nicht umbedingt alles korrekt
> geparst, aber nach ein paar ms geht es los mit immer dem gleichen
> Packet:
> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x1F 0xE4 0x75 0x00 0x00 0x00 0x00
> 0xC0 0x38

Interessant! Auf welchen Kanälen sendet er?

Davis schrieb:
> Auf den 16 Kanälen, die aus der Unique-ID generiert werden.

Also um das hier nochmal heraus zu stellen. Das Channel Hopping ist 
immer gleich egal ob in der "Bind" Phase oder bei der eigentlichen 
Steuerung. Die Sequenz hängt nur von der ID des Senders ab und ist daher 
immer gleich.

Die Bind Phase zeichnet sich nur durch die spezielle Struktur der Pakete 
aus. Damit kann der Copter dann discovern welcher Sender sich binden 
will und kennt dann dessen ID und damit die Hopping Sequenz.

Philipp E. schrieb:
> Die Sequenz hängt nur von der ID des Senders ab und ist daher
> immer gleich.

Also bezogen auf die ID. Die variiert natürlich von Sender zu Sender.

Philipp E. schrieb:
> Oh no. Naja, damit muss ich mich wenigstens nicht mehr entscheiden, ob
> ich auch einen bestelle ;-) Hier gab es doch jemanden, der das Original
> hat und damit auch ein Erase durchgeführt hat. Vielleicht könnte er dir
> sein original ausleihen? Oder wir schmeißen hier zusammen und kaufen
> einen "gemeinsam".

Ich werde wie gesagt auch einen kaufen, sobald mein Quad mal vom Zoll da 
ist, davor hat es keinen Sinn

> Mal schauen, ob Du erfolgt hast. Es gab schon einige Anfregen über das
> Nuvoton-Forum, die leider abgelehnt wurden.

Jop, leider.

Manuel Steiner schrieb:
> Ich werde wie gesagt auch einen kaufen, sobald mein Quad mal vom Zoll da
> ist, davor hat es keinen Sinn

Ach ja, stimmt ja. Super sache. Bitte direkt den LA dran hängen ;-)

Philipp E. schrieb:
> Ach ja, stimmt ja. Super sache. Bitte direkt den LA dran hängen ;-)

Klaro, Robert hat das zwar schon gemacht, aber vielleicht kann man da ja 
noch mehr rausholen. nosilent hat so einen Saleae Clone, und ich habe 
einen Open Bench Logic Sniffer, der sollte rein theoretisch bis 200Mhz 
funktionieren, aber leider nur One Shot und nicht kontinuierlich wie de 
saleae Teile, die den PC als Buffer verwenden.

Ich hoffe es dauert nicht mehr all zu lange.

Manuel Steiner schrieb:
> Robert hat das zwar schon gemacht

Ich dachte irgendwie, der Trace war unvollständig. Habe ich mir das 
falsch gemerkt?

Manuel Steiner schrieb:
> Saleae Clone, und ich habe
> einen Open Bench Logic Sniffer, der sollte rein theoretisch bis 200Mhz

Das ist ja super. Damit müsste sicher ein guter Trace rauskommen.

Philipp E. schrieb:
> Hier gab es doch jemanden, der das Original
> hat und damit auch ein Erase durchgeführt hat. Vielleicht könnte er dir
> sein original ausleihen? Oder wir schmeißen hier zusammen und kaufen
> einen "gemeinsam".

Klar, kein Ding. Hatte ich ja eh schon angeboten. Nachdem ich den 
Controller erased habe, brauche ich das Teil ja erstmal nicht. Sagt mir 
nur wo ich ihn hin schicken soll.

Robert Knipp schrieb:
> Klar, kein Ding. Hatte ich ja eh schon angeboten.

Wahnsinn. Danke! Klasse Sache!!!

Da mein Copter noch nicht da ist, nützt mir das gute Stück leider im 
Moment nichts. Ich denke Tim wäre ein guter Ansprechpartner, falls er 
Zeit und Lust hat. Die Sache mit dem BuLink ist ja etwas ungewiss atm 
;-)

Ich habe noch einmal etwas im Thread gelesen und habe da noch einmal 
eine Frage. Du hast gesagt, du hast den Chip wieder gelockt und dann 
mittels ICP unlockt und erased. Hast du mit deinem LA eine Aufzeichnung, 
die dieses unlock + erase vollständig  auf allen relevanten Leitungen 
Kommunikation gespeichert hat? Weil, ich hatte es damals so verstanden, 
dass dein LA immer irgendwann die Aufzeichnung abgebrochen hat.

Danke schonmal für deine Mühe!

Philipp E. schrieb:
> Ich habe noch einmal etwas im Thread gelesen und habe da noch einmal
> eine Frage. Du hast gesagt, du hast den Chip wieder gelockt und dann
> mittels ICP unlockt und erased. Hast du mit deinem LA eine Aufzeichnung,
> die dieses unlock + erase vollständig  auf allen relevanten Leitungen
> Kommunikation gespeichert hat? Weil, ich hatte es damals so verstanden,
> dass dein LA immer irgendwann die Aufzeichnung abgebrochen hat.

Genau, der hat die Aufzeichnung selbstständig abgebrochen. Keine Ahnung 
warum. Ist auch das erste mal dass ich mit nem LA etwas mache. Daher 
fehlt mir da noch etwas die Erfahrung. Daher verleihe ich auch gern den 
NuLink. Ihr könnt damit wohl erstmal mehr anfangen als ich.

Haben will schrieb:
> Ist das der richtige?

Ja.

Viel billiger als "PayPal" ist "Kredietkarte" nach wie vor nicht:

http://www.aliexpress.com/item//1082441152.html

Haben will schrieb:
> Will mir so 3 bis 5 von den Dingern shoppen.

Der übliche Hinweis: Einen nach dem anderen kaufen. Erst wenn der eine 
auf "versendet" steht, den nächsten.

Alles was am gleichen Tag aus China abgeschickt wird, kann vom Zoll 
zusammen addiert werden, und dann zahlst Du drauf!

Haben will schrieb:
> Aber eine Sammelbestellung gibt es jetzt nicht, oder?

Kann noch kommen, dann aber ohne Fernbedienung. Das Problem: 
Einzeln_ohne_Zoll mit Fernbedienung ist vielleicht billiger als eine 
Sammelbestellung mit_Zoll und ohne Fernbedienung.

Robert Knipp schrieb:
> Philipp E. schrieb:
>> Hier gab es doch jemanden, der das Original
>> hat und damit auch ein Erase durchgeführt hat. Vielleicht könnte er dir
>> sein original ausleihen? Oder wir schmeißen hier zusammen und kaufen
>> einen "gemeinsam".
>
> Klar, kein Ding. Hatte ich ja eh schon angeboten. Nachdem ich den
> Controller erased habe, brauche ich das Teil ja erstmal nicht. Sagt mir
> nur wo ich ihn hin schicken soll.

Hallo Robert, vielen Dank für das Angebot. Ich würde gerne mein Glück 
versuchen. Du bekommst eine PM von mir.

Tim    schrieb:
> Jetzt wird der BU-Link plötzlich nicht mehr angeboten:
>
> 
http://www.aliexpress.com/store/product/Free-Shipping-NuLink-BuLink-Compatible-Cortex-M0-M051-ISP-ICP-Program/213957_674565728.html
>
> Ich hoffe doch, dass meiner auch wirklich geliefert wird. Langsam

Oh!
Habe neulich auch einen geordert. Wurden soviel bestellt das die schon 
ausverkauft sind? Der Anbieter hat etliche Programmier-Interface im 
Angebot.
Mal nachhaken.

So, mein NuLink ist auf dem Weg zu Tim. Vielleicht kommt er damit ja 
weiter.

Robert Knipp schrieb:
> So, mein NuLink ist auf dem Weg zu Tim. Vielleicht kommt er damit ja
> weiter.

Ich bin schon gespannt!

Davis schrieb:
>> Wurden soviel bestellt das die schon ausverkauft sind?
>
> Es sieht so aus, dass die Firma nicht mehr existiert.
> Die Webseite ist ist nicht erreichbar: http://www.betemcu.cn

Die Website ging schon vorher nicht. Den Aliexpress-shop gibt es aber 
noch. Nur bietet man das Produkt nicht mehr an.

Hi,

das Teil ist m. E. doch sehr schwer zu steuern. Also einen Schwebeflug 
auf konstanter Höhe in einem Raum kaum möglich. Das Teil haut immer nach 
den Seiten ab, auch wenn ich versuche zu trimmen....

Habe mir besseres erwartet :-(

Kalle S. schrieb:
> das Teil ist m. E. doch sehr schwer zu steuern. Also einen Schwebeflug
> auf konstanter Höhe in einem Raum kaum möglich. Das Teil haut immer nach
> den Seiten ab, auch wenn ich versuche zu trimmen....

Meiner ist ziemlich stabil. Schaue mal hier: 
Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter" und weitere...

Tim    schrieb:
> Kalle S. schrieb:
>> das Teil ist m. E. doch sehr schwer zu steuern. Also einen Schwebeflug
>> auf konstanter Höhe in einem Raum kaum möglich. Das Teil haut immer nach
>> den Seiten ab, auch wenn ich versuche zu trimmen....
>
> Meiner ist ziemlich stabil. Schaue mal hier:
> Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter" und weitere...

Danke
Werde ich mal probieren.

Frage : habe schon jemand ein anderes Netzteil fündig Akkus probiert?

Turbonator schrieb:
> Meine beiden sind da ich musste 9euro zoll zahlen :)

Dann hast Du wohl beide zusammen bestellt?

> geht ja noch 50€
> die kopter

War aber nicht nötig, der einzelne Copter wäre ganz legal ohne Kosten 
durchgegangen.

Bei Käufen aus Fernost (oder Fernwest) immer die 22€-Grenze (bzw. 
5€-Grenze für Gebühren) für EUst im Auge behalten. Sammelbestellungen 
lohnen sich da fast nie. Lieber zwischen den Bestellungen ein paar Tage 
oder Wochen warten. Ansonsten frisst die fällig werdende EUst den 
Preisvorteil auf.

...

Hannes Lux schrieb:
> Lieber zwischen den Bestellungen ein paar Tage oder Wochen warten.

Wie lange denn nun? ;)

Torsten C. schrieb:
> Einen nach dem anderen kaufen. Erst wenn der eine
> auf "versendet" steht, den nächsten.

@Hannes: Nicht gelesen oder anderer Meinung?

Disclaimer: Es geht nicht ums "Recht haben", sondern darum, was später 
im Wiki steht.

PS: Noch ein Wort zum Wiki: Im China-Billig-Thread ist das Wiki gerade 
"gestorben",
siehe Beitrag "SUPER Bauteile-Schnäppchen WIKI"

Ich hoffe, dass Ihr beim WIKI mit macht, und nicht alles an mir allein 
hängen bleibt. Im Moment muss ich erstmal etwas pausieren. Ausreden:

1. Meine Familie will, dass die LED-Leiste an der Wohnzimmerdecke
   endlich fertig wird (rechte Hälfte, Bild).

2. Ich muss endlich das Lochraster-Layout fertig machen, siehe
   Beitrag "Gitter-Drill (Trennstellen)"

3. Das Aquariumforum quengelt wegen eines LED-Strip-PWM-Dimmers:
   http://www.aquariumforum.de/threads/350068-sammelpost-rigid-stripes-test-fragen-beckenvorstellungen/page11?p=2346959&viewfull=1#post2346959

Das muss nun erstmal erledigt werden. Sorry.

Habe heute um Mitternacht den Nu-Link von Robert im Briefkasten 
gefunden. Das ging ja wirklich schnnell!

Viel dran ist nicht. Ich habe mal Bilder der Platine gemacht.

Der Prozessor wurde erkannt. Auch wurde sofort gefragt, ob ich einen 
Chip erase durchführen will. Der Chip erase selbst dauert sehr lange, 
wobei eine sehr große Menge Daten über SWD geschaufelt werden, wie auf 
dem Screenshot zu sehen.

Anbei ein Log des Datenaustausches zur Identifikation des Chips. Das Log 
des Erase-Vorgangs ist >100mb gezippt. Wo könnte ich das hochloaden?

Ich muss jetzt erst einmal schlafen. Evtl. finde ich morgen noch etwas 
Zeit.

Hm,
was wird da wohl in dem Flash drin stehen?

Kannst du den auslesen? Vielleicht steht da die VID/PID drin. Wobei man 
dazu ja anscheinend meist bei billigen Sachen nen EEPROM benutzt.

Achso das File geht das nicht auch bei github rein?

Torsten C. schrieb:
> @Hannes: Nicht gelesen oder anderer Meinung?

Gelesen sicher, aber wieder vergessen, denn ich lese die Threads nicht 
in einem Stück, sondern immer mal wieder die neuesten Beiträge. Da gerät 
sowas schon mal in Vergessenheit.

Anderer Meinung bin ich diesbezüglich nicht. Nur kann oder will man 
nicht immer warten, bis der erste Artikel da ist. Dazu ist die Ware 
einfach zu lange unterwegs.

...

Hannes Lux schrieb:
> Nur kann oder will man
> nicht immer warten, bis der erste Artikel da ist.

Nee, da würde man ja kirre werden. Das hat m.E. auch niemand 
vorgeschlagen.

Tim    schrieb:
> Habe heute um Mitternacht den Nu-Link von Robert im Briefkasten
> gefunden. Das ging ja wirklich schnnell!

Super. Nochmal vielen vielen Dank an Robert!

Tim    schrieb:
> Anbei ein Log...

Klasse, auch dir tausend Dank, das du direkt den LA dran gehängt hast!

Tim    schrieb:
> Wo könnte ich das hochloaden?

Pack es zur Dropbox (https://www.dropbox.com). Der Account ist schnell 
angelegt und Speicher ist genug da. Nachteil: Die NSA hat dann den Log 
vom Erase...

Tim    schrieb:
> Erase-Vorgangs ist >100mb

Mhhh, damit wird das ganze vermutlich etwas komplexer als gedacht. Was 
könnten das wohl alles für Daten sein. Vielleicht ist es erst einmal das 
eigentliche unlocking und danach wird dann wie bei Keil ein Erase Tool 
in den Flash / Ram vom uC geschaufelt? Könnte es weiterhin sein, dass 
der Erase vlt. so lange braucht weil es viel zu löschen gibt? Kannst du 
den Chip noch einmal locken (aber sonst leer lassen) und noch mal das 
Unlock + Erase aufzeichnen? Weiterhin wäre ein reines Erase auf einem 
nicht gelockten (und ebenfalls leeren) Chip interessant. Ach ja, eine 
Frage noch: Kommt eigentlich auch was vom Chip zurück? Oder sendet der 
ICP nur?

Torsten C. schrieb:
> Im Moment muss ich erstmal etwas pausieren.

Mach dir keinen Stress. Soll doch alles Hobby und Spaß bleiben. Und der 
Wiki Artikel kann ja über die Zeit wachsen. Außerdem muss er ja nicht 
jedes Detail dokumentieren. Je mehr dort steht, umso besser, aber wenn 
etwas dort nicht dokumentiert ist, kann das ja über die Zeit wachsen. 
Der Artikel ist in meinen Augen für den "frühen" Projekt Status schon 
auf einem super weg, ich denke das wird so weiter gehen. Jeder trägt 
bei, was er hat bzw. möchte bzw. kann und dann wird das schon.

Philipp E. schrieb:
> Tim    schrieb:
>> Wo könnte ich das hochloaden?
>
> Pack es zur Dropbox (https://www.dropbox.com). Der Account ist schnell
> angelegt und Speicher ist genug da. Nachteil: Die NSA hat dann den Log
> vom Erase...

Guter Punkt. Einen Account habe ich dort eh. Hier ist das File:

https://www.dropbox.com/s/l4xuxvaw1ielv19/connect%20and%20chip%20erase.zip

Der Rest liegt im GitHub-Repository

https://github.com/hackocopter/Documentation/tree/master/Nu-Link

Hier noch einmal ein paar Details zum Datenverkehr auf dem 
SWD-Interface.

Das SWD-Intarface besteht aus zwei Leitungen: SWDCLK und SWDIO. SWDIO 
ist bidirektional. Die Datenrichtung wird dabei vom Master festgelegt.

Der Chip-ERase Vorgang wird durch eine sehr kurze Sequenz eingeleitet, 
wie auf dem mittleren Bild zu sehen (3). Dann kommt für 25ms nicht. 
Diese Zeit kann eigentlich nur zum Chip-Erase reichen, wenn wirklich das 
ganze Flash gleichzeitig gelöscht wird. Diesen Teil hatte Robert auch 
oben schon einmal gepostet.

Anschließend wird für eine sehr lange Zeit (20s) immer wieder die 
gleiche Sequenz gesendet. Bei mir kam dieser Vorgang immer erst zum 
erliegen, wenn ich auf "disconnect" in der ICP-Software geklickt habe. 
Der Controller war danach trotzdem entsperrt. Daher kann es sein, dass 
die lange Sequenz nicht unbedingt notwendig ist.

p.s. die logfiles kann man mit Saleae Logic öffnen. Die Software ist für 
Testzwecke frei herunterladbar:

http://www.saleae.com/downloads

Torsten C. schrieb:
> PS: Noch ein Wort zum Wiki: Im China-Billig-Thread ist das Wiki gerade
> "gestorben",
> siehe Beitrag "SUPER Bauteile-Schnäppchen WIKI"
>
> Ich hoffe, dass Ihr beim WIKI mit macht, und nicht alles an mir allein
> hängen bleibt. Im Moment muss ich erstmal etwas pausieren. Ausreden:

Hi Torsten,
ich denke das Wiki wird sich von ganz alleine weiterentwickeln. Du hast 
ja schon einen sehr guten ersten Schritt gemacht. Man sollte nur 
häufiger darauf hinweisen dass es den Eintrag auch gibt. Daher hier noch 
einmal der Link auf den Artikel:

http://www.mikrocontroller.net/articles/Hack-O-Copter

Das wichtigste ist dass die Leute zum Artikel beitragen wenn sie Lust 
haben. Wenn vorher zu viele Regeln festgelegt werden schreckt das nur 
ab. Aufräumen kann man später immer noch.

Informationen zu SWD und freie Implementierungen sind immer noch recht 
spärlich. Hier einmal das, was ich bisher gefunden habe:


Im MCHCK-Projekt gibt es eine SWD bit-bang Minimalimplementierung. 
Leider alles ziemlich wenig dokumentiert:

https://mchck.org/
https://www.evernote.com/shard/s13/sh/2557f123-e1fd-4d04-b053-0adac1945c74/6343ffac964a01863d817690f27bbfb5
https://github.com/mchck/mchck/tree/master/bootloader/swd-adapter/swduino

Dann natürlich Versaloon:
http://www.versaloon.com/

Black Magic probe:
http://www.blacksphere.co.nz/main/blackmagic
https://github.com/gsmcmullin/blackmagic

SWD Einführung
http://www.lpcware.com/content/blog/introduction-cortex-serial-wire-debugging-part-one

Hier noch Links von Manuel Steiner 
(Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter") damit alles an 
einem Platz ist:

Ich hab letztens mal libswd gefunden:

http://sourceforge.net/apps/trac/libswd

Das ist eine SWD Library. Auf dieser Seite waren unter anderem folgende
Dokumente zu SWD verlinkt:

http://www.arm.com/products/system-ip/debug-trace/...
http://www.arm.com/files/pdf/Low_Pin-Count_Debug_I...

An die genaue Spezifikation kommt man wahrscheinlich nur als ARM Partner
:/

Edit: Die ARM Debug Interface Architecture Specification könnte noch
interessant sein. (Kapitel 5.2)

http://www.pjrc.com/arm/pdf/doc/ARM_debug.pdf

Ohne genaue Kenntnis des SWD Protokolls wird es fast unmöglich sein, die 
gesuchten Befehle zu finden. SWD ist bidirectional, wie soll man aus dem 
Mitschnitt erkennen, was der Nulink gesagt hat und was die Antwort war?

Tim    schrieb:
> Edit: Die ARM Debug Interface Architecture Specification

Genau das hat mir gefehlt! Super. Nun den Mitschnitt als Folge von 
Nullen und Einsen (positive Flanke von SCK ist Abtastzeitpunkt) und mit 
ein paar Zeilen Code kann man es grob aufdröseln.

Anbei die Daten von oben als Binary dump.
Jedes Byte ist ein Sample bei 16MHz Abtastfrequenz. Bit0 =SWData 
Bit1=SWCLK.

Man kann die Daten auch nur Abschnittsweise oder in anderen Formaten aus 
Logic exportieren.

Ich hatte noch nicht so viel Zeit, mich mit der Interpretation zu 
beschäftigen. Was mir bisher aufgefallen ist:

- Da die clk nur vom Host kommt, hängt die Gültigkeit der Daten von der 
Richtung des Datentransfers ab:
  Host->Target   steigende Flank von Clk
  Target->Host   fallende Flanks von Clk

Das sieht man auch gut in dem SWD Bitbanging Source, der oben verlinkt 
ist.

1

static void

2

write_bits(uint8_t buf, size_t bits)

3

{

4

        pin_configure(SWD_DIO_PIN, SWD_MODE_OUTPUT);

5

        for (; bits > 0; --bits, buf >>= 1) {

6

                pin_write(SWD_CLK_PIN, 0);

7

                pin_write(SWD_DIO_PIN, buf & 1);

8

                pin_write(SWD_CLK_PIN, 1);

9

        }

10

}

11

12

static void

13

read_bits(size_t bits, int silent)

14

{

15

        uint8_t val = 0;

16

17

        pin_configure(SWD_DIO_PIN, SWD_MODE_INPUT);

18

        size_t bit;

19

        for (bit = 0; bit < bits; ++bit) {

20

                pin_write(SWD_CLK_PIN, 0);

21

                val |= !!pin_read(SWD_DIO_PIN) << bit;

22

                pin_write(SWD_CLK_PIN, 1);

23

        }

24

        if (!silent)

25

                reply_write(&val, 1);

26

}

Hi,

Der NuLink wird eine Unlock Sequenz senden und danach darauf warten bis 
der Chip mit dem Flash-Löschen fertig ist. In dieser Zeit pollt er den 
SWD um eine Statusmedllung zu erhalten
Läuft doch beim STM32 auch so. Ein Chip-Unlock löscht immer das gesamte 
Flash, das dauert eben etwas.

Versuche zu identifizieren was in der langen Leer Phase passiert und 
teile die ganze Übertragung in drei Teile. Unlock -> Status polling -> 
Antwort.

Gruß Martin

Tim    schrieb:
> - Da die clk nur vom Host kommt, hängt die Gültigkeit der Daten von der
> Richtung des Datentransfers ab:
>   Host->Target   steigende Flank von Clk
>   Target->Host   fallende Flanks von Clk

Bild 6 in "LPC Debug Interfaces" sagt, dass die Daten immer mit der 
steigenden Flanke gültig sind, egal, wer sendet.

Bild 5-1 in der ARM Debug Spec sagt, dass es immer die fallende Flanke 
ist, egal, wer sendet.

Nun darfst du dir aussuchen, was richtig ist :-)

(Abgesehen davon: Der von dir gezeigte Code Ausschnitt verwendet immer 
die steigende Flanke, das Target legt nach der fallenden Flanke die 
Daten an. Man wartet etwas und zeigt mit der steigenden Flanke, dass man 
gelesen hat und Target bitte das nächste Bit bereit stellen möge.)

> Der NuLink wird eine Unlock Sequenz senden und danach darauf warten bis
> der Chip mit dem Flash-Löschen fertig ist. In dieser Zeit pollt er den
> SWD um eine Statusmedllung zu erhalten
> Läuft doch beim STM32 auch so. Ein Chip-Unlock löscht immer das gesamte
> Flash, das dauert eben etwas.
>
> Versuche zu identifizieren was in der langen Leer Phase passiert und
> teile die ganze Übertragung in drei Teile. Unlock -> Status polling ->
> Antwort.

Hi Martin,

das kann gut sein. Es Großteil des Datenverkehrs scheint nur aus der 
"line reset sequence" (50x CLK während IO high ist) zu bestehen. 
Wahrscheinlich wartet der Adapater einfach nur darauf, dass das Target 
eine gültige Antwort zurück sendet.

Siehe auch 5.4.1
http://www.pjrc.com/arm/pdf/doc/ARM_debug.pdf

Direkt am Anfang macht er bereits 4x einen Line-Reset, ohne dass eine 
Antwort zu kommen scheint.

Georg G. schrieb:
> (Abgesehen davon: Der von dir gezeigte Code Ausschnitt verwendet immer
> die steigende Flanke, das Target legt nach der fallenden Flanke die
> Daten an. Man wartet etwas und zeigt mit der steigenden Flanke, dass man
> gelesen hat und Target bitte das nächste Bit bereit stellen möge.)

Ja, aber dadurch ändern sich die Daten auf/nach der steigenden Flanke 
und sind damit dort nicht gültig. Im LA Log kann das durchaus zu 
Glitches führen, wie man an ein paar Stellen sehen kann.

So morgend werde ich dem Zoll die Rechnung schicken und dann ist das 
Teil hoffentlich auch bald hier und dann brauch ich keinen "Blindflug" 
bezüglich der Hardware mehr zu machen.

No y. schrieb:
> was wird da wohl in dem Flash drin stehen?
>
> Kannst du den auslesen? Vielleicht steht da die VID/PID drin. Wobei man
> dazu ja anscheinend meist bei billigen Sachen nen EEPROM benutzt.

Das ist ein 16mbit Device. Da wird wohl etwas mehr drin gespeichert sein 
als nur VID/PID. Nur was? Auslesen will ich es lieber nicht, ich will 
den NU-Link nicht beschädigen.

chris schrieb:
> x
> parity error header x
>  ack = 1  SWD(1) DAP Write  = 0x997dec09
>  ack = 1 data parity error
>  SWD(1) DAP Write  = 0x197ccc09
>  ack = 7  SWD(2) DAP Write  = 0xf3181332

Ich habe mir inzwischen noch einmal einige Stellen das Protokolls per 
Hand angeschaut. Es wird sehr lange einfach nur "Line Reset" und "Read 
IDCODE" gesendet, worauf das Target nicht zu antworten scheint. Erst 
ganz am Ende des "ID-Device" blocks findet eine gültige Kommnukation 
statt. Ich habe diesen Bereich mal ausgeschnitten und angehängt.

Übrigens musste ich zur Auswertung des Anwort des Targets tatsächlich 
die fallende Flanke auswerten, da es manchmal am Übergang Glitches gab. 
Evtl. müsstest Du das in Deinem Code auch berücksichtigen.

Der Screenshot zeigt ein "READ"-Feld, in dem das Target sendet. Manchmal 
hat der LA einen Übergang auf der steigenden Flanke gesampled, machmal 
danach.

chris schrieb:
> Nur zur schnellen Erklàrung:
> parity error header  --  discard bit and repeat header parsing.
> Ack error -- Protocol error, no answer from target
> data parity error -- parity error on 32bit data field.

Also wenn ich das richtig verstehe, ist das Log auf dem Post oben aus 
einem Bereich wo das Target nicht antwortet.
t.

> Ich will noch einen Filter fuer die Raw Daten reinmachen,
> und dann anstelle oder zusàtzlich zum derzeitigen Debug Ausgabe
> ein Replay C File generieren damit man dann testen kann, ob man dies

Ich fürchte ja fast, dass es nicht ausreicht, einfach nur die 
Signalsequenz zu wiederholen. Es ist wohl notwendig, die 
Registerzugriffe zu extrahieren und mit einem simplemen SWD-Treiber 
wieder abzuspielen. Aber zum Glück ist das Low-Lowevel Protokoll ja 
relativ einfach.

> mit irgendeiner CPU raufspielen kann, ungeachtet aller Timings.
> Hier mein derzeitiger Code , der Rueckgabewert ist die Anzahl der bits
> to discard, data ist 64bit bitstream Variable als einziges Argument der
> Funktion.

Wie extrahierst Du denn "data"? Wie oben geschrieben, müsste man das 
evtl. Kontext-Sensitiv tun. Was machen "lsb" und "parity"?

P.s.: Ich habe per Hand den IDCODE 0x0BB11477 ermittelt. Dabei stimmt 
die Vendor Id in [11:] = 0x23B, allerdings ist die Device ID in [27:12] 
mit 0xBB11 evtl. nicht richtig.

Tim    schrieb:
> ganz am Ende des "ID-Device" blocks findet eine gültige Kommnukation
> statt. Ich habe diesen Bereich mal ausgeschnitten und angehängt.

Tim    schrieb:
> ganz am Ende des "ID-Device" blocks findet eine gültige Kommnukation
> statt. Ich habe diesen Bereich mal ausgeschnitten und angehängt.

Hier ist auch die Datei.

Zum Thema "Daten erfassen":

SWD ist bis 50MHz Takt spezifiziert. Das sind 20ns. Da wird es also 
keine langen Haltezeiten geben. Unmittelbar nach der gültigen Flanke ist 
das Signal schon wieder weg.

Eine asynchrone Aufzeichnung müsste also mit 100MHz erfolgen. Das ist 
unrealistisch und ergibt einen Wust an Daten.

Der Saleae kann auf Flanke triggern. Also warum nicht die Datenerfassung 
auf der positiven Clock Flanke machen? Eventuell zusätzlich zwei 
Inverter zwischen Nulink-Takt-Ausgang und Board-Takt-Eingang schalten, 
den Saleae mit seinem Trigger Kanal am Nulink. Das könnte 10ns 
Sicherheit geben (in der Hoffnung, dass der Nulink etwas Haltezeit für 
die Daten hat).

Bei der Gelegenheit die Frage, ob jemand den User Guide für Saleae 
Version 1.0.21 hat. Online kommt leider die falsche Version, die im GUI 
etwas anders ist. Ich kann mir die Funktionen denken, bin an einigen 
Stellen aber nicht sicher.

Simon schrieb:
> Hat jemand eigentlich schonmal die arduino Software von
> 
https://bitbucket.org/rivig/v202/src/c2142a790c463abff9004b761e013cff6735f50b/V202_arduino/?at=default
> mit dem copter ans laufen bekommen?
> Ich hab da jetzt mal ein bisschen mit rumgespielt (atmega328p +
> nrf24l01) aber bei
> mir bindet der copter nicht mit der Software. :-\

Ich glaube Helmut hat das hinbekommen, wenn ich seine Bemerkung richtig 
interpretiere.

Helmut H. schrieb:
> https://bitbucket.org/rivig/v202 schickt zum Binden mehrere 0-Sätze mit
> byte[14]=0xc0 und geht dann in den Normalbetrieb. Mein jd385 bindet aber
> auch wenn [14]==0 ist.
>
> NB: Das Steuern des Helis über Tastatur ist deutlich schwieriger als
> über  die Fernbedienung :-)

Magst Du uns verraten, was Du hier gemacht hast? :)

Georg G. schrieb:
> Bei der Gelegenheit die Frage, ob jemand den User Guide für Saleae
> Version 1.0.21 hat. Online kommt leider die falsche Version, die im GUI
> etwas anders ist. Ich kann mir die Funktionen denken, bin an einigen
> Stellen aber nicht sicher.

Ist nicht 1.1.15 die neuste Version?

Tim    schrieb:
> Ist nicht 1.1.15 die neuste Version?

Das ist richtig. Aber ich suche den alten User Guide.

Habs mit dem Original nicht probiert, aber müsste eigentlich wenn man 
einen der #if 0 für die Definition der txid's zu #if 1 macht
Mit dem angehängten Testprogramm, das davon geklaut ist, gehts mit 
uint8_t txid[3] = { 0xcd, 0x31, 0x71 } bei meinen beiden Helis.

* Stromlosen Heli mittels handelsüblichen Nähgarns(z.B. "Sternzwirn 
hohreißfest") so an einer Unterlage befestigen, so dass er sich zwar 
bewegen, aber nicht entkommen kann
* Software auf Arduino starten (benutze 8 für CE und 9 für CSN)
* Terminal mit 115200
* tippe H für Hopping-Kanäle aus der o.a. txid berechnen
* tippe s für senden, man sieht die gesendeten Werte von buf[0] bis 
buf[3]
* Heli stromversorgen
* Warten bis er langsam blinkt
* tippe b für Binden, das schickt einfach 50 bind-Sätze.
* Heli LEDs bleiben an
* Üben mit +, -, i,j,k,m. Das ändert throt um 10 (von 0-255), roll und 
pitch um 4 (von 0x19 ..0 oder ox80 ..0x9f)
* Leertaste setzt alle Werte wieder auf 0 zurück.
* Nähgarn durchschneiden

Mit anderen txids funktioniert das Binden nur manchmal, habe mich aber 
nicht weiter darum gekümmert.
N.B: Interessante Erfahrung, wenn Programmier- oder Bedienungsfehler 
sofort mit Schmerzen bestraft werden. Beabsichtige dies als "Taktile 
Feedback Driven Super Agile Software Development" zu vermarkten.

@Simon: schön dass es funktioniert.
Simon schrieb:
> Helmut: könntest Du noch deine  RF24.h/cpp, RF24_config.h und nRF24L01.h
> posten? Das wäre super.
Nur der Vollständigkeit halber: Erforderlich sind die aktuellen Dateien 
von  https://github.com/maniacbug/RF24 nach libraries/RF24. Habe nichts 
daran geändert.

Gibt es mittlerweile etwas neues vom Bu-Link?

Oder von den analysierten Unlock Sequenzen?

Das neue über den von mir bestellten Bulink ist, dass er noch nicht da 
ist :-(

Turbonator schrieb:
> Bei mir sind 80 meter möglich, 200-500m wären gut .

Ich habe es bisher noch nicht geschafft die Reichweite zu überschreiten.
Wie denn auch? Wenn er so weit weg ist sieht man ihn sowieso nicht mehr, 
das einzige was man damit erreichen würde wäre, dass er unkontrollierbar 
(da fast nicht mehr sichtbar) irgendwo abstürzt.

Heute hat mir der Postmann Flattermaxe Nummer 3 gebracht, aber vom 
Bulink noch keine Spur :-(

Ich habe leider in den letzten Tagen keine Zeit gefunden, mich weiter 
mit dem copter zu beschäftigen. Das wird sich aber hoffentlich wieder 
ändern.

Nur kurz ein paar Kleinigkeiten:

- Das Bu-Link ist immer noch nicht da.
- Programmieren mit dem Nu-Link funktioniert wunderbar. Das CMSIS-Blinky 
ist jetzt auch auf richtiger Hardware erprobt. Auch die Ausgabe über die 
serielle Schnittstelle funktioniert:

https://github.com/hackocopter/Examples/tree/master/Blinky-CMSIS

-Die Platinen für den LiPO-Charger sind angekommen. Leider konnte ich 
ihn noch nicht testen, da mir das IC noch fehlt. Aus einem mir 
unerfindlichen Grund hat OSH-Park mir sogar die doppelte Anzahl an 
Platinen geschickt. Daher würde ich an die ersten drei, die mir ihre 
Adresse per PM schicken, eine abgeben. Bitte nur anfragen, wenn ihr 
später auch hier über euren Aufbau berichtet :)

https://github.com/hackocopter/LiPoCharger

-Bezüglich der Chip-Erase Sequenz habe ich mir überlegt, eine Low-Level 
SWD Implementierung zu programmieren. Mit den Beispielen und der 
Dokumentation ist das nicht sonderlich kompliziert, hilft aber auch das 
Protokoll besser zu verstehen. Außerdem ist dann die Software zum 
Unlocken gleich mit fertig.

Philipp E. schrieb:
> Kannst du
> den Chip noch einmal locken (aber sonst leer lassen) und noch mal das
> Unlock + Erase aufzeichnen? Weiterhin wäre ein reines Erase auf einem
> nicht gelockten (und ebenfalls leeren) Chip interessant.

chris schrieb:
> Es waere hilfreich, zwei komplette Logs zu haben, einmal von einem
> ungesperrten Baustein, und einmal von einem welcher looked ist und
> testen,
> ob es da differenzen gibt.

Glaube auch das die beiden Logs zusammen sehr hilfreich wären. Dann 
könnte man das SWD darin parsen und schauen was dann noch für Waveforms 
übrig bleiben.

chris schrieb:
> Es waere hilfreich, zwei komplette Logs zu haben

Aber bitte nicht wieder mit freilaufendem Takt sondern auf die positive 
Flanke getriggert.

Philipp E. schrieb:
> kann mir jemand sagen, was das für ein Connector

Im "nRF24LU1 Reference Design" (was anscheinend die 2.4G NRF24lu1p
china dongle ist)

http://www.freqchina.com/en/down.asp?ID=102

ist ein adapter kabel gezeigt "nRF24LU1 USB Dongle Programming adapter
cable", die passende buchse ist in der BOM als "JST BM05B-SRSS-TB"
gelistet. Der stecker ist also JST SH familie, 5pin, 1mm pitch.

Ok, weiter gehts. Hier sind ein paar neue Logs:

->connect__protected_device_-disconnect

Verbinden und Verbindung wieder trennen. Read protect ist gesetzt.

->connect-chip_erase-disconnect

Verbinden, Chip erase und disconnect. Read protect war gesetzt.

->connect-program_fuses_to_protect-erase-disconnect

Verbinden, Read protect fuse setzen und disconnt. Read protect war nicht 
gesetzt.

Bit 0- SWDIO
Bit 1- SWDCLK
Bit 2- Reset (wird nie ausgelöst)

Georg G. schrieb:
> chris schrieb:
>> Es waere hilfreich, zwei komplette Logs zu haben
>
> Aber bitte nicht wieder mit freilaufendem Takt sondern auf die positive
> Flanke getriggert.

Das kann der LA leider nicht. Das Triggering bezieht sich wirklich nur 
auf den Startzeitpunkt der Aufzeichnung. Danach wird einfach nur 
gesampled. Dafür haben die ganzen "professionellen" LA nicht die 
Speichertiefe.

Letztendlich bin ich aber immer noch davon überzeugt, dass das Protokoll 
nicht darauf angewiesen ist, innerhalb eines sehr kleinen Zeitfensters 
zu samplen. Für so etwas wäre auf der Host-seite dedizierte Hardware 
notwendig. Das Nu-Link, und wahrscheinlich die meisten anderen 
SWD-Adapter auch, nutzt anscheinend die GPIO Pins an einem normalen 
Mikrocontroller per "Bit-Banging" Daher ist es gar nicht möglich, ein 
Clock-Signal auszugeben und gleichzeitig auf einer Flanke zu sampeln.

Kommt man vielleicht schneller weiter, wenn man per USB-Sniffer die 
Kommunikation zum NuLink mitschneidet? Nur ein Gedanke ...

chris schrieb:
>> Wie extrahierst Du denn "data"? Wie oben geschrieben, müsste man das
>> evtl. Kontext-Sensitiv tun. Was machen "lsb" und "parity"?
>>
> Vom binary dump durch das Programm swd_dat generiere ich eine Datei,
> welche
> den Bitstream enthàlt, bei steigender Flanke von clk.
> Ich lese diesen Bitstream dann in der Variable data ein, Msb first.
> Aus diesem Grunde gibt es die Funktion lsb(len,offset,data) welche den
> lsb first Wert aus data zurueckgibt. Parity gibt das parity bit zurueck.

Wie schon oben geschrieben, ich denke hier liegt m.E. das Problem. 
Daten, die vom Target gesendet werden, müssten auf der nachfolgenden 
fallenden Flanke ausgelesen werden. Das Einlesen der Daten und der 
Protokollanalyzer lassen sich demnach nicht trennen.

Torsten C. schrieb:
> Kommt man vielleicht schneller weiter, wenn man per USB-Sniffer die
> Kommunikation zum NuLink mitschneidet? Nur ein Gedanke ...

Damit würden sich bestimmt einfach binärdaten abfangen lassen. Aber der 
Befehl, den der Computer an das NU-Link zum Löschen sendet kann ziemlich 
beliebig sein. 42? 請刪除該芯片? "kill them all"?

Tim    schrieb:
> "kill them all"?

THIS!

Tim    schrieb:
> Das kann der LA leider nicht

Dann muss man mit einem Flipflop zwischen Nulink-Daten und 
Analyser-Daten nachhelfen, damit die Daten immer zur Flanke passen. Mit 
freilaufendemTakt kommt es schnell zu Schmutzeffekten. Aber vielleicht 
haben wir ja Glück.

Ich habe den SWD-Analyzer von Chris etwas erweitert. Aktueller Stand 
anbei.

- Bug: Read und Write waren verwechselt
- Bug: lsb(...) wurde bei mir nicht richtig compiliert, da Maskierung 
nicht long long war
- Neu: rising udn falling edge werden ausgewertet
- Neu: Analyse in einem Durchgang

Leider ergeben die Logs immer noch nicht so recht viel Sinn. Sie sind 
voll von erfolglosen versuchen, den SWD-Port zu resetten. Ich werde 
später weiter machen, vermute aber langsam, dass es doch einfacher ist, 
sich über eine SWD-Implementierung heranzutasten. Welche Sequenz für 
Chip-Erase verantwortlich ist, lässt sich ja einkreisen.

Tim    schrieb:
> Ich habe den SWD-Analyzer von Chris etwas erweitert.

Bitte noch etwas mehr erweitern:
<string.h> mit dazu.
Funktionen, die nichts zurück geben als void definieren.

Dann meckert LCC32 auch nicht mehr :-)

Georg G. schrieb:
> Ich habe den SWD-Analyzer von Chris etwas erweitert.
>
> Bitte noch etwas mehr erweitern:
> <string.h> mit dazu.
> Funktionen, die nichts zurück geben als void definieren.

Du meinst, ich sollte den Source lieber in das Repository laden? :)

Ist schon geschehen:
https://github.com/hackocopter/SWD-Hacking

mingw-gcc ist übrigens ziemlich schmerzfrei.

Tim    schrieb:
> mingw-gcc

Mag sein. Aber nichts hält sich hartnäckiger als Software, mit der man 
seit mehr als 10 Jahren problemlos arbeitet.

Ich würde die typedefs auch anders machen, mit Typen aus stdint.h, also 
nicht z.B. short int sondern int16_t. Ist defensiver.

Und immer noch kein Copter gekommen...

Georg G. schrieb:
> Tim    schrieb:
>> mingw-gcc
>
> Mag sein. Aber nichts hält sich hartnäckiger als Software, mit der man
> seit mehr als 10 Jahren problemlos arbeitet.
>
> Ich würde die typedefs auch anders machen, mit Typen aus stdint.h, also
> nicht z.B. short int sondern int16_t. Ist defensiver.

chris scheint K&R C zu programmieren, ich halte mich eher an 
Ansi-C90/C95. Was Du siehst ist eben der resultierende Mischmasch. 
Einige casts mit long long haben mir auch ziemliche Probleme bereitet. 
Werde ggf. den Source noch aufräumen, aber im Moment ist mir die 
Funktion wichtiger. Die int-typen sind wahrscheinlich C99?

Sensation! Obiges lag gerade in der Post. Die Nuvoton-Tools haben es als 
Nu-Link erkannt und die Software auf den neusten Stand gebracht. Es 
scheint sich also um einen kompatiblen Clone zu handeln. Jetzt müsste es 
nur wieder lieferbar sein...

Ich bin mit dem Entschlüsseln des Protokolls auch entscheidend weiter 
gekommen. Später mehr.

Tim    schrieb:
> s
> scheint sich also um einen kompatiblen Clone zu handeln. Jetzt müsste es
> nur wieder lieferbar sein...

Wow, das hört sich ja wirklich toll an. Aber schade, dass der jetzt 
nicht mehr lieferbar ist.

Ich glaube die Post wollte mir heute meinen Quad auch endlich bringen, 
bin gespannt auf morgen.

So, jetzt funktioniert der SWD-Analyzer. Es wird der komplette 
Datenverkehr ohne Bit- und Paritätsfehler geparsed. Erstaunlicherweise 
funktioniert das mit 16M Samplerate sogar noch bei 4Mhz SWD-Clock.

https://github.com/hackocopter/SWD-Hacking/tree/master/SWD-Analyzer

Ein nerviges Problem war die Gültigkeit der Daten vom Target. Es stimmt 
natürlich, dass diese bei der steigenden CLK-Flanke herausgeclocked 
werden. Durch die Gatterlaufzeit im Target, erscheinen die Daten 
natürlich verzögert am Ausgang, was im LA zu glitches führt. Was mich am 
Anfang verwirrt hat, ist dass die Daten bereits im vorhergehenden 
Taktzyklus herausgeclocked werden. Dafür gibt es die Turnaround cycles.

Ich habe das Problem jetzt gelöst, in dem ich die Daten an der 
vorhergehenden fallenden Flanke einlese. Aus dem Timing sieht man, dass 
das Nu-link selbst wohl genau das gleiche macht. Ein Flip-Flop hätte 
auch funktioniert, wie Georg oben schon angemerkt hat.

So, die Herausforderung besteht jetzt natürlich darin, die Chip-Erase 
Sequenz zu isolieren. Falls jemand mitpuzzeln will - ich habe hier ein 
paar Logs als Rohdaten und nach dem Parsen abgelegt:

https://github.com/hackocopter/SWD-Hacking/tree/master/Nulink-Logs

Ich habe bereits einen heißen Kandidaten für die Chip-Erase Sequenz 
identifiziert. Direkt nach dieser Sequenz ist der Chip nämlich für 140ms 
"tot" und wird über einen Registerzugriff und die Resetsequenz gepollt. 
Die Sequenz beginnt mit einem Reset. Möglicherweise handelt es sich 
daher also um den Relevanten Teil.

Die höheren Ebenen des SWD-Protokolls wirken auf mich ziemlich wirr. 
Einen Masterplan scheint es beim Design nicht gegeben zu haben. Ich 
frage mich, welche Randbedingungen hier relevant waren. Der Zugriff auf 
die tatsächlichen Funktionsregister erfolgt zweifach indirekt, wie im 
Bild.

Dies sind die besten SWD-Referenzen:

http://sourceforge.net/apps/mediawiki/stm32primer2swd/index.php?title=Main_Page#SWD_Packet_Construction

http://www.pjrc.com/arm/pdf/doc/ARM_debug.pdf

Hier der Kandidat für die Chip-Erase Sequenz.

Geschafft! Ich habe die Chip-Erase Sequenz extrahieren können. Damit ist 
es jetzt möglich, den Microcontroller ohne Bu-Link/Bu-Link zu 
programmieren. Noch einmal vielen Dank an Robert für das zur Verfügung 
stellen des NU-Links. Und an chris, georg und die anderen für die Hilfe.

Das ganze ist aber noch aufwändiger geworden als gedacht. Um mit der 
Datenflut etwas anfangen zu können, habe ich auch noch die derüber 
liegende Ebene, nämlich die Speicherzugriffe, geparsed.

Der aktuelle Source ist hier:
https://github.com/hackocopter/SWD-Hacking

Durch den Vergleich von unterschiedlichen Logs habe ich die 
Chip-Erase-Sequenz finden können. Anbei das kommentierte Log der 
Sequenz. Der Relevante Teil ist unten. Eigentlich ist es recht einfach. 
Die Chip-Erase Sequenz wird natürlich über die Flash-Register 
kontrolliert. Es gibt anscheinend ein undokumentiertes Enable-Register 
(0x5000C01C) und einen Undokumentierten Befehl (0x26) für das ISP 
Command register.

1

@3315.698313ms:Read  Buf(0x5000c000)=0x00000032     ; ISP control 

2

@3315.738438ms:Write BD (0x5000c000)=0x00000033    ; ISP Control=0x33 Set bit 1= Enable ISP function... really?

3

@3315.767938ms:Read  Buf(0x5000c000)=0x00000000

4

@3315.927375ms:Read  Buf(0x5000c01c)=0x00000000

5

@3315.967688ms:Write BD (0x5000c01c)=0x00000001    ; 0x5000C01C=1 Interesting. Undocumented register in Flash controller 

6

@3315.997188ms:Read  Buf(0x5000c01c)=0x04770021    ; Buffer after write - "unpredictable"

7

8

@3316.156188ms:Read  Buf(0x5000c000)=0x00000033

9

@3316.232000ms:Read  Buf(0x5000c000)=0x00000033    ; check ISPFF=0

10

@3316.400563ms:Read  Buf(0x5000c010)=0x00000000    ; ISP not busy?

11

@3316.527437ms:Write BD (0x5000c00c)=0x00000026     ; ISP Command=0x26. Undocumented combination. Enable page erase and program

12

@3316.556938ms:Read  Buf(0x5000c00c)=0x04770021    ; Buffer after write - "unpredictable"

13

@3316.595000ms:Write BD (0x5000c004)=0x00000000    ; ISP Address=0x00000000 Start of APROM

14

@3316.624500ms:Read  Buf(0x5000c004)=0x00000000

15

@3316.748562ms:Write BD (0x5000c010)=0x00000001    ; ISP Trigger=1 -> Start ISP Operation

16

@3316.778125ms:Read  Buf(0x5000c010)=0x00000000    ; First read is invalid? better replicate or trouble looms

17

@3316.852250ms:Read  Buf(0x5000c010)=0x00000001    ; Operation is ongoing during ISP Trigger reads 

18

19

... poll poll poll ...

20

21

@3326.586938ms:Read  Buf(0x5000c010)=0x00000001

22

@3326.664813ms:Read  Buf(0x5000c010)=0x00000001

23

@3326.742625ms:Read  Buf(0x5000c010)=0x00000001

24

@3326.820500ms:Read  Buf(0x5000c010)=0x00000001

25

@3326.898375ms:Read  Buf(0x5000c010)=0x00000000    ; and done. After ~10ms

26

@3327.060438ms:Read  Buf(0x5000c000)=0x00000033    ; check ISPFF=0

Die große Frage ist jetzt natürlich wie man das am besten Umsetzt. Weiss 
jemand, ob sich die Befehlssequenz z.B. über ein Script in 
Keil/OpenOCD/etc. abbilden liesse?

Eine andere Möglichkeit wäre eine kleine SWD-Implementierung auf einem 
Microcontroller, die nichts anderes tut als zu überprüfen ob das 
richtige Device angeschlossen ist und ein chip erase durchzuführen. Im 
Vergleich zum parsen des Logs erscheint das fast trivial, aber diese 
Woche nicht mehr... :)

SWD ist übrigens ein ganz schreckliches Protokoll. Und das Nu-Link ist 
eine noch schlimmere Umsetzung davon -> Glitches, übles Timing und 
redundante Zugriffe.

Tim,

könntest Du bitte mal erklären wie Du vorgegangen bist. Mit dem LA den 
Datenstrom aufzeichnen ist klar. Ich bin nur nicht durchgestiegen wie Du 
das Protokoll jetzt rekonstruiert hast. Muss jetzt nicht jedes kleinste 
Detail sein. Aber so ein paar Stichworte, für jemanden, der sich mit uC 
einigermaßen auskennt aber nicht mit Protokollanalyse, wären super.

Also bei Keil und dem JLink lassen sich Scripte eingeben mit Delay, 
Write/Read Register usw...

Da die ST-Link ja abgespeckte  J-Links sind denke ich mal es geht..


Was mich jetzt mal interessieren würde ist was sonst noch so in dem 
"versteckten" Register für Bits gesetzt werden können..!?


Mein 2. Flattermaxe von Tonnse_mall ist heute angekommen!


Edit: Würde mich auch mal interessieren..

Den Bu-Link scheint es ja auch hier noch zu geben. Ich versteh nur das 
Kauderwelsch nicht.
Meiner von aliexpress ist leider noch nicht da :-(

Für 13 Euro
http://de.imendit.com/item/bu-link-really-is-fully-compatible-with-the-nu-link-emulator-offline-download-full-version-12369014346.html

Für 9 €
http://de.imendit.com/item/the-the-bu-link-compatible-nu-link-emulator-full-version-offline-download-new-don-the-numicro-m0-16901419914.html

No y. schrieb:
> Mein 2. Flattermaxe von Tonnse_mall ist heute angekommen!

Wann bestellt? Ich warte auch auf Post von denen.

Georg G. schrieb:
> No y. schrieb:
>> Mein 2. Flattermaxe von Tonnse_mall ist heute angekommen!
>
> Wann bestellt? Ich warte auch auf Post von denen.

und gut drei Stunden nach dieser Mail war er auch hier. Und er fliegt 
sogar :-)

Ich werde dann mal versuchen, die LCD Ansteuerung im Sender zu verstehen 
(sie ist aktiv).

So mein Quad ist heute auch von der Post geholt worden. Ich werde also 
nun auch etwas aktiver sein, hoffentlich :)

Aber zu fliegen ist das Teil am Anfang ja wirklich schwer

Mal ne andere Frage:

Ich hab meinen gerade auseinandergenommen und wieder zusammengeschraubt. 
Wie viele der Schrauben hatten denn danach bei euch noch richtig Biss?

Erstmal ganz großes Lob und vielen vielen Dank für die tolle Arbeit!!!

Tim    schrieb:
> Eine andere Möglichkeit wäre eine kleine SWD-Implementierung auf einem
> Microcontroller, die nichts anderes tut als zu überprüfen ob das
> richtige Device angeschlossen ist und ein chip erase durchzuführen.

Haben die Jungs vom McHck nicht eine SWD implementierung gezimmert? 
Könnte eventuell als Grundlage dienen...
https://github.com/mchck/mchck

Davis schrieb:
> Es hindert dich niemand den Link von dir und die Infos von Tim
> zusammenzuführen.

Doch. Noch nicht angekommener Copter. Frau. Kinder. Job. Zeit...

Philipp E. schrieb:
> Frau. Kinder. Job. Zeit...

Hey, **das** Lied kenn' ich ...

Ich habe den SWD-Analyzer noch einmal etwas überarbeitet.

-C99 Datentypen eingeführt, Source aufgeräumt.
-Verbose level lassen sich jetzt von der Commandozeile auswählen.
-Parsing der AHB-Registerzugriffe verbessert. Dummy-Lesezugriffe werden 
jetzt nicht mehr angezeigt.

https://github.com/hackocopter/SWD-Hacking

Hier sind nach dem Parsing mit der neusten Version die notwendigen 
Zugriffe zum Chip-Erase:

1

@3310.553875ms:Write BD (0xe000edf0)=0xa05f0003   <- Debug Halting Control Reg STOPRead Powercon. Oscillators enabled?

2

@3315.189313ms:Write BD (0x50000100)=0x00000059    ; Unlock registers with magic sequence

3

@3315.256750ms:Write BD (0x50000100)=0x00000016

4

@3315.324187ms:Write BD (0x50000100)=0x00000088

5

@3315.512938ms:Read  Buf(0x50000200)=0x0000001c    ; Read Powercon

6

7

Erase sequence

8

@3315.698313ms:Read  Buf(0x5000c000)=0x00000032     ; ISP control 

9

@3315.738438ms:Write BD (0x5000c000)=0x00000033    ; ISP Control=0x33 Set bit 1= Enable ISP function... really?

10

@3315.927375ms:Read  Buf(0x5000c01c)=0x00000000

11

@3315.967688ms:Write BD (0x5000c01c)=0x00000001    ; 0x5000C01C=1 Interesting. Undocumented register in Flash controller 

12

13

@3316.156188ms:Read  Buf(0x5000c000)=0x00000033

14

@3316.232000ms:Read  Buf(0x5000c000)=0x00000033    ; check ISPFF=0

15

@3316.400563ms:Read  Buf(0x5000c010)=0x00000000    ; ISP not busy?

16

@3316.527437ms:Write BD (0x5000c00c)=0x00000026     ; ISP Command=0x26. Undocumented combination. Enable page erase and program

17

@3316.595000ms:Write BD (0x5000c004)=0x00000000    ; ISP Address=0x00000000 Start of APROM

18

@3316.748562ms:Write BD (0x5000c010)=0x00000001    ; ISP Trigger=1 -> Start ISP Operation

19

@3316.852250ms:Read  Buf(0x5000c010)=0x00000001    ; Operation is ongoing while ISP Trigger reads 

20

21

... poll poll poll ...

22

@3326.742625ms:Read  Buf(0x5000c010)=0x00000001

23

@3326.820500ms:Read  Buf(0x5000c010)=0x00000001

24

@3326.898375ms:Read  Buf(0x5000c010)=0x00000000    ; and done. After ~10ms

25

@3327.060438ms:Read  Buf(0x5000c000)=0x00000033    ; check ISPFF=0  

26

27

@3329.989687ms:Write BD (0x5000c000)=0x00000032    ; Disable ISP

28

@3330.178625ms:Read  Buf(0x5000c01c)=0x00000001

29

@3330.218938ms:Write BD (0x5000c01c)=0x00000000    ; Write 0 to undocumented register

Dann will ich mich auch mal melden, meiner ist nun auch endlich 
angekommen. Bestellt hatte ich am 22.10.2013.

Danke an den Threadstarter!

Ich wäre auch noch an 1-3 stück interressiert, falls es eine 
Sammelbestellung gibt.

Robert Knipp schrieb:
> könntest Du bitte mal erklären wie Du vorgegangen bist. Mit dem LA den
> Datenstrom aufzeichnen ist klar. Ich bin nur nicht durchgestiegen wie Du
> das Protokoll jetzt rekonstruiert hast. Muss jetzt nicht jedes kleinste
> Detail sein. Aber so ein paar Stichworte, für jemanden, der sich mit uC
> einigermaßen auskennt aber nicht mit Protokollanalyse, wären super.

Prinzipiell sind solche Protokolle ja wie eine Zwiebel in mehreren 
Schichten aufgebaut. Ich habe mich dabei von der niedrigsten 
Protokollebene, dem Hardwarelevel immer weiter nach oben gehangelt. 
(Bzw. Chris hat den Anfang gemacht). Am besten schaust Du Dir den Source 
an:

https://github.com/hackocopter/SWD-Hacking/blob/master/SWD-Analyzer/swd_analyzer.c

1) Konvertieren der Samplingdaten in einen Bitstream, der nur Daten auf 
steigenden und fallenden Flanken enthält. (macht getnextperiod())

2) Einteilen des Bitstreams in interpretierbare Dateneinheiten. Dazu 
habe ich zunächst nur geschaut, ob sich gültige Befehle (Reset-Sequenz 
oder Read/write) im Bitsream befinden und wie lang diese sind. Das 
geschieht in der Hauptschleife. Dazu wird bei SWD- Lese- und 
Schreibzugriffen der Header ausgewertet (Bild). Wenn er gültig ist, 
werden die Daten interpretiert, sonst verforfen.

3) Interpretieren und übersetzten der SWD-Befehle (macht swd()).

4) Nachbilden des Memory Access Ports (Bild), um die SWD-Befehle in 
Schreib- und Lesezugriffe auf die Peripherie des Prozesseres zu 
übersetzen. Denn per SWD wird im Grunde nichts anderes gemacht, als den 
Prozessor anzuhalten und auf den Addressraum zuzugreifen. Leider 
geschieht das auf eine extrem umständliche Art. Es gibt z.B. drei 
unterschiedliche Möglichkeiten eine Speicherzelle auszulsen.

Die Daten die auf den unteren Protokollebenen Interpreitert werden, kann 
der Analyzer auch ausgeben. (Kann mit mit -v x einstellen. --help zeigt 
eine Hilfe an).

No y. schrieb:
> Also bei Keil und dem JLink lassen sich Scripte eingeben mit Delay,
> Write/Read Register usw...

Hast Du dazu eine Referenz, oder kennst Du selbst damit aus? Das wäre 
natürlich die beste Lösung, da Keil mit vielen SWD-Adaptern zurecht 
kommt.

No y. schrieb:
> Was mich jetzt mal interessieren würde ist was sonst noch so in dem
> "versteckten" Register für Bits gesetzt werden können..!?

Wahrscheinlich nur das eine, aber Du kannst damit ja mal herumspielen.

> Mein 2. Flattermaxe von Tonnse_mall ist heute angekommen!

Habe heute auch gerade einen von denen bekommen. Komisch, da ist wohl 
ein Container angekommen?

Oliver Stellebaum schrieb:
> Kauderwelsch nicht.
> Meiner von aliexpress ist leider noch nicht da :-(
>
> Für 13 Euro
> 
http://de.imendit.com/item/bu-link-really-is-fully-compatible-with-the-nu-link-emulator-offline-download-full-version-12369014346.html

Das ist ein Taobao-Agent, der sie für Dich von www.taobao.com kauft und 
Dir zusendet. Dort werden auch einige Bu-Links angeboten. Auf den Preis 
kommen noch erhebliche Zusatzgebühren.

Manuel Steiner schrieb:
> Ich hab meinen gerade auseinandergenommen und wieder zusammengeschraubt.
> Wie viele der Schrauben hatten denn danach bei euch noch richtig Biss?

Eigentlich alle? "Nach fest kommt ab" usw. :)

Philipp E. schrieb:
> Haben die Jungs vom McHck nicht eine SWD implementierung gezimmert?
> Könnte eventuell als Grundlage dienen...
> https://github.com/mchck/mchck

Hatte ich oben auch schon gepostet. Leider haben die nur die 
allerunterste Ebene im client implementiert, den Rest macht der PC.

Prinzipiell würde es gar nicht so lange dauern, ein kleines 
Bitbang-SWD-Programm zum programmieren welches Chip-Erase macht - auf 
jeden Fall ist das weniger aufwändig als der Analyzer.

Allerdings benötigt man sowieso noch einen Keil-kompatiblen SWD-Adapter 
für die Programmierung. Da wäre es einfacher, diesen über ein Script 
anzusteuern.

Georg G. schrieb:
> Ich werde dann mal versuchen, die LCD Ansteuerung im Sender zu verstehen
> (sie ist aktiv).

Es wäre natürlich praktischen, wenn man nur ein LCD anschließen müsste.

Entschuldigung ich muss mich korrigieren.

Ein Script lässt sich in J-Flash zusammenklicken. Nicht Keil!!
Hab mich da leider vertan. Ist schon länger her, dass ich da rumgesucht 
hatte.

Bringt also nichts. Ich glaub selbst mit nem J-Link Edu bringt es nichts 
da keine J-Flash Lizenz dabei ist. Weiß daher nicht ob die Scripts 
ausgeführt werden oder ob zuerst der Lizenzfehler kommt. Werde ich 
demnächst mal ausprobieren.

No y. schrieb:
> Entschuldigung ich muss mich korrigieren.
>
> Ein Script lässt sich in J-Flash zusammenklicken. Nicht Keil!!
> Hab mich da leider vertan. Ist schon länger her, dass ich da rumgesucht
> hatte.

Also für mich sieht es aus, als wenn es mit den Debug Function im Menu 
Debug->Function Editor funktionieren könnte. Man kann damit functionen 
definieren, die Befehle wie _WWORD (0x20000, 123); beinhalten, mit denen 
man den Speicher des Targets beschreiben kann. Oder verstehe ich hier 
etwas falsch?

Es hat sich herausgestellt, dass es wirklich sehr einfach ist, mit 
"Functions" im KEIL Debugmodus eigene SWD-Sequenzen zu definieren. Mit 
dem Anhängenden Beispielprojekt lässt sich Chip-Erase jetzt mit jedem 
beliebigen SWD-Adapter an KEIL durchführen. Mit ST-Link funktioniert es 
wunderbar.

Leider gibt es noch ein paar Probleme mit ST-Link und Keil. Mann kann 
programme Downloaden, aber nicht debuggen und ausführen. Woran es liegt 
weiss ich nicht. Evtl. hilft hier Versaloon usw. Kennt sich hier jemand 
aus?

https://github.com/hackocopter/SWD-Hacking/tree/master/KEIL-Flashtools

Hier nur kurz:

-Es wird Keil µVision5 mit Legacy Device support benötigt.
-Die Treiber für den SWD-Adapter sollten installisert sein.

-Projekt im Anhang öffnen
-Den richtigen SWD-Adapter auswählen.
-In den Debug-modus gehen (1)
-In der Command Zeile "INCLUDE Mini51flashtools.ini"+<enter> eingeben 
(2)
-Jetzt erscheint ein Tool-Menu mit einigen neuen Funktionen. (3)

_Mini51 ShowConfig_: Zeigt aktuelle configuration des controllers an. 
Hier am besten zuerst mal draufklicken.

_Mini51 ChipErase_: Führt ein Chip-Erase durch, wenn der Chip gesperrt 
war. *ACHTUNG:* Dieser Befehl löscht die original Firmware ohne 
Sicherheitabfrage

_Mini51 WriteStdConfig_: Beschreibt die Configurationsregister mit 
Standardwerten. Sollte nach dem Chip-Erase immer gemacht werden.

_Mini51 Reset_: Selbsterklärend

Tim    schrieb:
> Mit ST-Link funktioniert es
> wunderbar.

Na das kommt doch genau zum richtigen Zeitpunkt. Da mein Quad so lange 
auf sich warten hat lassen ist ja jetzt wirklich zu überlegen, ob sich 
die Anschaffung eines Nulinks noch lohnt. Eigentlich hab ich nicht vor, 
irgendwo anders Nuvoton MCUs zu verwenden.

Ich denke Tim, aber auch allen die dabei geholfen haben, das möglich zu 
machen, gebührt mal wirklich ein Dankeschön.

Tim    schrieb:
> Mit
> dem Anhängenden Beispielprojekt lässt sich Chip-Erase jetzt mit jedem
> beliebigen SWD-Adapter an KEIL durchführen. Mit ST-Link funktioniert es
> wunderbar.

Super Arbeit! Klasse. Tolles reverse engineering und super Ergebnis! 
Tausend Dank!!!
(PS: Vielleicht machst du nen Artikel bei dir im Blog daraus und schicks 
zu Hack a Day o. Ä., ist sicher auch für viele andere Interessant)

Jog3k schrieb:
> Gute Arbeit cpldcpu! Nach einem chip-erase (mit dem magic register)
> konnte ich meine alte Firmware wieder aufspielen und das Gerät läuft
> wieder!!!

Interessant! Du hattest den "Mold-King", oder? Welche Software hast Du 
für die Programmierung verwendet? Bei mir klappt es mit dem ST-Link noch 
nicht so gut.

Philipp E. schrieb:

>
> Super Arbeit! Klasse. Tolles reverse engineering und super Ergebnis!
> Tausend Dank!!!
> (PS: Vielleicht machst du nen Artikel bei dir im Blog daraus und schicks
> zu Hack a Day o. Ä., ist sicher auch für viele andere Interessant)

Danke! :) Habe auch schon über einen Artikel nachgedacht, aber dafür 
muss ich auch erstmal die Zeit finden. Der Hackocopter hat mir diese 
Woche schon sehr viel davon gekostet...

>> Interessant! Du hattest den "Mold-King", oder? Welche Software hast Du
>> für die Programmierung verwendet? Bei mir klappt es mit dem ST-Link noch
>> nicht so gut.
>
> Genau, MouldKing (in der Anleitung als X6 betitelt, auf dem Gehäuse
> steht M-1). Ich habe ein eigenes Programm geschrieben bzw. erweitert und
> verwende den stlink-v1 vom ersten Discovery. Ich werde den Code bei
> Gelegenheit gerne veröffentlichen. In meinem code.google.com repo habe
> ich auch ein script für openocd (allerdings habe ich nicht getestet ob
> das Programmieren damit funktioniert).
> Welche Probleme hast Du mit dem stlink?
>
> Beste Grüße!

Ich kann mit µVision über ST-Link auf den Mini54ZAN zwar programme 
hochladen, aber das Debuggen und Ausführen funktioniert nicht richtig.

Verwendest Du die normale ST-Link Firmware und OpenOCD zum 
programmieren?

Dein Programm wäre sicherlich für andere auch interessant.

Hubsy schrieb:
> Tim    schrieb:
>
>> Ich kann mit µVision über ST-Link auf den Mini54ZAN zwar programme
>> hochladen, aber das Debuggen und Ausführen funktioniert nicht richtig.
>
> Kannst du dies etwas präzisieren? Was funktioniert und was funktioniert
> nicht?

Flash und Erase wird ohne Fehlermeldung durchgeführt. Nur das 
hochgeladene Programm (z.B. Blinky) wird anschließend nicht ausgeführt. 
Ebenso zeigt der Debug-Mode einen leeren Speicher. Entsperrt ist der 
Chip, denn das Programmieren geht mit dem Nu-Link wunderbar.

Hey,
Ich wollte mal eben fragen ob dein Ladegerät mittlerweile fertiggestellt 
ist? Ich layoute gerade selber eins und bin mir ein bisschen unsicher 
mit der Verlustleistung des Chips. Wie sieht das bei dir aus?

Dominic A. schrieb:
> Hey,
> Ich wollte mal eben fragen ob dein Ladegerät mittlerweile fertiggestellt
> ist? Ich layoute gerade selber eins und bin mir ein bisschen unsicher
> mit der Verlustleistung des Chips. Wie sieht das bei dir aus?

Ich habe leider den Chip noch nicht, habe aber von den PCBs ein paar 
verschenkt. Vielleicht kommt von da eher Rückmeldung. Ich habe mich an 
den Layoutvorschlag aus dem Datenblatt gehalten. Allerdings werde ich 
den Ladestrom sowieso eher gering einstellen, so dass ich nicht mit 
Wärmeproblemen rechne.

Hubsy schrieb:
> Kannst du mit dem ST-Link und der "STM32 ST-LINK Utility" auf den
> Mini54ZAN zugreifen?

Das STM32 utitlity habe ich noch nicht ausprobiert. Aber da das Script 
von oben funktioniert, wird der genenrelle Zugriff möglich sein. Ich 
glaube eher, dass das ST-Linkt versucht irgendwelche Protokolleigenarten 
auszunutzen, die es nur auf dem STM32 gibt.

Die Bedienungsanleitung ist mir teilweise ein Buch mit 7 Siegeln. Leider 
sind meine Kenntnisse der chinesischen Sprache zu gering, das Original 
zu entziffern.

Drei Punkte, die vielleicht jemand beantworten kann:

- Was bewirkt der "Turning" Taster? Ist er nur für die Rollen gedacht?
- Der letzte Punkt über "flying environment" beginnt mit "if the 
aircraft take-off not be vertical rise..." Was will der Autor uns sagen? 
Was soll die beschriebene Prozedur bewirken?
- Beim Trimmen kommen mal lange, mal kurze Piepser. Was will das Gerät 
mir sagen? Lässt sich das Ding so trimmen, dass es wirklich auf der 
Stelle schwebt?

Tim    schrieb:
> Dominic A. schrieb:
>> Hey,
>> Ich wollte mal eben fragen ob dein Ladegerät mittlerweile fertiggestellt
>> ist? Ich layoute gerade selber eins und bin mir ein bisschen unsicher
>> mit der Verlustleistung des Chips. Wie sieht das bei dir aus?
>
> Ich habe leider den Chip noch nicht, habe aber von den PCBs ein paar
> verschenkt. Vielleicht kommt von da eher Rückmeldung. Ich habe mich an
> den Layoutvorschlag aus dem Datenblatt gehalten. Allerdings werde ich
> den Ladestrom sowieso eher gering einstellen, so dass ich nicht mit
> Wärmeproblemen rechne.

Alles klar, ich denke ich bestelle auch einfach mal meine PCB's. Ich 
werde wahrscheinlich auch noch ein paar zu viele und hier vergeben. Da 
werde ich mich aber wieder melden wenn ich die Platinen habe. Kann also 
noch dauern.

Georg G. schrieb:
> - Was bewirkt der "Turning" Taster? Ist er nur für die Rollen gedacht?

Mit ihm kann scheinbar auch eine Kalibrierung durchgeführt werden. Den 
Knopf drücken und beide Knüppel in die Linke untere Ecke ziehen. (Hat 
bei mir selber aber auch noch nie funktioniert)
Edit: Doch es funktioniert. Man muss beide Knüppel in die linke untere 
Ecke ziehen und dann den Turningbutton gedrückt halten.

Georg G. schrieb:
> - Der letzte Punkt über "flying environment" beginnt mit "if the
> aircraft take-off not be vertical rise..." Was will der Autor uns sagen?
> Was soll die beschriebene Prozedur bewirken?

In meinem Handbuch kann ich diesen Satz nicht finden. Bei mir stehen 
unter flying environment nur so Dinge wie z.B bei warmem Wetter fliegen 
und nicht fliegen wenn es windet.

Georg G. schrieb:
> - Beim Trimmen kommen mal lange, mal kurze Piepser. Was will das Gerät
> mir sagen? Lässt sich das Ding so trimmen, dass es wirklich auf der
> Stelle schwebt?

Das habe ich mich auch schon gefragt. Jedoch habe ich dazu soeben noch 
etwas Interessantes im Handbuch gefunden.
Scheinbar werden die Kalibierungseinstellungen in der Fernbedienung 
gespeichert. Den bei mir steht der Satz:"Press and Hold the speed 
conversation button while turning the power switch, Trimming the remote 
controller is reset"
Also so wie ich das verstehe werden die Kalibrierungseinstellung 
gelöscht wenn man die Fernbedienung mit gedrücktem Speedbutton 
einschaltet.
Vielleicht hängt das gepiepse irgendwie damit zusammen?

Kann man den linken Button nicht auch 2x hintereinander drücken und dann 
ist er noch agiler? Habe ich zumindest das Gefühl.

Noch ein kleiner Tipp. Bei mir sind manchmal die Sticks hängen 
geblieben. Insbesondere in den Ecken. Das ist ziemlich mühsam. Bei mir 
lag es daran das die Knöpfe zu stark auf die Fernbedienung gedrückt 
haben. Als Lösung habe ich einfach die Fernbedienung aufgeschraubt und 
die 2 Schrauben in der oberen Ecke des PCB ein bisschen gelöst. Nun 
flutschen die Sticks zurück in die Mitte wie noch nie.

Georg G. schrieb:
> - Beim Trimmen kommen mal lange, mal kurze Piepser. Was will das Gerät
> mir sagen? Lässt sich das Ding so trimmen, dass es wirklich auf der
> Stelle schwebt?

Die langen Piepser ertönen, wenn das Trimming auf 0 eingestellt ist.

Das Trimming bleibt übrigens nach dem Ausschalten der FB erhalten. 
(EEPROM?). Am besten nutzt man es gar nicht.

Davis schrieb:
> Ansonsten:
>
> Laut Keil kann der ULINK2 mit dem Mini54ZAN "arbeiten"[1]. Der ULINK2
> selbst liegt mit ca. 11 Euro preislich beim Nu-/BuLink[2] und ist aber
> auch für andere Controller-Familien geeignet.
>
> Was haltet ihr davon?
>
> [1]
> http://www.keil.com/dd/chip/5587.htm
>
> [2]
> 
http://www.ebay.de/itm/Ulink-2-USB-JTAG-Emulator-ARM9-Cortex-Keil-Ulink-II-GH2-White-Adapter-Debug-DR-/300945296019

Klingt gut. Chip erase wird es nicht unterstützen, aber das macht das 
Script oben.

Den Versuch, im FB Sender an den LCD Anschluss ein Display zu hängen 
werden wir beerdigen können.

Es kommen - wie bereits geschrieben - abwechselnd drei Datenpakete, die 
sich bei Bedienung der Hebel und Taster ändern. Es ist aber kein 
Zusammenhang zwischen den Bytes und Bits und irgendwelchen Aktionen zu 
erkennen.

Um weiter zu kommen, müssten wir einen Sender analysieren, der mit LCD 
ausgeliefert wurde.

Schade, dann ist die Datenausgabe evtl. einfach nur übrig gebliebener 
Code ohne richtige Funktion? Oder lässt sich zumindest erkennen dass die 
Ausgabe als Reaktion auf etwas erfolgt (Binding, Steuern, usw.)

Tim    schrieb:
> Oder lässt sich zumindest erkennen dass die
> Ausgabe als Reaktion auf etwas erfolgt (Binding, Steuern, usw.)

Die Ausgabe ändert sich, wenn man steuert. Es ist aber nicht so, dass 
eine Änderung der Betriebsspannung bestimmte Bits ändert (oder Binden 
oder Trimmung oder Bewegung der Knüppel).

Beispiel: Drücken auf "trimmen roll rechts" ändert ein Byte permanent 
von 0x04 auf 0x0c. Anschließendes Drücken auf "trimm roll links" ändert 
es aber nicht zurück auf 0x04. Es geht zurück auf 0x04 bei "throttle 
10%". Es ist alles irgendwie pseudozufällig und doch reproduzierbar.

Auf meinen Bulink warte ich noch immer :-( Ob ich in der Zwischenzeit 
den Ulink2 bestelle?
Was haltet ihr von diesem
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=130738049882
Magnetsensor? Könnte man damit einen autonomen Schwebeflug erzielen?

Also zum Thema ULink:

Beitrag "CoLinkEX oder Segger J-Link EDU oder Ulink2"

Und für ca. 11€ bekommt man auch ne 10DOF IMU in Ebay mit MS5611 die 
wahrscheinlich auch nicht viel größer ist als die verlinkte.

Oliver Stellebaum schrieb:
> Könnte man damit einen autonomen Schwebeflug erzielen?

Für die Höhe brauchst du einen Höhensensor, barometrisch oder 
Ultraschall oder Laser oder Radar.

Für die anderen zwei Koordinaten hilft dir der Magnetsensor auch nur 
begrenzt, weil das Magnetfeld sich über wenige Meter nicht merkbar 
ändert. Du kannst nur die Richtung der Nase damit stabilisieren.

Für die Höhenstabilisierung bietet sich ein Drucksensor an. Ich habe mir 
mal einen BMP180 bestellt, der einer der besten Sensoren am Markt zu 
sein scheint:

http://www.ebay.de/itm/1PC-BMP180-Digitale-Luftdruck-Sensor-Brett-Modul-fur-Arduino-/271336856744

Bis das mit der Software funktioniert ist es aber noch ein weiter weg .)

batman schrieb:
> Vielleicht kann man eine optische Maus so modifizieren, daß sie den
> Bewegungsvektor über Boden ausgibt (statt über Mousepad)?

Ich glaube nicht, dass das mit mehr als wenigen mm Abstand noch 
funktioniert.

Wenn man dem kleinen Ding dann noch eine zusätzliche Schubdüse verpasst 
könnte er mit der Mouse unten drunter auch abheben :-)

Heute ist mein original Hubsan angekommen.
Da ist eine Schutzschaltung mit DW01 im Ladekabel.
Schaltung scheint ziemlich exakt nach Datenblatt zu sein.

Ist sicherlich nicht der Weißheit letzter Schluss, aber schon besser als 
beim Billig-Hubsan.

Allerdings ist die Steuerung der "Flips" doof gelöst. Man muss erst in 
eine Richtung drücken und danach schnell in die andere Wechseln um einen 
Flip aus zu führen.

Immer wenn man keinen Flip machen will macht er einen und wenn man einen 
machen will funktioniert's nicht :(

Außerdem sackt er nach dem Flip noch viel stärker weg als der 
Billig-Hubsan.

Bevor dieser Thread hier vollkommen in der Versenkung verschwindet gebe 
ich bekannt dass mein bestellter Bu-Link endlich angekommen ist.
Erschwerend kam hinzu, das nicht mein Name sondern nur mein 
Aliexpress-Name auf dem Umschlag stand. Ich konnte dem Postmann aber 
glaubhaft versichern das ich der rechtmäßige Empfänger bin :-)

So, bald sind Weihnachtsferien, hoffe ich komme dann dazu, mir eine 
Testumgebung aufzubauen.

Ich habe mich gerade noch einmal wieder dran gesetzt. Eine positive 
Sache: Das Programmieren und Debuggen mit ST-Link funktioniert. Ich 
weiss nicht was letztes mal schief ging.

Das heisst, dass sich der Hack-O-Copter mit jedem Discovery-Board 
entsperren und programmieren lässt.

Ich werde jetzt noch versuchen das Flash tool zu erweitern, um den 
Bootloader einzuspielen. Auch wenn SWD für das Debugging praktisch ist, 
ist ein serieller Bootloader einfacher in der Handhabung

Tim    schrieb:
> Das heisst, dass sich der Hack-O-Copter mit jedem Discovery-Board
> entsperren und programmieren lässt.
>
> Ich werde jetzt noch versuchen das Flash tool zu erweitern, um den
> Bootloader einzuspielen. Auch wenn SWD für das Debugging praktisch ist,
> ist ein serieller Bootloader einfacher in der Handhabung

Nice work :) Big thx.

Leider stresst die Uni in letzter Zeit ziemlich :(