Fumot Tornado 25000 mit LCD -Teardown

...und das scheint ja sowas wie ein 160x240 Pixel Farbdisplay zu sein (!) Die haben doch einen an der Waffel. Versteh mich nicht falsch, für Bastler super - aber als Wegwerfware ist das doch Verschwendung pur. Aber mit LiIon Akku, Ladeschaltung und noch einer Leistungsendstufe und ein paar Knöpfchen fast schon fertige Hardware fü alles mögliche. Widerstandsheizung oder Induktion?

Matthias S. schrieb:

Widerstandsheizung oder Induktion?

Widerstand.

Naja, Stiller Zeitgenosse. Auf der seriellen ist nix.

Ich würde halt fast wetten die haben (laut übersetztem DB) RDP/WRP für den internen Speicher des MCU gesetzt. Somit dürfte das erneute verwenden des Cortex M0+ der da werkelt vermutlich eher nicht möglich sein. (oder kennt jemand einen Trick?)

Morgen geht's weiter. Irgendwie hab ich einen R an Boot0 in Verdacht der verhindert das ich in den Bootloader komme.

Selbst wenn ich nur den Touch (Separates PCB, Ttp223! Sicher sogar, sind 0,08€ teure Sensormodule) LCD und den Flash benutzen kann. Das Zeug liegt GRATIS auf der Straße!

Das sind alleine die LCD wert aufgesammelt zu werden und ausnahmsweise haben sie es ja einfach gemacht: Beschriftung auf dem PCB.

Ach kommt, zwei schnelle snappschüsse. ;-)

Und das LCD, ich sollte um die Zeit wohl keinen Kaffee mehr Trinken... :-D

Halt, will ja nix vorenthalten.

;-)

Das ist Elektronik aus so einem Suchtnuckel, aber das ist ja wohl einer zum Nachfüllen, denn wozu sonst sollte der eine USB-C-Buchse haben, mit der man den Akku wieder aufladen kann?

Insofern werden diese Drecksdinger nicht in der gleichen Menge in die Pampa geworfen wie die Einweg-Suchtnuckel.

Diese Menschen sind krank. Schwer krank.

Harald K. schrieb:

wie die Einweg-Suchtnuckel

Die soll es bald nicht mehr geben, weil das ja noch mehr elende Verschwendung ist. Wimre wird die EU Einwegdampfer verbieten.

aber Hauptsache man hat sich auf USB-C geeinigt, wofür man sich ja ganz toll beweihräuchert.

Harald K. schrieb:

Das ist Elektronik aus so einem Suchtnuckel, aber das ist ja wohl einer zum Nachfüllen,

Nein, ist er nicht!

Typ und Marke im Titel, das sind ALLES Einweg, der einzige Grund warum die Teile USB-C haben und den Akku laden können ist weil das Ding 25.000 Züge beherbergt. Das schafft ein so kleiner Akku natürlich nicht ohne nachgeladen zu werden.

Hier ist das Gehäuse mit Tank zu sehen. Ein mal Vorderseite und Rückseite.

Theoretisch (pinker Deckel, an der Rückseite entfernen und der Tank liegt frei) könnte man den nachfüllen. Aber auch wenn der Trend dazu Grad online die Runde macht, das ist ekelhaft! Wie lange die Watte in den Heitzelementen unverkohlt bleibt ect. Und die Heitzwendeln lassen sich nicht tauschen ohne riesen Sauerei.

Kilo S. schrieb:

Wie lange die Watte in den Heitzelementen unverkohlt bleibt ect

So lange wie genügend Liquid enthalten ist - garnicht.

Ich dampfe mit einem Voopoo Drag M100S Smart - also ein Mehrwegdampfer mit einem UFORCE Kopf. Der Drag erkennt die Coils anhand ihres Widerstandes automatisch und stellt sich darauf ein. Im Grunde, wie schon gesagt, braucht der Coil - solange er nicht trocken betätigt wird - garnicht gewechselt werden. Ich wechsle dennoch alle 50k Züge.

Und man muss mal sagen, ich dampfe relativ viel, den Drag habe ich jetzt ein Jahr und genau 97.727 Züge gemacht. Aber 25.000 Züge von diesem Fumot sind schon extrem viel für ein Einwegdampfer. Das Ding hält dicke 5-6 Monate - so oft wird man den mit Sicherheit nicht finden.

Harald K. schrieb:

Suchtnuckel

Lass mich raten: du rauchst nicht, du trinkst kein Alkohol und Zucker ist dir auch völlig fremd?! ;-)

Btw.: ich bin durch einen Schlaganfall von 2 Schachteln Zigaretten am Tag auf das Dampfen (natürlich ohne Nikotin) umgestiegen.

Auch die hochkapazitiven (25000 Puffs = Züge) Einweg-Dinger haben USB-C, weil dann können die Akkus kleiner (=billiger) sein. Und bei Fumot heißen die Typ-C-Anschluss und Typ-C-Schnellladung, vermutlich weil sie sich dadurch Lizenz-Gebühren sparen.

Folgende 2-Milliliter-Regelung habe ich nicht verstanden, dadurch erhöht sich doch der Einweg-Müll: Zitat https://www.randmvape-shop.net/blogs/news/tornado-vape-kaufen Warum sind Tornado-Vapes in Deutschland verboten?

Der Tornado Vape ist in Deutschland nicht generell verboten, allerdings gibt es strenge Vorschriften, die das Gerät in seiner aktuellen Form auf dem deutschen Markt einschränken. Ein Grund dafür sind die in Deutschland geltenden Regelungen zur E-Zigaretten-Nutzung. Die maximale Liquid-Menge in einem Einweg-Vape darf hier 2 ml nicht überschreiten. Der Tornado Vape, der bis zu 12.000 Züge bietet, enthält deutlich mehr als diese Menge und verstößt damit gegen die deutsche E-Zigaretten-Richtlinie.

Zudem gibt es Vorschriften bezüglich der Nikotinmengen, die in Vaping-Produkten erlaubt sind. Diese strengen Gesetze sollen den Verbraucherschutz stärken, insbesondere in Bezug auf minderjährige Nutzer. Deshalb sind viele Einweggeräte, die in anderen Ländern problemlos verkauft werden, in Deutschland nicht zugelassen. Zitatende

Man kann sie dennoch kaufen. Bestellen oder "unter der Hand".

Rene K. schrieb:

Das Ding hält dicke 5-6 Monate - so oft wird man den mit Sicherheit nicht finden.

Der Kollege der mir den gab, hatte ihn ca. Ne Woche. Glaub mir die Teile gehen hier an den Kiosken Rum, an Jugendliche verkauft, ohne Skrupel. Die halten nicht lange, da nuckeln dann 1000 Leute dran:"Probier mal".

Und je nach dem wie schnell und lange da wer dran zieht. Ich hör öfter mal:"Schmeckt verbrannt". Ich bekomm die ja regelmäßig für die Akkus von Freunden und Bekannten.

Rene K. schrieb:

Voopoo Drag M100S Smart

Smog Mag GRIP 225TC, Kopf weiß ich Grad nicht auswendig, einfaches Modell mit Dual Coil.

Benutze ich aber kaum, dampfen ist schön und gut, da hau ich mir aber immer zu viel Nikotin rein. Irgendwie bin ich da einer "dem fehlt da was". Schwer zu erklären.

Torsten B. schrieb:

Man kann sie dennoch kaufen. Bestellen oder "unter der Hand".

Leider ja, das schlimmste ist das Gilt sogar für harmlos aussehende aber gar nicht so harmlose HHC Vapes. Ich hab die Dinger hier an einem Kiosk gesehen und mich gefragt:"HHC?"... Googelt mal, krass was sich so mancher da freiwillig in die Synapsen zwiebelt.

So, jetzt schau ich erst mal was sich an Boot0 noch so verbirgt.

Über 1k an VCC verbunden.

Hm, Boot0 auf GND bringt nix.

Das Teil spielt stur sein Programm ab. Tipps wie ich den internen Schutz umgehen kann sind immer noch willkommen.

Display, natürlich hab ich den originalen connector irgendwo auf dem Tisch mit dem Ärmel mitgerissen und finde ihn nicht.

So hab ich mir was "Zusammengefummelt".

Kilo S. schrieb:

laut übersetztem DB

Datenblatt auf englisch gibts hier: https://download.py32.org/Datasheet/en/PY32F030_Datasheet_V1.8.pdf

Matthias S. schrieb:

Datenblatt auf englisch gibts hier

