Okay, es ist für mich peinlich (aber nur ein bisschen), denn ich bekomme etwas einfach nicht hin.
Scheinbar bin ih ein Freund von wirklich ultrabilligen Elektronikbauteilen und der py32f002 ist so ein ultrabilliges Ding.
Nachdem ich erst PFS154 und dann ch32v003 hinbekommen habe, möchte ich jetzt auch gerne mit dem py32f002 "experimentieren" und das stellt sich für mich als harte Nuss heraus. Einen Programmer der zuverlässg validiert ist und unter Linux läuft finde ich nicht so wirklich, zudem habe ich Probleme mit einer Toolchain, die sich nicht compilieren läßt (ich arbeite auf der Konsole mit Makefile).
So, also wirklich viel experimentiert und Versuche gemacht mit ST-Link und openocd, dem fehlt natürlich eine korrekte Config-Datei und dann mit pyocd. Mit dem kann ich augenscheinlich eine Verbindung zum py32f002 herstellen, mir Register anschauen und auch, zumindest dem Output nach auch flashen.
Natürlich blinkt es nicht, weil ich eben auch keine Toolchain habe und ich so ein erstes Blinkprogramm mittels Linkerscript, Startup-Datei und C-Programm erstelle, welches sich auch compilieren läßt, aber nur ein 136 Byte großes Binary erstellt.
Um jetzt besser evaluieren zu können und feststellen zu können bräuchte ich ein Binary für eben genau den py32f002A, welches garantiert funktioniert um dann feststellen zu können, ob ich grundsätzlich einen Chip flashen kann und mich dann um eine Toolchain zu kümmern, oder ob ich erst weiter eine Möglichkeit suchen muß, um ein Programm auf den Chip zu flashen.
Wenn also jemand mit dem Ding arbeitet wäre es nett, wenn man mir ein Blinkprogramm zur Verfügung im Format .elf und .bin zukommen lassen könnte. Natürlich mit der Angabe, auf welchem Port es blinken soll.
Hatte ich auch gefunden gehabt, aber das ließ sich auch nach Anpassungen nicht fehlerfrei übersetzen. Der Linker macht hier Ärger und ich müßte mir das ganze noch viel genauer ansehen. Grundsätzlich wollte ich das schon als Basis nehmen.
Fehler kann natürlich auch verursacht dadurch sein, dass mein arm-none-eabi-gcc schon deutlich alt ist: Version 6.2 aus dem Jahr 2016.
Ich möchte das dennoch nicht updaten, weil meine ganzen anderen Projekte von stm32f0 bis H7 oder nxp dann vielleicht unangenehme Seiteneffekte zeigen.
Hm, wenn das bei dir läuft, kannst du mir ein Blinkbinary erstellen und hier posten ?
nachtrag, ich hab da jetzt mal parallel einen arm-none-eabi-gcc Version 15.2 installiert und damit läßt sich die toolchain übersetzen ... ich bin gespannt!
Verstehe ich nicht!
Welcher Compiler verwendet werden soll, steht doch im Makefile.
Oder kann man zumindest da rein schreiben.
deswegen hab ich die neueste Version jetzt parallel installiert und habe ein Makefile gemacht, nur für py32. Übersetzt korrekt, aber blinken tut immer noch nix.
Flashen, wie es sich mir darstellt, kann ich scheinbar, nur am Programm sollte ich suchen:
Ob das auch auf den PY32F002A läuft weiss ich nicht und ich habe auch
nicht vor das auszuprobieren (ich habe keinen von beiden da).
ich hab das ausprobiert, es blinkt leider nicht. Dateien kann ich mittlerweile ja selbst kompilieren und ich denke dass ich irgendwoher einen käuflich zu erwerbenden Programmer besorgen muß.
und ich denke dass ich irgendwoher
einen käuflich zu erwerbenden Programmer besorgen muß.
Sollte nicht SWD standardisiert sein?
Nicht nur "sollte", sondern ist es ja auch. Aber in meiner Unwissenheit fange ich an (Asche über mein Haupt) auch die Dinge zu hinterfragen, die mir schwarz auf weiss (im Falle der Konsole weiss auf schwarz :-) ), gezeigt werden und pyocd sagt mir, dass der Code im Controller angekommen ist.
Das ist ja ein ganz normaler Cortex-M0, hast Du geschaut ob im Flash
auch das steht was Du reingeschrieben hast?
Habe ich gemacht und augenscheinlich ist der Code dort, wo er sein soll.
Hrmpf.... aber ich denke ich setze mich am Wochenende noch einmal hin, irgendwie nagt das an meinem Ehrgeiz, dass das nicht funktioniert und dann werde ich noch einmal das nicht ganz so tolle Datenblatt befragen und ein Linkerscript und Startupfile machen....
Habe ich gemacht und augenscheinlich ist der Code dort, wo er sein soll.
Dann vielleicht den Blink-Code auf Assembler-Ebene per SWD debuggen, das ist ja nicht so viel und man sieht genau was passiert. Mögliche Fehler wie z.B. endloses Warten findet man so sehr schnell.
Einen Programmer der zuverlässg
validiert ist und unter Linux läuft finde ich nicht so wirklich,
Ich verwende einen WCH-DAPLink-R0-2v0.
(ich arbeite auf der Konsole mit Makefile).
Ich auch.
So, also wirklich viel experimentiert und Versuche gemacht mit ST-Link
und openocd, dem fehlt natürlich eine korrekte Config-Datei und dann mit
pyocd. Mit dem kann ich augenscheinlich eine Verbindung zum py32f002
herstellen, mir Register anschauen und auch, zumindest dem Output nach
auch flashen.
Mit openocd bin ich auch nicht klargekommen und habe dann pyocd genommen.
Um jetzt besser evaluieren zu können und feststellen zu können bräuchte
ich ein Binary für eben genau den py32f002A, welches garantiert
funktioniert um dann feststellen zu können, ob ich grundsätzlich einen
Chip flashen kann und mich dann um eine Toolchain zu kümmern, oder ob
ich erst weiter eine Möglichkeit suchen muß, um ein Programm auf den
Chip zu flashen.
In Userverzeichnis unter .config/SEGGER/JLinkDevices/Puya/PY32/
liegen bei mir die Dateien aus dem template und ich kann problmemlos mit den F002A (QFN16, QFN20 kannst du über serial flashen) kommunizieren.
Vielen Dank für die vielen Rückmeldungen und ich werde bevor ich weiter mache zum einen eine neue Lieferung Chips von LCSC.COM abwarten und zum anderen morgen versuchen, mit einem uralten Segger J-Link Version 6.0 das Teil zu flashen.
