CH32V003 Resetverhalten

[Vanye R. (vanye_rijan)]

Ich benutze den CH32V003 im SOT8(!) jetzt schon so ein Jahr fuer diverse 
kleine Spielereien. Bisher hat alles im grossen und ganze so 
funktioniert wie ich mir das vorstelle. Aber gelegentlich kam es schon 
mal zu irgendeinem komischen Verhalten und ich hab das Teil dann mit 
minichlink -u wieder auf die Beine geholfen.

Aktuell hab ich gerade eine kleine Anwendung laufen die nichts anders 
macht als mit tim1 300khz erzeugen zu lassen und dies an PC4, PA1 und 
PA2 auszugeben.
Das funktioniert auch! Aber erstaunlich oft haengt sich der Controller 
beim starten weg! Das Programm laeuft dann direkt nach dem flashen wenn 
es vom debugger gestartet wird, aber nur sehr gelegentlich nach einem 
Powercycle in meiner Hardware.

Ich wuerde ja sagen irgendwas stimmt mit meiner Resetbeschaltung nicht, 
aber der SOT8 hat keinen Reseteingang.
Ich hab auch schon minichlink mit -d oder -D probiert ohne das ich da 
eine Besserung sehen wuerde.

Hab ich da was uebersehen?

Vanye

[Cyblord -. (cyblord)]

Vanye R. schrieb:
> Hab ich da was uebersehen?

Abblockkondensatoren

[Vanye R. (vanye_rijan)]

Ja, der Gedanke liegt natuerlich nahe. Ich hatte aber schon direkt an 
den Beinen des SOT8 einen 100nF drueber geloetet. Und mehr ist da ja 
nicht....

[Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)]

Häng mal ein Oszi an den Versorgungsspannungseingang und nimm den 
Verlauf auf.

[Vanye R. (vanye_rijan)]

Ich hab da wohl wirklich einen Bug der Extraklasse in meinem System. :-D

Mein Programm sieht so aus:

int main()
{
  SystemInit48HSI();        //Systemclock auf 48Mhz setzen
  pwm_init();               //PWM Initialisieren fuer 300khz an PA1 und 
PA2
  while(1);
}

Das funktioniert IMMER wenn ich es vom Debugger in den STM32V003 
reinlade. Stoepsel ich den Debugger an und lasse es ueber mein 
Labornetzteil laufen, so funktionier es meistens nicht. Aber so jedes 
30-40x startet es doch und laeuft dann auch!
Wenn es nicht läuft dann kommen komische Impulse aus PA2 raus. (siehe 
Bild)
Kommentiere ich SystemInit48HSI() aendert sich nichts am problematischen 
Startverhalten, aber wenn es geht dann sind natuerlich die Frequenzen 
anders weil der Systemtakt niedriger ist.


Als ich damals meine Umgebung aufgesetzt habe, da habe ich ch32fun 
kopiert und als erstes ein einfaches LED-Blink Programm geschrieben. Das 
zeigt dieses verhalten nicht! Es startet also immer.


Nehme ich das als Basis und änder das auf obiges main ab, so 
funktioniert es auch immer! Der Timer gibt also die gewuenschten Signale 
aus.


Danach hab ich damals etwas am "Design" der Umgebung rumgespielt. Also 
nur die Libaries kopiert die ich brauche, andere Verzeichnisse, Startup 
verschlankt, usw. Dabei muss ich wohl einen Fehler gemacht haben der mir 
nicht aufgefallen ist weil es halt immer problemlos funktioniert wenn es 
ueber den Debugger gestartet wird.
Da muss ich wohl noch mal tief in mich gehen und beide Startupcodes 
genau vergleichen. Vermutlich initialisiert der Debugger irgendetwas das 
ich selber vergessen habe. Aber bizarr das es manchmal halt doch 
funktioniert.

Vanye

[Harald A. (embedded)]