Vielen Dank!

Also, wo ich mir Recht sicher bin, ich hab gerade mit dem Diamantkopf die GND plane weggenommen, der Hersteller weiß zu verwirren!

Das wird doch SPI sein, I2C geht an den USB-C Port.

1.) GND

2.) LED-K

3.) LED-A

4.) GND

5.) RST

6.) ? (LCD-DCN = MOSI?)

7.) ? (MISO?)

8.) CLK

9+10.) VCC (3,3V)

11.) CS

12.) GND

Wenn ich nach der Auflösung suche lande ich bei einem Modul mit GC9A01 Controller, das kommt dem sehr nahe.

Das Problem beim PY32 scheinen die Option Bytes zu sein. Man hat einen Weg zu finden, an die ranzukommen.

Matthias S. schrieb:

Das Problem beim PY32 scheinen die Option Bytes zu sein. Man hat einen Weg zu finden, an die ranzukommen.

Jepp, der war aber sowieso nicht der Grund für mein Interesse.

Verdammt, das Display ist ganz schön "Zickig".

Ich hab's jetzt mal versucht wie beim ST7735/89, immerhin, es wechselt zu "Grau" anstelle weiß.

Irgendwas hab ich noch nicht ganz richtig glaub ich.

Kilo S. schrieb:

Verdammt, das Display ist ganz schön "Zickig".

Kannst du nicht die Verbindungen vom LCD an den MC durchpiepsen?

Kilo S. schrieb:

Schön einsammeln Freunde! Gratis Displays!

Solch ein Exemplar würde ich gern auch mal finden! Leider habe ich hier auf dem Land aber bisher kaum E-Vapes in der Pampa gefunden, und wenn, dann die einfachen 0815-Teile ohne LED- oder gar LCD-Anzeige.

Matthias S. schrieb:

Kannst du nicht die Verbindungen vom LCD an den MC durchpiepsen?

Hab ich. Ich hab sogar mit dem proxon die oberste Schicht abgetragen und so gut es eben ging durchleuchtet ect.

Daher kam ich ja zur Vermutung das es in Richtung ST77XX geht, DCN an SCL und Data an MOSI. Scheint aber kein ST77XX zu sein ODER ich hab noch nicht die richtige Variante ausprobiert.

Ich scheine jedenfalls dem Rätsel auf der Spur zu sein. Ohne Ansteuerung bleibt es einfach Weiß, mit wird es zumindest schon mal Grau und flackert leicht. Es versucht also was zu tun.

Da bin ich zuversichtlich das auch noch Platinen von dem Modell Reinflattern, bis dahin muss ich mir noch einen LA besorgen.

Gleich löte ich erst mal den Flash um, reinschauen was da so drin ist.

Matthias S. schrieb:

Kilo S. schrieb:

laut übersetztem DB

Datenblatt auf englisch gibts hier: https://download.py32.org/Datasheet/en/PY32F030_Datasheet_V1.8.pdf

Das Reference Manual liegt hier: https://download.py32.org/ReferenceManual/en/PY32F030%20Reference%20manual%20v1.3_EN.pdf

In Kapitel 4.6.2 steht was zur Flash Read Protection. M.E. sollte es möglich sein, die Protection wieder rückgängig zu machen, wobei natürlich dadurch das on-chip Flash gelöscht wird. Aber der Chip müsste prinzipiell neu programmierbar sein.

Kilo S. schrieb:

Hm, Boot0 auf GND bringt nix.

Das Teil spielt stur sein Programm ab. Tipps wie ich den internen Schutz umgehen kann sind immer noch willkommen.

Um in den Bootloader zu kommen, müsste BOOT0 auf HIGH gesetzt werden. (Kap. 3.5. in https://download.py32.org/ReferenceManual/en/PY32F030%20Reference%20manual%20v1.3_EN.pdf)

Ebenfalls wichtig: Es sind mehrere USART-Boot-Interfaces möglich. Die RX-Pins der nicht benutzten USARTs dürfen nicht floaten. siehe Kap. 1 von UM1503: https://download.py32.org/Tool/en/PY32_IspTool_V1.0.0/UM1503_PY32IspTool_User%20Manual%20V1.0_EN.pdf

ISP-Tool: https://py32.org/tool/PY32_ISP.html

M. G. schrieb:

In Kapitel 4.6.2 steht was zur Flash Read Protection. M.E. sollte es möglich sein, die Protection wieder rückgängig zu machen, wobei natürlich dadurch das on-chip Flash gelöscht wird. Aber der Chip müsste prinzipiell neu programmierbar sein.

Sehr cool! Danke.

Nu, is ja wurscht ob der inhalt danach weg ist! Mein weg mit den MCU wäre so oder so der uber den Arduino kram: https://github.com/py32duino/Arduino-PY32

Der inhalt des Flash, 16MB für eine verdammte E-Zigarette! Pffff! Irgendwie geil für uns bastler, vor allem weil das OTP register komplett leer ist usw. Bis auf den inhalt ist der komplett jungfräulich!

M. G. schrieb:

Um in den Bootloader zu kommen, müsste BOOT0 auf HIGH gesetzt werden.

OK, also wie es ursprünglich war. (1k an 3,3V)

M. G. schrieb:

Ebenfalls wichtig: Es sind mehrere USART-Boot-Interfaces möglich. Die RX-Pins der nicht benutzten USARTs dürfen nicht floaten.

Das überprüfe ich bei der nächsten Platine.

Im allerschlimmsten notfall kauf ich (wenn bis dahin nicht eine reinflattert) mir einfach eine!

Kilo S. schrieb:

Im allerschlimmsten notfall kauf ich (wenn bis dahin nicht eine reinflattert) mir einfach eine!

Günstig sind die aber nicht ... ;-)

M. G. schrieb:

Günstig sind die aber nicht ... ;-)

In etwa so viel wie ein Display Breakout auch. ~20€ wenn ich noch handeln kann eventuell auch weniger.

Hab bald Geburtstag, daher wird's von dem geld bezahlt.

Übrigens lohnt es sich auch die anderen Modelle zu Sammeln.

Wer die in Rund oder flach mit 12.000/15.000/20.000 Zügen und Charlyplexing für die Siebensegmentanzeige aufsammelt, da sitzen (SOP16/TSOP20) PY32F002 drauf.

Kilo S. schrieb:

M. G. schrieb:

Um in den Bootloader zu kommen, müsste BOOT0 auf HIGH gesetzt werden.

OK, also wie es ursprünglich war. (1k an 3,3V)

Allerdings muss dazu das BOOT1n Bit in den Option Bytes auch auf 1 stehen, Und das scheint auf 0 programmiert zu sein.

Matthias S. schrieb:

Allerdings muss dazu das BOOT1n Bit in den Option Bytes auch auf 1 stehen, Und das scheint auf 0 programmiert zu sein.

Wenn ich nen passendes Breakout organisiert bekomme, versuch ich es nach DB mit dem ISP Tool. Aktuell hab ich nix passendes und "Dead Bug" hab ich grad echt keine lust zu. 0,5mm pitch is mir grad zu fummelig.

Ein Komplettes Löschen würde ja schon reichen, das würde den anteil von "Müll" von den teilen regelrecht auf Gehäuse, Platine und Verdampfer reduzieren. Es gehen sogar die stehenden USB-C Buchsen gut runter.

Ich hab grad die meisten der platinen (platz!) abgeerntet, geht echt gut!

Matthias S. schrieb:

Kilo S. schrieb:

M. G. schrieb:

Um in den Bootloader zu kommen, müsste BOOT0 auf HIGH gesetzt werden.

OK, also wie es ursprünglich war. (1k an 3,3V)

Ist BOOT0 auf dem Board über 1k an 3V3 gelegt? Das wäre seltsam, dann müsste ja immer der Bootloader gestartet werden?

Allerdings muss dazu das BOOT1n Bit in den Option Bytes auch auf 1 stehen, Und das scheint auf 0 programmiert zu sein.

BOOT1n=0 würde bedeuten, dass versucht wird, Code aus dem SRAM zu starten. Nach dem PowerOn dürfte da nichts vernünftiges drin stehen.

Vielleicht wäre SWD eine Möglichkeit?

M. G. schrieb:

Vielleicht wäre SWD eine Möglichkeit?

Geduld, einen J-Link hab ich hier. Mein hauptaugenmerk gilt dem Display, denn das ist halbwegs "Bastlerfreundlich" mit connector versehen. Das passende Breakout dafür wird es bestimmt auch irgendwo geben.

