py32v002A: Blink-Binary "gesucht"

[Ralph S. (jjflash)]

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.

Viele Grüße,
Ralph

[Dieter S. (ds1)]

Das hier kennst Du?

https://github.com/TDLOGY/py32f0-template-project

Da steht zwar "PY32F0 Template Project for Windows" aber das läßt sich 
ohne Probleme mit dem GCC für ARM übersetzen.

Für einen PY32F030 habe ich das als Basis für "Bare Metal" Code 
genommen, funktionierte problemlos.

Nachtrag: Das hier sollte man auch anschauen

https://github.com/IOsetting/py32f0-template

https://github.com/jaydcarlson/py32-template

[Ralph S. (jjflash)]

Dieter S. schrieb:
> Das hier kennst Du?
>
> https://github.com/TDLOGY/py32f0-template-project
>
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 ?

[Arduino F. (Firma: Gast) (arduinof)]

Ralph S. schrieb:
> Ich möchte das dennoch nicht updaten, weil meine ganzen anderen Projekte
> von stm32f0 bis H7 oder nxp dann vielleicht unangenehme Seiteneffekte
> zeigen.

Verstehe ich nicht!
Welcher Compiler verwendet werden soll, steht doch im Makefile.
Oder kann man zumindest da rein schreiben.

[Ralph S. (jjflash)]

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!

[Dieter S. (ds1)]

Ralph S. schrieb:
>
> Hm, wenn das bei dir läuft, kannst du mir ein Blinkbinary erstellen und
> hier posten ?

In

https://github.com/IOsetting/py32f0-template

gibt es nur Beispiele für den PY32F002B.

Ich habe mal auf die Schnelle "Examples\PY32F002B\LL\GPIO\GPIO_Toggle" 
ausprobiert, mit einem alten GCC 6.2.1 geht das problemlos.

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).

Im Anhang ist das erzeugte Binary, der PIN ist GPIOA Pin 1, aus dem 
Code:

LL_GPIO_TogglePin(GPIOA, LL_GPIO_PIN_1);

[Ralph S. (jjflash)]

Arduino F. schrieb:
> 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:

(gdb) load app.elf
Loading section .isr_vector, size 0xc0 lma 0x8000000
Loading section .text, size 0x57c lma 0x80000c0
Loading section .init_array, size 0x4 lma 0x800063c
Loading section .fini_array, size 0x4 lma 0x8000640
Loading section .data, size 0xc lma 0x8000644
Start address 0x80005d0, load size 1616
Transfer rate: 46 KB/sec, 323 bytes/write.
(gdb)

[Ralph S. (jjflash)]

Dieter S. schrieb:
> 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ß.

Grrrrr.....

[Dieter S. (ds1)]

Mit einem J-Link geht es.

Das ist ja ein ganz normaler Cortex-M0, hast Du geschaut ob im Flash 
auch das steht was Du reingeschrieben hast?

[Harald K. (kirnbichler)]

Ralph S. schrieb:
> und ich denke dass ich irgendwoher
> einen käuflich zu erwerbenden Programmer besorgen muß.

Sollte nicht SWD standardisiert sein?

[Ralph S. (jjflash)]

Harald K. schrieb:
> Ralph S. schrieb:
>> 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.

Dieter S. schrieb:
> 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....

:-) :-) :-) :-) wäre doch gelacht !

[Dieter S. (ds1)]

Ralph S. schrieb:
>
> 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.

[Arne R. (ebps)]

Moin Ralph,

Ralph S. schrieb:
> 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.

Ist zwar etwas mehr als nur Blinken, aber ich habe mit dem PY32F002A 
dieses Projekt veroeffentlicht: 
https://wiki.blinkenarea.org/index.php/DuckMini#Version_5.0 - vielleicht 
ist es dir hilfreich. Ein fertiges Hexfile ist dabei.

[Kilo S. (kilo_s)]

Ich benutze einen J-Link OB Klon dafür.

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.

[Kilo S. (kilo_s)]

Anklemmen, Konsole:

JLinkExe -device PY32F002Ax5 -if SWD -speed 4000  -CommandFile jump_bootloader.jlink

Per Arduino und serial geht so auch das flashen der F002A in QFN16.

[Kilo S. (kilo_s)]

Sorry für die Verteilung, springe zwischen Laptop und Smartphone.

Pinout:(QFN16)
4=SWDC, 3=SWDIO, 5=RESET, 8=TXD (Serial RXD) 9=RXD, PAD=GND, 14=VCC.

[Kilo S. (kilo_s)]

Arduino IDE Blink an Pin1 (PB1) meines QFN16.


PuyaISP eine option?

Beitrag "Re: PY32F002AW15, Dump trotz RDP Level 1."

Sag mir welchen pin du brauchst, ich erstelle dir per arduino ein bin.

[Ralph S. (jjflash)]

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.

[Kilo S. (kilo_s)]

Moin.

Wozu warten?

LoadFile (.bin only) 0x08000000
r
g

Funktioniert einwandfrei.

Welches pakage hast du vorliegen?

Unter der Vorraussetzung das du einen zugänglichen BOOT0 Pin hast, 
reicht auch ein einfacher UART Adapter aus.

[Kilo S. (kilo_s)]

Entpacke die nach:/home/DEINUSERNAME/.config/SEGGER/JLinkDevices/

Dort findest du dann die ordner:Puya/PY32/ und darin die *.xml und *.FLM 
dateien.