Weiß nicht, ob es das bei diesem Controller auch gibt, aber die NXP LPC 
Controller können ähnlich herumzicken, wenn man die Brown-Out BOD nicht 
sofort als erstes beim Reset setzt.

[Harald K. (kirnbichler)]

Harald A. schrieb:
> Weiß nicht, ob es das bei diesem Controller auch gibt

Tut es:

1.4.4 Power Supply Monitor

This product integrates a power-on reset (POR)/power-down reset (PDR) 
circuit, which is always in working condition to ensure that the 
system is in supply. It works when the power exceeds 2.7V; when VDD 
is lower than the set threshold (VPOR/PDR), the device is placed in 
the reset state without using an external reset circuit.

In addition, the system is equipped with a programmable voltage 
monitor (PVD), which needs to be turned on by software to compare 
the voltage of VDD power supply with the set threshold VPVD.
Turn on the corresponding edge interrupt of PVD, and you can 
receive interrupt notification when VDD drops to the PVD threshold 
or rises to the PVD threshold. Refer to Chapter 4 for the values of 
VPOR/PDR and VPVD.

(Seite 5 im Datenblatt CH32V003 V1.7)

[Vanye R. (vanye_rijan)]

Ich muss den Thread noch mal nach oben holen, weil ich gerade etwas Zeit 
gefunden habe mich damit zu beschaeftigen und etwas Rat gebrauchen 
koennte. :)

Zuerst mal die Probleme hier treten mit verschiedenen Programmen auf. 
Ich denke daher nicht das sie an einem Programmierfehler in einem 
bestimmten Programm liegen. Im folgenden betrachten wir aber nur ein 
Programm!

int main()
{
  SystemInit48HSI();        //Systemclock auf 48Mhz setzen
  pwm_init();               //PWM Initialisieren fuer 300khz an PA1 und PA2
  uart_write(buffer, 0);    //Bullshit, dazu später mehr!
  while(1);
}

Hier noch mal mein Hardfault handler

void HardFault_Handler(void)
{

  //Port PA2 als Ausgang für LED initialisieren                                                            
  RCC->APB2PCENR |= RCC_APB2Periph_GPIOA;
  GPIOA->CFGLR &= ~(0xf<<(4*2));
  GPIOA->CFGLR |= (GPIO_Speed_10MHz | GPIO_CNF_OUT_PP)<<(4*2);

  //LED blinkt so grob 5x pro Sekunde mit LED an PA2.                                                      
  volatile int i;
 doof:
  GPIOA->BSHR = (1<<2);                // PA2 = grüne LED auf High setzen                                  
  i=100000; while(i-- > 0);
  GPIOA->BSHR = (1<<16) | (1<<(16+2)); //grüne LED auf low=aus setzen                                      
  i=100000; while(i-- > 0);
  goto doof;


}

Uebersetze ich das und lade das mit dem Debugger in mein Testboard so 
passiert das erwartete. Der in pwm_init() initialisierte Timer gibt mir 
ein PWM/Rechteck an PA1 und PA2 aus. Die CPU selber bleibt in der 
whileschleife stehen. Alles wie erwartet.

Die Zeile:
   uart_write(buffer, 0);
gibt einen Buffer von 0Byte aus. Macht also nix!

Kommentiere ich die aus so wird mein Programm um ein paar hundert Byte 
kleiner weil der Compiler erkennt das diese Funktionen die dahinter 
haengen nicht aufgerufen werden. Eine der nicht genutzten Funktionen 
liegt im Flash-Speicher vor main. Hier mal ein Ausschnitt aus dem 
mapfile mit uart_write

 *(.text.*)
 .text.uart_getFifoSend
                0x00000000000000a0       0x2e /tmp/ccvJfodc.ltrans0.ltrans.o
 .text.startup.main
                0x00000000000000ce      0x216 /tmp/ccvJfodc.ltrans0.ltrans.o
                0x00000000000000ce                main
 .text.USART1_IRQHandler
                0x00000000000002e4       0x6c /tmp/ccvJfodc.ltrans0.ltrans.o