Die aktuelle platine ist zu nix mehr zu gebrauchen weil ich mir die layer angesehen hab. ;) Der MCU liegt aber hier, bisschen angeschliffen bei der aktion, sollte aber noch funktionieren.

Oh, noch was interessantes dazu:

"Der Beitrag scheint Spam zu enthalten: "x-cigarette"", bitte beim zweiten link X gegen e ersetzen!

https://hackaday.com/2024/04/25/reverse-engineering-a-fancy-disposable-vape/ https://hackaday.com/tag/X-cigarette-hack/ https://ripitapart.com/2024/04/20/dispo-adventures-episode-1-reverse-engineering-and-running-windows-95-on-a-disposable-vape-with-a-colour-lcd-screen/ https://github.com/ginbot86/ColorLCDVape-RE

Spätestens übernächste woche hab ich ne neue davon hier! Die infos sind doch erstaunlich ähnlich dessen was ich vermute, ähnliches modell.

Genau wie bei denen die hier sind, SWD geht an den USB-C....

OK!

https://ripitapart.com/2024/04/20/dispo-adventures-episode-1-reverse-engineering-and-running-windows-95-on-a-disposable-vape-with-a-colour-lcd-screen/

Zitat:"During my initial teardown, I noticed that the microcontroller’s SWD (Serial Wire Debug) programming lines were brought out to the USB-C port, but in an unusual way. The CC1/CC2 lines were not only used as regular 5.1k pulldowns to enable USB-C chargers to recognize the vape, but also as a programming connector"

Er hat recht, das ist bei diesen Fumot ebenfalls so. Ich komm allerdings damit gerade nicht wirklich weiter. Mein J-Link Clon will anscheinend nicht bzw. alles deutet auf fehlerhafte verbindungen hin, Pulldown drauf oder entfernt, spielt keine rolle.

Auf der einen ist DAT/CLK sogar herausgeführt als testpad, die hab ich gerade in der mangel und bekomme einfach keine verbindung.

P.S Joa, mein fehler! Einstellungen!

Erst mal reset/boot0 anfrickeln.

Hm, mit den "kleinen" hab ich kein glück. (Modelle unter 20.000 Züge, mit den Charlyplexing Displays)

Mögen einfach nicht mit mir reden!

Dabei hatte ich gehofft wie er einfach so an die firmware zu kommen ect.

Die tools aus dem link funktionieren auch, hier mal ein ergebniss nur mit einem "Schnellen test". Ist natürlich nicht "Richtig" aber das format scheint zumindest mal zu stimmen. ;)

http://www.rinkydinkelectronics.com/t_render_rgb565.php

Grr... Das ewige hin und her mit unpassenden connectoren.

Jetzt muss ich erst mal einen neuen suchen.

langsam sieht das aus als hätte jemand zuviel Zeit.

●Des|ntegrator ●. schrieb:

langsam sieht das aus als hätte jemand zuviel Zeit.

Nö, haben nicht, die Nehm ich mir aber einfach, es pisst mich mega an das die Dinger nix können als ausgenuckelt werden und danach irgendwo im Müll oder Gebüsch zu Landen.

Da ich die Teile grundsätzlich (seh ich auch ein wenig als Jugendschutz) einsammel und entsorge sofern Defekt oder die Akkus nach Prüfung selbst verwende/entsorge und die Dinger mittlerweile immer bessere Hardware haben, dachte ich mir das man neben den "Alten" (Drucksensor + IC ) als kleine notladegeräte doch bestimmt auch aus den neueren was machen könnte.

Die sch.. Dinger haben aber teils Custom Marking, außerdem verschiedene Pinout im gleichen Gehäuse ect. Daher kam mir tatsächlich die Idee nicht früher. Ich hielt es bis zur 25000 mit Display für Custom IC.

Und die mit TFT (ich hab aktuell auch ganz stark ein ST7735/S/P ect. oder sowas in Verdacht, hab einfach 1,77 Zoll Displays verglichen.) war jetzt die "Zündende" Hardware.

Ich fände das schon geil die PY32 nach dem zerlegen der kippen auf ein breakout zu löten und neben den Akkus so auch noch "on mass" gratis "Arduinos" für mich zum basteln und lernen zu haben.

Oder stell dir vor das ganze Forum macht mit und die gesammelten IC gehen als "Anfängergeschenke" an die Jugend von Freunden und Bekannten oder an sonst jemanden der damit "Gefördert" werden kann. Kostet uns dann doch nur ein breakout und pinheader! (<=1€)

Das sind die Gedanken die mich dabei antreiben, vor allem jetzt wo die Modelle mit richtigem Display einfach total verlockend sind.

Immerhin, ich versuchs öffentlich zu machen damit mehr Leute darauf aufmerksam werden. Vielleicht können wir so dafür sorgen daß die Dinger nicht mehr nur weggeworfen werden.

Kilo S. schrieb:

Da ich die Teile grundsätzlich (seh ich auch ein wenig als Jugendschutz) einsammel

Und Du meinst dass Jugendliche an herumliegenden Vapes rumnuckeln?

●Des|ntegrator ●. schrieb:

Und Du meinst dass Jugendliche an herumliegenden Vapes rumnuckeln?

Ich meine nicht, ich hab schon gesehen wie KINDER und nicht jugendliche die Dinger auf dem Spielplatz sammeln und dran Rum nuckeln.

Der Kiosk der die verkauft ist keine 30m weit weg von dort, abends sitzen die Jugendlichen da am Spielplatz und feuern die "leeren" in die Büsche...

Mag ja sein das du aus einer schöneren Gegend kommst, hier ist das leider Alltag das man sowas sieht!

Kilo S. schrieb:

Ich meine nicht, ich hab schon gesehen wie KINDER und nicht jugendliche die Dinger auf dem Spielplatz sammeln und dran Rum nuckeln.

Treibst du dich öfter in der Nähe von Spielplätzen rum?

Cyblord -. schrieb:

Treibst du dich öfter in der Nähe von Spielplätzen rum?

Natürlich, meine kleine Tochter will ja auch irgendwie beschäftigt werden und andere Kinder um sich haben zum Spielen!

Deine dummen Bemerkungen kannst du dir sparen!

Cyblord -. schrieb:

Treibst du dich öfter in der Nähe von Spielplätzen rum?

Kommt zumindest vor wenn man selbst Kinder hat. Also unterstelle hier nichts falsches bitte

Das gute ist, meine Tochter sieht was Papa macht, findet sie welche beim Spielen (nein sie nuckelt nicht daran, auch nicht an sonstigem was sie findet!) BRINGT sie mir die:"Papa musst du reparieren!"

Sie ist oft bei mir wenn ich hier was mache. Das ich die Akkus zb. Für Lampen benutze ect. kennt sie. Daher das "reparieren".

Kilo S. schrieb:

Deine dummen Bemerkungen kannst du dir sparen!

Du musst verstehen das das durchschnittliche Alter hier im Forum so um die 60 Jahre liegt - da haben die wenigsten noch Kinder. ;-)

Rene K. schrieb:

• da haben die wenigsten noch Kinder. ;-)

Aber vielleicht Enkel oder Urenkel, sowas ist schon knapp an der Grenze!

Meine beste Freundin (R.I.P) hätte jetzt gesagt:"Karma wegen dem dummen Spruch. Das Universum gibt dafür was zurück!".

Eine wird eventuell heute Abend, spätestens morgen wenn sie leer ist, die andere eventuell am Montag Reinflattern.

Zwei Zusagen für neue hab ich bereits. Für die 25000 mit LCD.

Kilo S. schrieb:

Meine beste Freundin (R.I.P) hätte jetzt gesagt:"Karma wegen dem dummen Spruch. Das Universum gibt dafür was zurück!".

Klar, die Sterne regeln das. Wenn du doch ein bisschen an Kristallsalz reibst und Räucherstäbchen anzündest, knallts noch mehr.

Hast du keine Voodoo-Puppe?

Ich bezeichne das als "Networking". Bei dem Thema waren die Eule und ich uns nie einig, aber ihre Kenntnisse über viele andere Dinge habe ich trotzdem sehr geschätzt.

Höflich fragen kann man immer! Und wer fragt hat auch häufig Erfolg.

Aber schön das du auch noch was sinnvolles beizutragen hast außer über Erinnerungen an Tote Freunde Rundumeckern? Oder ist das weil ich etwas "sozialverträglicher" bin und daher erfolgreich und kurzfristig Nachschub bekommen kann?

