Forum: Offtopic 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

}