und hier ohne:

 *(.text.*)
 .text.startup.main
                0x00000000000000a0      0x1b4 /tmp/ccPdPsYu.ltrans0.ltrans.o
                0x00000000000000a0                main
 .text.USART1_IRQHandler
                0x0000000000000254       0x84 /tmp/ccPdPsYu.ltrans0.ltrans.o

Im zweiten Fall bin ich mir ziemlich sicher das mein "main" garnicht 
mehr aufgerufen wird. Der CH32 wirft einen HardFault und ich sehe meine 
LED blinken die ich dort im Handler ansteuere.

Auch wenn ich vor der Uartaufruf einen while(1) einfuege funktioniert 
das Programm nicht mehr. Grund dafuer ist das der Compiler erkennt das 
uart_write nicht aufgerufen wird und alle ungenutzten Funktionen aus dem 
Programm wirft. Spiele ich aber etwas mit den Compileroptionen

  -flto -ffunction-sections -fdata-sections

Llaesst er den Code drin und das Programm laeuft wieder.

Funktion und Nichtfunktion haengt also davon ab an welcher Stelle main 
im Programm steht! Das erstaunt mich!  Dabei wird main aus dem 
startupCode aufgerufen:

  //Sprung nach Main                                                                                       
  __set_MEPC( (uint32_t)main );
  // set mepc to be main as the root app.                                                                  
  asm volatile( "mret\n" );

Ich sehe nicht wieso das manchmal gehen soll und wieso manchmal nicht!

Aber es kommt noch besser! All das gesagte gilt immer wenn ich das 
lauffaehige Programm ueber den angeschlossenen Debugger in die MCU 
reinlade.

./minichlink -3w ./template.bin flash -b

Dabei ist meine TestPlatine die ganze Zeit am Debuger angeschlossen und 
wird auch von diesem mit Spannung versorgt. Ziehe ich die Platine ab und 
steck sie wieder an, oder versorge sie extern mit Spannung, funktioniert 
das Programm auch nicht mehr richtig. Ich lande dann wieder im 
Hardfaulthandler!

Ein paar brilliante Ideen wie man da weiter kommt? :)

Vanye

[Ont E. (ont_e)]

Keine Idee, aber super interessanter Krimi...

Im Falle vom UART Code, er ja dann da liegt wo "main nicht tut", wenn du 
mal ein Byte sendest, so dass er da auch "durchlaufen muss", knallt es 
dann auch?

[Klaus R. (klausro)]

Vanye R. schrieb:
> Ein paar brilliante Ideen wie man da weiter kommt? :)

Knifflig. Einen "frischen" CH32V003 hast du schon probiert? Nicht dass 
das Flash (schon) Macken hat und beim "miteincompilieren" von 
uart_getFifoSend liegt das im fehlerhaften Flash (und wird ja nicht 
benutzt...)

[Vanye R. (vanye_rijan)]

> Knifflig. Einen "frischen" CH32V003 hast du schon probiert?

Klar. Hab ja genug. Es liegt nicht an einem defekten CH32V003.
Ich hab sogar zwei verschiedene Chargen, einmal in SOT8 und
einmal in SOT16. Beide identisches Verhalten.

Ich hab gerade mal eine Ausgabe des mcause Register programmiert,
dazu schreibe ich gleich noch was im anderen Thread. Ist vielleicht doof 
das ich das getrennt habe, aber ist vielleicht auch von allgemeineren 
Interesse wenn man dieses Register auslesen kann.

Jedenfalls fuehrt das nun dazu das der code mit auskommentierten
usart_write immer noch laeuft. Aber nicht wenn ich das Teil
neu starte. Dann gibt es Hardfault, noch dazu einen sehr merkwuerdigen.

Aber dazu anderer Thread.

Vanye