Fragen über Fragen warum du so "blöd" antworten musst.

Kilo S. schrieb:

Ich bezeichne das als "Networking". Bei dem Thema waren die Eule und ich uns nie einig, aber ihre Kenntnisse über viele andere Dinge habe ich trotzdem sehr geschätzt.

Habe ehrlich keinen Schimmer wovon du redest.

Höflich fragen kann man immer! Und wer fragt hat auch häufig Erfolg.

Siehe oben. Wen fragen? Nach was?

Aber schön das du auch noch was sinnvolles beizutragen hast außer über Erinnerungen an Tote Freunde Rundumeckern? Oder ist das weil ich etwas "sozialverträglicher" bin und daher erfolgreich und kurzfristig Nachschub bekommen kann?

Immer noch keine Ahnung. Nachschub an was? Toten Freunden?

Meine letzte Antwort bezog sich allein auf deine Aussage zum Karma. Was man auch am Zitat sehen kann. Eine Funktion die dir unbekannt sein dürfte.

Cyblord -. schrieb:

Immer noch keine Ahnung.

Weshalb du den sonst eigentlich konstruktiven Beitrag störst.

Egal, viel Spaß noch.

Ignorieren wir ihn einfach, ich schau in der Zeit ob ich nicht irgendwo noch einen LA kurzfristig auftreiben kann.

Bzw. Ich flashe schon mal den ESP8266 dafür...

Und auf ein neues!

Die innereien lassen sich komplett zerstörungsfrei entnehmen!

Ahhhh!

Endlich, es tut sich was!

Heut is nicht mein tag irgendwie ... also zum dritten mal! SWD für die Fumot 2500: Boot0 auf VCC, SWDO auf SDA, SCKL ist SWDCKL.

Reset auf GND, Debugging Starten und reset loslassen.

Reset übrigens doch auf GND halten, sonst bekommt man die CPU nicht in halt.

So, Feierabend für heute.

Ich such mir zwar eigentlich noch nen Wolf wie genau ich das ISP Programm von Puya dazu bekommen kann mit meinem CH340/Jlink zusammen zu Arbeiten, alternativ wie ich das alles mit Jlink hin bekomme. (Flashdump ect..) Aber immerhin!

Jetzt wo die Kommunikation passt ist es aktuell allein nur mein fehlendes wissen, das lässt sich nachholen.

Morgen noch das Display mit dem LA beobachten.

Den Arduino Core hab ich auch bereits, ich muss also eigentlich (da ich noch mal die gleiche CPU habe eigentlich auch nicht!) nur noch den (vollständigen) flashdump hinbekommen damit das alles hier so weit komplett wird. So können Leute die daran interessiert sind was damit machen.

Wie ich es auch mache, ich bekomme mit dem ISPtool keine Verbindung.

Es gibt den Hinweis das USART1 bei denen nicht will, jetzt Brauch ich aber erst mal mehr Kaffee bevor ich da was anfädel.

LA möchte auch noch nicht, zumindest die erste ausprobierte Variante nicht.

Sieht doch schon mal gut aus. +1

Im externen Flash sind 302 RGB565 Images mit jeweils 128x160 Pixel, die konvertierten Images sind als BMP Dateien im angehängten Archiv ("test000.bmp" bis "test301.bmp"). Einige der Dateien ergeben Animationen (u.a. das Würfelspiel und die Umschaltung der Heizleistung).

Dieter S. schrieb:

Im externen Flash sind 302 RGB565 Images mit jeweils 128x160 Pixel, die konvertierten Images sind als BMP Dateien im angehängten Archiv ("test000.bmp" bis "test301.bmp"). Einige der Dateien ergeben Animationen (u.a. das Würfelspiel und die Umschaltung der Heizleistung).

Vielen Dank für die Hilfe!

Ich bin dabei den zweiten "Käfer" zum Leben zu erwecken. Fleißarbeit seit heute morgen, mit Unterbrechungen, mit der Ausrüstung geht das ganz schön auf die Augen!

Matthias S. schrieb:

Sieht doch schon mal gut aus.

Danke, vom Arduino Zeugs ist man echt verwöhnt. Daher gibt's da noch viel was ich lernen muss.

Der Flash läßt sich vom J-Link Commander z.B. so auslesen (64 kByte):

1

savebin flash_dump.bin, 0x08000000, 0x10000

Voraussetzung: RDP ist nicht gesetzt und das Lesen des Flash ist erlaubt.

Dieter S. schrieb:

Der Flash läßt sich vom J-Link Commander z.B. so auslesen (64 kByte):

savebin flash_dump.bin, 0x08000000, 0x10000

Voraussetzung: RDP ist nicht gesetzt und das Lesen des Flash ist erlaubt.

Perfekt! Genau bei den Adressen hapert es noch, das war der Hinweis den ich bräuchte.

Flashdump kommt sofort!

Anfangs leicht "Hakelig" (CPU lies sich nicht gleich anhalten) aber hat geklappt!

So, der Käfer ist so weit!

Durch das umdrehen stimmen die Pin Nummern auch wieder.

Und der "Deadbug" reagiert auf SWD!

Jetzt muss ich noch die Verbindung mit dem ISPtool zum laufen kriegen!

PA2/PA3 (8,9) und USART2 ist "Floating".

Klappt trotzdem!

Und der Deadbug blinkt erfolgreich mit dem ersten Test Scetch, programmiert mit der Arduino IDE.

Coole Sache! Ich such schon mal passende Breakout Boards.

Und nun noch das LCD.

Die E kippe liefert einem mal eben ein komplettes Devboard mit Display, zwei LL-Fets, Li-Lader, Akku und Touchsensor!

OK, das spielen mit dem "originalen" PCB hat erst mal einen MCU gekillt.

Wurscht, der zweite liegt nun angepiekst in der Testvorrichtung (Pin 6/PA0 als wackelpin für ne LED, RX/TX, VCC, GND) und gibt mir über die serielle jedes Mal den Text von Setup und der Loop aus. (?)

Was zum Geier geht da ab?

Normal erwarten würde ich 0, 1, 1, 1...

Kilo S. schrieb:

Was zum Geier geht da ab?

Der wird wohl immer wieder einen Reset ausführen.

Matthias S. schrieb:

Der wird wohl immer wieder einen Reset ausführen.

Aber weshalb, den hatte ich vorher (Deadbug) umgedreht auf dem PCB, da hat er das nicht gemacht. Ohne pullup an Reset o.ä, ohne C Zwischen VCC und GND.

Ich zieh Reset gleich mal mit 1k auf VCC, schauen ob das was verändert. Muss nur die LED kurz entfernen.

Kleinen Moment Geduld, Familie geht vor.

gibts nicht....

1

//int P = PA0;

2

3

void setup() {

4

Serial.begin(9600);

5

//pinMode(P, OUTPUT);

6

Serial.println("ON0");

7

}

8

9

void loop() {

10

  //digitalWrite(P, HIGH);

11

  for(int i;i<10;i++){

12

  Serial.println(i);

13

  }

14

  //delay(300);

15

  //digitalWrite(P, LOW);

16

}

Ausgabe:

1

ON⸮ON0

2

22:23:09.499 -> 536871984

3

22:23:09.499 -> 536871985

4

22:23:09.499 -> 536871986

5

22:23:09.532 -> 536871987

6

22:23:09.532 -> 536871988

7

22:23:09.532 -> 536871989

8

22:23:09.566 -> 536871990

9

22:23:09.566 -> 536871991

10

22:23:09.566 -> 536871992

11

22:23:09.599 -> 536871993

12

22:23:09.599 -> 536871994

13

22:23:09.599 -> 536871995

14

22:23:09.632 -> 536871996

15

22:23:09.632 -> 536871997

16

22:23:09.632 -> 53687199O

Da scheint die RTC was auszugeben?

Was ist da los mensch... was mach ich falsch?

Und ende!....

Zusammenfassung: erneuter versuch zu flashen ergab das er stirbt.

VCC:3,3V daran kann es also auch nicht gelegen haben.

Ich hab den eindruck das liegt am Arduino Core, denn mein einfaches serial kann soas nicht anrichten.

Schade. Deine Geduld ist zu bewundern. Ist aber auch eine interessante Sache.

OK, drei dinge:

1.) Nach dem ansprechen mit dem ISP Tool (Klappte auf anhieb) "lebt" er wieder.

2.) Variablen innerhalb der schleifenbedingungen müssen mit 0 initialisiert werden, sonst zählt der müll.

3.) Beachtet man 2 nicht hilft nur ansprechen 1 und ein erase!

Gibts einen grund weshalb ein ESP8266 sowas verzeiht?

Also kann das echt am core liegen?

Thomas S. schrieb:

Schade. Deine Geduld ist zu bewundern. Ist aber auch eine interessante Sache.

;-)

Ich glaub nicht dran das beide IC hin sind... Wenn ich den zweiten auch Reanimiert bekomme melde ich das hier.

Irgendwann im laufe der nächsten woche gehts auch mit (der dritten, vierte ist auf dem weg!) mit dem display weiter!

Ich besorg mir so einen Salea Clon und fuchs mich auch da ein.

Abgesehen vom Arduino kram ist das mein erster "Echter" ritt mit "Blanken" IC.

Aber ich bleib dran!

Thomas S. schrieb:

Schade. Deine Geduld ist zu bewundern. Ist aber auch eine interessante Sache.

Ich hab schon wieder vergessen was er eigentlich tun will...

Kilo S. schrieb:

536871984

Wenn ich das in Hex umrechne, kommt da 0x20000430 raus, was zufällig (oder absichtlich) eine Adresse im RAM des PY32 ist. Weiterhin ist natürlich verwunderlich, das die Abbruchbedingung in

1

for(int i;i<10;i++){

ignoriert wird. Als oller C-Programmerer würde ich vermutlich mal auf das Arduino Zeugs verzichten und ein simples C Programm einnageln. Wenn es eine Startup.S oder so gibt, solltest du dir die mal angucken.

Cyblord -. schrieb:

Ich hab schon wieder vergessen was er eigentlich tun will...

Schlaf weiter, wir wecken dich wenn's nötig wird. Aber zusammengefasst nochmals für dich: Ziel (Neben der Identifikation des Display und der Nutzbarmachung selbigen) war es die PY32F030 mit der Arduino IDE programmierbar zu machen.

Ist erledigt, Grundsätzlich geht's.

Oder anders gesagt eines von zwei Zielen erreicht.

Matthias S. schrieb:

Wenn ich das in Hex umrechne, kommt da 0x20000430 raus, was zufällig (oder absichtlich) eine Adresse im RAM des PY32 ist. Weiterhin ist natürlich verwunderlich, das die Abbruchbedingung in

for(int i;i<10;i++){

ignoriert wird. Als oller C-Programmerer würde ich vermutlich mal auf das Arduino Zeugs verzichten und ein simples C Programm einnageln. Wenn es eine Startup.S oder so gibt, solltest du dir die mal angucken.

Danke für den Hinweis.

Was sagt man dazu, mit folgendem Syntax funktioniert es einwandfrei, Setup nur ein mal ausgeführt (wie es soll) und der Zähler läuft sauber durch.

1

for(int i=0;i<10;i++){

2

...

3

}

"Normales" C kommt noch für mich.

Jetzt ist nur die Frage, wieso ignoriert der Compiler die zuweisung in der Schleife? Für mich ist int i; eqivalent zu int i=0; Das muss aber irgendwo zwischen zählen und Ausgabe verändert Werden, nur wo und wieso?

Ich will ja wissen wie gut sich die Dinger eben für Arduino eignen. Ich hab hier einige an der Hand die das nutzen, daher liegt der Fokus darauf.

Matthias S. schrieb:

Wenn es eine Startup.S oder so gibt, solltest du dir die mal angucken.

Bin grad dabei.

Da passiert nicht viel, muss gleich noch zwei dateien finden dann weiß ich mehr...

Erst ein mal den "Zombiebug" um ein paar weitere Testnadeln erweitern.

Kilo S. schrieb:

"Normales" C kommt noch für mich.

Was ist "Normales" C und mit was arbeitest du aktuell?

Cyblord -. schrieb:

Was ist "Normales" C und mit was arbeitest du aktuell?

Aktuell Arduino, da nimmt einem die IDE einfach viel ab. Unter "Normalem" C verstehe ich eher sich die sachen per hand zusammen zu stricken anstelle eines fertigen core der so sachen wie compiler ect. für einen bedient.

Aktuell habe ich diesen code laufen.

1

void ser_contr(){

2

  int i = Serial.parseInt();

3

  int x = 0;

4

  switch(i){

5

  case 1:

6

      Serial.println("A");    

7

    break;

8

  case 2:

9

    Serial.println("b"); 

10

    break;

11

  case 3:

12

    Serial.println("C"); 

13

    break;

14

  default:

15

    Serial.println("Loop:");

16

    } 

17

}

18

19

void setup() {

20

Serial.begin(9600);

21

Serial.println("ON0");

22

}

23

24

void loop() {

25

 ser_contr();

26

}

Ich glaube einfach das war ein Syntaxfehler, irgendwas mochte bei der ubersetzung nicht so wie ich mir das einfach dachte.

Alles andere geht tadellos!

Kilo S. schrieb:

Cyblord -. schrieb:

Was ist "Normales" C und mit was arbeitest du aktuell?

Aktuell Arduino, da nimmt einem die IDE einfach viel ab. Unter "Normalem" C verstehe ich eher sich die sachen per hand zusammen zu stricken anstelle eines fertigen core der so sachen wie compiler ect. für einen bedient.

Das ist eine Abstruse Ansicht. C ist C auch bei Arduino (oder C++ stellvertretend gemeint).

Weder hängt das davon ab, ob du ein Million fertiger Funktionen aufrufst oder ob die IDE dir die Einrichtung der Toolchain abnimmt. Es ist und bleibt C.

Ein Beispiel wo C nicht mehr C (oder C++) ist, wäre z.B. QT, wo man das native C++ mit Makros so lange vergewaltigt hat bis man de facto neue Sprachelemente reingepfuscht hat. Das könnte man durchaus als nicht mehr echtes C++ bezeichnen.

Arduino macht das aber nicht.

Korrekte Terminologie steht am Anfang.

Seis drum...

Nächste woche organisier ich mir den LA, muss noch schauen welchen jetzt genau.

Breakouts für 0,5mm pitch sind auch auf der liste. 12 PIN FPC breakouts mit 0,5mm pitch auch, für das Display.

Ich wusste es!

Beide MCU Leben noch.

Der Schluckauf den ich da verursacht habe muss wohl irgendwas seltsames getriggert haben.

Jetzt ist er leer, kann also erneut beginnen ihn zu nutzen.

OK, Jetzt ist es seltsam!

Der erste "Deadbug" (erkenne ich an der angeschliffenen kante) kann den gleichen code wie der neue NICHT fehlerfrei ausführen!

Scheint ein loop zu sein, setup-reset-setup-reset.

Aufbau ist der selbe wie vorher.

Kilo S. schrieb:

Aufbau ist der selbe wie vorher.

Dann versuch doch mal, da irgendwie ein paar Abblockkondensatoren in die Nähe zu bringen. Ein 8031 läuft auch ohne alles an der Motorradbatterie, aber diese neumodischen Controller mit internen Corespannungen verstehen da relativ wenig Spass.

Kann es nicht einfach an der abenteuerlichen "Deadbug" Kontaktierung mit viel zu dicken Anschlussleitungen liegen?

Soul E. schrieb:

Dann versuch doch mal, da irgendwie ein paar Abblockkondensatoren in die Nähe zu bringen.

Jo, wenn ich weiter mach. Muss morgen erst mal kurzfristig weg. Ich geh allerdings nicht davon aus das die was helfen.

Cyblord -. schrieb:

Kann es nicht einfach an der abenteuerlichen "Deadbug" Kontaktierung mit viel zu dicken Anschlussleitungen liegen?

Ne, das vermute ich weniger.

Das sind P50-01 nadeln die sauber auf den kontakten aufliegen. Das gleiche verhalten zeigt er mit kurzen stücken draht einer relaisspule auf einem stück platine.

Erstmal werkzeug einpacken....

Kilo S. schrieb:

Was sagt man dazu, mit folgendem Syntax funktioniert es einwandfrei, Setup nur ein mal ausgeführt (wie es soll) und der Zähler läuft sauber durch. for(int i=0;i<10;i++){ ... }

"Normales" C kommt noch für mich.

Jetzt ist nur die Frage, wieso ignoriert der Compiler die zuweisung in der Schleife? Für mich ist int i; eqivalent zu int i=0; Das muss aber irgendwo zwischen zählen und Ausgabe verändert Werden, nur wo und wieso?

Wenn du nur int i; schreibst, wird die Variable i nicht initialisiert, der Wert ist also undefiniert, entsprechend dem Wert, der an dem verwendeten Register oder im entsprechenden Stackbereich steht.

M. G. schrieb:

Wenn du nur int i; schreibst, wird die Variable i nicht initialisiert, der Wert ist also undefiniert, entsprechend dem Wert, der an dem verwendeten Register oder im entsprechenden Stackbereich steht.

OK, danke für den Hinweis. Ich dachte das wäre das gleiche. Wenn ich den gleichen Code auf einem Mega oder ESP8255 benutze passiert das lustigerweise nicht. (muss ich bei einem Projekt tatsächlich noch ändern bevor das mal zu Problemen führt!)

Interessant was man so alles finden kann, schaut aus wie die nicht initialisierte RTC (die letzten vier stellen in der Ausgabe der seriellen sehen halt wie ein Datum aus) die ich auf diesem weg ausgegeben habe.

Bleibt Frage Nummer zwei, weshalb verhält sich der erste PY32 nicht wie der zweite.

Der eine wurde nach dem erfolgreichen schreiben des "serial" Testprogramm und ausführen des selbigen einfach unter der Testvorrichtung "heraus geschoben" und der andere in Position gebracht, erfolgreich programmiertund getestet.

Wo der erste ausgibt: ON0 Loop: Loop:

Macht der zweite: ON0 ON0 ON0

In der Zwischenzeit wurde nur der Chip getauscht, sonst gab's keine Änderungen.

löppt dat nu!

●Des|ntegrator ●. schrieb:

löppt dat nu!

Geduld, Familie Besuchen. Bin 200Km vom PY32 weg.

Hab dafür anderes zu tun. Verdammte Noframe Displays, Patienten mit Provisorium beschwert auf der mobilen Arbeitsmatte. ;-)

Wenn das falsche Ersatzteil Arbeitszeit kostet.

Heute noch mal mit den Kids zum Umzug, dann geht's langsam weiter.

Kurzer "Status": Patient "ON ON ON" ist bereits auf einem breakout, Display breakout ist fertig, ein einfacher 8 Kanal LA+SW läuft.

Ich muss schauen ob ich selbst noch eine Vape besorge oder warte bis der Kollege zurück ist und seine leer hat.

Pinout habe ich ja, ich könnte also mit den breakout Boards das notwendige (Flash + Display) verbinden und das originale flashdump verwenden.

Mal schauen, ich hab für den Fall der Fälle ein 12pin FPC Kabel das passt und als Erweiterung an der originalen Platine dienen kann.

Ich hab jetzt X mal hin und her, das liegt nicht am "Deadbug" Design oder den Drähten ect. Beim Aufbau.

Ich erinnere mich das ich beim ISPTool beim einen IC eine andere Einstellung (Full Erase) nutzen musste um ihn erneut mit der IDE flashen zu können. Beim anderen reichte ein Flash Erase. Ich lese mich bezüglich der Register noch ein, vermutlich kann es aber auch daran liegen.

Geduld, das Display zu identifizieren steht aktuell mit ganz oben auf der Liste! Geschenkidee für meine Frau. Ich hab hier so ne schöne Glaskuppel die so toll auf einen Messingsockel passt, das wäre mit dem kleinen Display ein echt schöner "Mini Digital Fotorahmen".

;-)

Michael schrieb:

'Schatz, ich habe Dir was aus Müll gebaut' käme bei meiner nicht so gut an.

1.) Die Dinger kommen aus dem Bekanntenkreis, "verkeimt" ist da nicht viel schlimmer als der normale Kontakt den man sonst so pflegt. Deren Kaffeetasse muss ich auch wegräumen wenn die gehen.

2.) Meine Frau findet das (sie ist selbst handwerklich begabt) viel besser als gekauft. Kaufen kann jeder!

3.) Sind die Teile nur theoretisch "Müll". Aktuell kostet mich so ein "PY32Duino" 96 Cent. (breakout Platine) Für das Display 86 Cent.

Michael schrieb:

Geh lieber Flaschen sammeln.

Ich kann mir meine Zeit gut selbst einteilen und entscheiden was ich mache! Es geht nicht um Geld, es geht darum das die Dinger für jeden GRATIS rumliegen und so eben nicht die Umwelt mit Nikotin (schau mal was das mit dem Grundwasser macht) Plastik und sonstigem was mit der Zeit verottet, wenn die Leute alles damit zu Müllen, belastet und eventuell noch einer sinnvollen Verwendung zugeführt werden können.

Meine Frau ist totaler Fan von "Die schöne und das Biest".

Daher ist die selbstgemachte "Rosenkuppel" mit einem "Schrottdisplay" als Fotorahmen in Handarbeit nicht nur schöner als gekauft, es ist wirklich persönlich!

Die Optik passt auch schön zum Film, sieht halt aus wie aus dieser Zeit.

Kilo S. schrieb:

Erst ein mal den "Zombiebug" um ein paar weitere Testnadeln erweitern.

Sehr geil, so was brauch ich auch :-)

Andreas M. schrieb:

Sehr geil, so was brauch ich auch :-)

Bedarf aber einigem an Verbesserungen bezüglich des "Arbeitskomfort".

Das positionieren der spitzen ist etwas fummelig.

Variante 2, kugelgelagerter drahtarm mit fixierschraube im Messing klemmblock ist bereits (Prototyp) in Arbeit. Ich muss nur mehr der Messing klemmblöcke besorgen oder eben Stangenmaterial zum selber herstellen. ;-)

Ich empfehle stark (wenn jemand nachbauen möchte) Variante 2 nachzubauen! Das aufdrücken der Pogopins geht damit viel besser.

So, unverhofft kommt oft.

Bisschen Geduld noch, komme vermutlich heute Abend dazu weiter zu machen.

Breakout für den LA ist vorbereitet, jetzt lüftet sich bald das Geheimnis um das Display!

Und dazu noch frischer Kaffee und Apfel Zimt Kuchen, Lecker!

Kilo S. schrieb:

Breakout für den LA ist vorbereitet, jetzt lüftet sich bald das Geheimnis um das Display!

Im Firmware Dump vom weiter oben sieht man sehr schnell wie das Display initialisiert wird. Allerdings scheint es keiner der verbreiteten Display Controller zu sein, auch wenn man einige der verwendeten Kommandos bei anderen Display Controllern findet.

Ich hänge mal die session vom analyzer an.

Die Vermehren sich heimlich...

Die nächste Reingeflattert!

Dieter S. schrieb:

Allerdings scheint es keiner der verbreiteten Display Controller zu sein,

Hast du irgendeinen Hinweis was eventuell "nahe dran" sein könnte?

Ich trau mir viel zu, für das LCD alles selbst zu schreiben ist aber aktuell noch nicht darunter.

Da muss ich erst noch ne ganze Menge lesen und ausprobieren.

Kilo S. schrieb:

Hast du irgendeinen Hinweis was eventuell "nahe dran" sein könnte?

Das Problem ist dass die Kommandos zum Schreiben von Daten in den Display Speicher (das benutzt die Firmware) bei vielen Display Controller (auch von unterschiedlichen Herstellern) fast gleich sind, daher ist eine Zuordnung kaum möglich.

Und da ich ich kein so ein Teil zum Testen habe kann ich es auch nicht ausprobieren (Nein, hier in der Gegend liegt so was nicht rum und mir ist auch niemand bekannt der diese Teile benutzt).

Wenn du magst schicke ich dir eine. PN mit einer Mail-Adresse, dann ist die Kommunikation weniger "zäh" als per PN.

Den Verdampfer hab ich vorher raus geholt, ich geh noch mal mit iso drüber und dann sollte das gehen mit dem Versand.

Bzw. Von mir aus auch nur PCB+LCD, wie du magst.

Zu lange auf eine sache konzentrieren kann einen manchmal den blick auf "Wesentliches" kosten.

Tipp zu den "Digital Box" (12.000/15.000, Eckig) und "Randm Tornado" (12/15/20.000, Rund) achtet beim zerlegen auf das Marking "XWH-" auf der platine.

Auf denen sitzen auch Puya, mehr wird noch nicht verraten. ;-)

Jetzt geht's erst richtig los.

Ich hab Grad im örtlichen Supermarkt mein Netzwerk erweitert!

Nachschub ist sicher Leute!

Uff, viel zu lernen. Dank Ghidra und dem svd bin ich jetzt jedenfalls schon mal zuversichtlich das ich in absehbarer Zeit Fortschritte mache.

Die Initialisierung des Displays scheint in mehrere Funktionen aufgeteilt. Außerdem verknüpft mit einem Timer?(Dazu eine Antwort wäre sehr nett, Ja/Nein reicht, dient nur der Selbstkontrolle. Den Rest will ich selbst herausfinden.)

Jedenfalls zerlege ich aktuell die Funktion die das Interface über das AFL Register konfiguriert. Oder sagen wir so, ich Versuche es so gut es geht.

Hier ist ein "Proof of Concept" um das Display zu initialisieren.

Es handelt sich um ein Code-Fragment dass das Prinzip zeigt, man muss es allerdings erst in eine Display Library einbinden um es sinnvoll nutzen zu können.

Gezeigt wird welche Pins der PY32F030 zur Ansteuerung des Displays verwendet, wie der Display Controller initialisiert wird und noch ein kleiner Test der ein paar Farbbalken anzeigt (siehe das nicht besonders gute Bild im Anhang).

Einen bestimmten Display Controller konnte ich nicht identifizieren, ein paar der Kommandos findet man aber z.B. im Datenblatt des GC9A01A, vermutlich gibt es aber auch noch andere mit änlichen Kommandos.

Das Ganze ist "Bare Metal" und die seriellen Daten werden per Bit-Banging zum Display übertragen. Die entsprechenden Funktionen lassen sich aber leicht durch etwas anderes ersetzen (z.B. SPI per Hardware mit/ohne DMA).

Mein Testcode läuft direkt im RAM des PY32F030, daher war es zum Testen nicht nötig die Firmware im Flash zu überschreiben.

Was man unabhängig davon beachten sollte: Die Firmware verwendet IWDG als Hardware Watchdog, das wird im Konfigurationsbereich des Flash festgelegt. Daher startet der IWDG unmittelbar nach dem Reset. Das sollte man beachten bzw. die Konfiguration entsprechende ändern sonst bekommt man periodisch einen Reset wenn man den IWDG nicht regelmäßig triggert.

Dieter S. schrieb:

Die Firmware verwendet IWDG als Hardware Watchdog, das wird im Konfigurationsbereich des Flash festgelegt. Daher startet der IWDG unmittelbar nach dem Reset. Das sollte man beachten bzw. die Konfiguration entsprechende ändern sonst bekommt man periodisch einen Reset wenn man den IWDG nicht regelmäßig triggert.

Mal doof gefragt, wie machst du das? Über USB-C scheitert es schon am "Halt" (kann nicht angehalten werden?!) geschweige denn am lesen oder schreiben von Registern.

DBGMCU_APB1_FZ zb. Ist für mich überhaupt nicht erreichbar. Also selbst wenn ich Versuche an Adresse 0x40015808 zu schreiben (so macht es Ozone so weit ich gelesen habe) bekomme ich das nicht hin.

Irgendwie mach ich gerade was grundlegend falsch, ich komm nur nicht drauf was es ist.

Wenn der Watchdog aktiv ist und man eigenen Code im RAM laufen lassen will baut man das Triggern des Watchdog in den eigenen Code so ein dass es regelmäßig passiert. Außerdem sperrt man die Interrupts damit einem die Firmware nicht in die Quere kommt (z.B. die Timer Interrupts der Firmware). Das Ganze ist zum schnellen Testen kleiner Code-Teile gedacht, nicht für umfangreiche Software (dafür ist der RAM des PY32F030 zu klein).

Den Code kann man vom J-Link Commander aus mit "loadbin" in den RAM laden und danach den PC auf den eigenen Code setzen, das geht schnell genug (man kann auch mehrere Kommandos per "Paste" hintereinander ausführen).

Dieter S. schrieb:

Den Code kann man vom J-Link Commander aus mit "loadbin" in den RAM laden und danach den PC auf den eigenen Code setzen, das geht schnell genug (man kann auch mehrere Kommandos per "Paste" hintereinander ausführen).

Genau das Versuche ich.

Aktuell Versuche ich folgendes:

1

Halt

2

Loadfile fumot.bin, 0x20000000

3

Setpc 0x20000000

4

Go

Noch bevor ich bei "Go" bin, kommt der Reset.

Natürlich hab ich bisher noch nicht herausgefunden wie ich den watchdog abgeschaltet bekomme. Je mehr ich lese um so undurchsichtiger wird es aktuell.

Der Watchdog ist im PY32F030 Reference Manual beschrieben ("22. Independent watchdog (IWDG)"). Abschalten kann man ihn nicht mehr wenn er mal gestartet wurde und wenn er als Hardware Watchdog konfiguriert ist (siehe "4.4. Flash option byte") startet er nach dem Reset. In diesem Fall muss man den Watchdog also regelmäßig triggern (0xAAAA ins IWDG_KR Register schreiben).

Im RAM stehen ab 0x20000000 die Interrupt Vektoren (die Firmware kopiert sie dort hin). Am einfachsten schreibt man eigenen Code in den RAM ab 0x20000C20, der Bereich von dort bis zum RAM Ende (0x20001FFF bei 8 kByte SRAM) wird von der Firmware nicht verwendet.

Und die vier Kommandos kann man auf einmal per "Paste" an den J-Link Commander schicken, dann werden sie ohne Unterbrechung hintereinander ausgeführt.

Dieter S. schrieb:

Und die vier Kommandos kann man auf einmal per "Paste" an den J-Link Commander schicken, dann werden sie ohne Unterbrechung hintereinander ausgeführt

Ja, das klappt an und für sich schon.

Da müsste dann doch wenigstens bis der Watchdog am ende des counter angelangt ist ein mal das "Streifenbild" wenigstens aufblitzen?

Was jedenfalls schon mal sicher ist, das schreiben selbst funktioniert. Ich hab den RAM danach ausgelesen, das programm ist da.

Hm.

Magst du mal schauen ob das bin das ich erzeugt hab auch funktioniert? (anhang)

Erzeugt hab ich es so:(display_init wurde in main.c umbenannt)

1

arm-none-eabi-gcc -o fumot.elf main.c  -mcpu=cortex-m0 -mthumb -Wall -Wextra -Os  -specs=nano.specs -nostartfiles

2

3

arm-none-eabi-objcopy fumot.elf -O binary fumot.bin

Ich habe oben bereits geschrieben dass man die Interrupts sperren muss und der Watchdog periodisch getriggert werden muss wenn man Code im RAM laufen lassen will, beides sehe ich nicht in "fumot_kilo.bin".

Außerdem liegt das Hauptprogramm an Offset 0x4FC in der Datei "fumot_kilo.bin", man muss also den PC auf diese Stelle setzen.

Wollte nicht so Recht, egal was ich da versucht habe.

Gut, das Projekt "Run Code in RAM" Werd ich später noch mal aufgreifen. Ich glaub da fehlt es noch bisschen mehr an Grundlage bis das klappt.

Ich glaub ich hab es endlich geschafft. Zumindest scheint es erst mal zu funktionieren.

1

#include <Arduino.h>  // Standard Arduino header

2

3

void setup() {

4

  // Enable the LSI (Low-Speed Internal) oscillator used by the IWDG

5

  RCC->CSR |= RCC_CSR_LSION;  // Enable LSI oscillator

6

  // Wait for the LSI to become ready

7

  while (!(RCC->CSR & RCC_CSR_LSIRDY)) {

8

    // Wait here until LSI is stable

9

  }

10

  // Unlock the IWDG registers

11

  IWDG->KR = 0x5555;  // Writing 0x5555 unlocks the control registers of IWDG

12

  // Set the prescaler (divides the LSI clock to determine the watchdog timeout)

13

  IWDG->PR = 0x03;  // Set prescaler to divide by 64 (prescaler values range from 0-7)

14

  // Set the reload value (this sets the timeout period)

15

  IWDG->RLR = 0x0FFF;  // Maximum reload value for the longest timeout

16

  // Start the watchdog timer

17

  IWDG->KR = 0xCCCC;  // Writing 0xCCCC starts the IWDG

18

  // Initialize serial communication for debugging purposes

19

  Serial.begin(115200);

20

  Serial.println("IWDG Initialized.");

21

22

}

23

24

void loop() {

25

  // The main loop where we periodically refresh the watchdog

26

  refreshIWDG();

27

  // Do some work here and simulate task delays

28

  Serial.println("Running tasks...");

29

  // Add some delay to allow tasks to run and avoid over-refreshing the watchdog

30

  delay(500);  // Example delay (this can be adjusted based on your requirements)

31

}

32

33

// Function to refresh the Independent Watchdog (IWDG)

34

void refreshIWDG() {

35

  // Unlock the IWDG registers

36

  IWDG->KR = 0x5555;  // Writing 0x5555 unlocks the control registers of IWDG

37

  // Write 0xAAAA to the KR (Key Register) to refresh the IWDG counter

38

  IWDG->KR = 0xAAAA;  // Writing 0xAAAA resets the watchdog timer counter

39

  Serial.println("IWDG Refreshed.");

40

}

Die dazu gesetzten Option Bytes:(PuyaISP!) IWDG_SW=0 WWDG_SW=1

1

Getting option bytes successfully!

2

AA 8E 55 71 FF 00 00 FF FF FF FF FF FF FF 00 00

Init, refresh, task:

1

IWDG Initialized.

2

11:55:38.887 -> IWDG Refreshed.

3

11:55:38.887 -> Running tasks...

4

11:55:39.420 -> IWDG Refreshed.

5

11:55:39.420 -> Running tasks...

Mal schauen ob ich (ist gar nicht so leicht) den pin finde der scheinbar "Hauptschalter" spielt.

Dann versuch ich diese version des code:

1

#include <Arduino.h> 

2

#include <SPI.h>

3

4

// Pin definitions for the LCD

5

#define LCD_PIN_RESET    4    // PB4: LCD Reset

6

#define LCD_PIN_CLOCK    3    // PB3: LCD Clock

7

#define LCD_PIN_DATA     5    // PB5: LCD Data

8

#define LCD_PIN_SELECT   8    // PA8: LCD Select

9

#define LCD_PIN_CMD_DATA 12   // PA12: LCD Command or Data

10

#define LCD_PIN_BACKLIGHT 11  // PA11: LCD Backlight

11

12

#define LCD_WIDTH   128

13

#define LCD_HEIGHT  160

14

15

// Some RGB565 colors

16

#define LCD_RGB565_BLACK    0x0000

17

#define LCD_RGB565_WHITE    0xFFFF

18

#define LCD_RGB565_RED      0xF800

19

#define LCD_RGB565_GREEN    0x07E0

20

#define LCD_RGB565_BLUE     0x001F

21

22

// Initialize SPI communication and GPIO

23

void setup() {

24

  // Enable the LSI (Low-Speed Internal) oscillator used by the IWDG

25

  RCC->CSR |= RCC_CSR_LSION;  // Enable LSI oscillator

26

27

  // Wait for the LSI to become ready

28

  while (!(RCC->CSR & RCC_CSR_LSIRDY)) {

29

    // Wait here until LSI is stable

30

  }

31

32

  // Unlock the IWDG registers

33

  IWDG->KR = 0x5555;  // Writing 0x5555 unlocks the control registers of IWDG

34

35

  // Set the prescaler (divides the LSI clock to determine the watchdog timeout)

36

  IWDG->PR = 0x03;  // Set prescaler to divide by 64 (prescaler values range from 0-7)

37

38

  // Set the reload value (this sets the timeout period)

39

  IWDG->RLR = 0x0FFF;  // Maximum reload value for the longest timeout

40

41

  // Start the watchdog timer

42

  IWDG->KR = 0xCCCC;  // Writing 0xCCCC starts the IWDG

43

44

45

  // Set up pin modes for control pins

46

  pinMode(LCD_PIN_RESET, OUTPUT);

47

  pinMode(LCD_PIN_CLOCK, OUTPUT);

48

  pinMode(LCD_PIN_DATA, OUTPUT);

49

  pinMode(LCD_PIN_SELECT, OUTPUT);

50

  pinMode(LCD_PIN_CMD_DATA, OUTPUT);

51

  pinMode(LCD_PIN_BACKLIGHT, OUTPUT);

52

53

  // Start SPI communication (SPI pins are pre-defined in Arduino)

54

  SPI.begin();

55

  SPI.setBitOrder(MSBFIRST);  // Set bit order to MSB first

56

  SPI.setDataMode(SPI_MODE0); // Set SPI mode to 0 (CPOL=0, CPHA=0)

57

  SPI.setClockDivider(SPI_CLOCK_DIV2); // SPI speed setting

58

59

  // Initialize the LCD

60

  LCD_GPIO_config();

61

  LCD_init();

62

  LCD_transfer_test();

63

}

64

65

// Main loop

66

void loop() {

67

  // Normally, you can add additional functionality here if needed.

68

  refreshIWDG();

69

}

70

71

// Set GPIO pins to control LCD functions

72

void LCD_GPIO_config() {

73

  digitalWrite(LCD_PIN_RESET, LOW);

74

  digitalWrite(LCD_PIN_CLOCK, LOW);

75

  digitalWrite(LCD_PIN_DATA, LOW);

76

  digitalWrite(LCD_PIN_SELECT, HIGH);  // Deselect

77

  digitalWrite(LCD_PIN_CMD_DATA, LOW); // Command mode initially

78

  digitalWrite(LCD_PIN_BACKLIGHT, HIGH); // Turn on backlight

79

}

80

81

// Reset the LCD

82

void LCD_Reset(int iReset) {

83

  if (iReset)

84

    digitalWrite(LCD_PIN_RESET, LOW); // Reset

85

  else

86

    digitalWrite(LCD_PIN_RESET, HIGH); // No reset

87

}

88

89

// Clock pulse for SPI

90

void LCD_Clock(int iClockLevel) {

91

  if (iClockLevel)

92

    digitalWrite(LCD_PIN_CLOCK, HIGH);

93

  else

94

    digitalWrite(LCD_PIN_CLOCK, LOW);

95

}

96

97

// Set LCD select pin (active low)

98

void LCD_Select(int iSelect) {

99

  if (iSelect)

100

    digitalWrite(LCD_PIN_SELECT, LOW);  // Select the display

101

  else

102

    digitalWrite(LCD_PIN_SELECT, HIGH); // Deselect the display

103

}

104

105

// Command mode (send command byte)

106

void LCD_Command(int iCommand) {

107

  if (iCommand)

108

    digitalWrite(LCD_PIN_CMD_DATA, LOW); // Command mode

109

  else

110

    digitalWrite(LCD_PIN_CMD_DATA, HIGH); // Data mode

111

}

112

113

// Send data byte through SPI

114

void LCD_send_SPI(uint8_t u8_byte) {

115

  SPI.transfer(u8_byte);

116

}

117

118

// Delay loop (adjust as necessary)

119

void delay_loop(int iDelay) {

120

  delay(iDelay);

121

}

122

123

// LCD initialization function

124

void LCD_init() {

125

  LCD_Select(1); // Select the LCD

126

  LCD_Command(1); // Command mode

127

128

  // Reset sequence

129

  LCD_Reset(0); 

130

  delay_loop(500);

131

  LCD_Reset(1);

132

  delay_loop(5000);

133

  LCD_Reset(0);

134

  delay_loop(12000);

135

}

136

137

// Send command byte

138

void LCD_send_CMD_byte(uint8_t u8_byte) {

139

  LCD_Select(1);

140

  LCD_Command(1); // Command mode

141

  LCD_send_SPI(u8_byte);

142

  LCD_Select(0); // Deselect the LCD

143

}

144

145

// Send data byte

146

void LCD_send_DATA_byte(uint8_t u8_byte) {

147

  LCD_Select(1);

148

  LCD_Command(0); // Data mode

149

  LCD_send_SPI(u8_byte);

150

  LCD_Select(0); // Deselect the LCD

151

}

152

153

// Send RGB565 data

154

void LCD_send_RGB565(uint16_t u16_rgb565) {

155

  LCD_send_DATA_byte((uint8_t)(u16_rgb565 >> 8));  // High byte

156

  LCD_send_DATA_byte((uint8_t)(u16_rgb565 & 0xFF)); // Low byte

157

}

158

159

// Test pattern (fill screen with different colors)

160

void LCD_transfer_test() {

161

  uint8_t u8_col_start = 0;

162

  uint8_t u8_col_end = LCD_WIDTH - 1;

163

  uint8_t u8_row_start = 0;

164

  uint8_t u8_row_end = LCD_HEIGHT - 1;

165

166

  LCD_send_CMD_byte(0x29);  // Display ON

167

168

  // Column and Row Address Set (2A, 2B)

169

  LCD_send_CMD_byte(0x2A);

170

  LCD_send_DATA_byte(0x00); // Start high

171

  LCD_send_DATA_byte(u8_col_start); // Start low

172