Teensy 4 komplett Absturz nach änderung eines Makros

Hallo Leute, bei meinem Teensy 4 Licht TRX ist seit gestern die Defekt Hexe zu Gange.

Aber von Anfang an:
Bei meinem Licht TRX gebe ich beim starten auf den Display immer die aktuelle Versionsnummer aus.
Dazu nutze ich ein Makro #define TRX_VERSION „2.0.0008“ z.B

In der setup Funktion findet das Makro seine Verwendung Main_Display->_init(TRX_VERSION, WIFI_VERSION);

danach wird es Eigentlich nicht mehr benötigt.
Passenderweise haben meine Sketch Datei Namen auch diese Versionsnummer.
Sonnst komme ich irgendwann nicht mehr klar.

Gestern Abend lege ich nun eine Sketch Kopie an version 2.1.0009,
weil ich eine WAV-Datei Wiedergabe von der SD-Karte einbauen möchte
und änder selbstverständlich auch das Makro auf TRX_VERSION „2.1.0009“

Der TRX beinhaltet diverse Betriebsarten wie AM, FM,CESSB,1000Hz Dauerton,CW usw.
Diese werden via PCF8575 geschaltet.

Die Betriebsart FM stellt immer eine besondere Herausforderung dar, Speziell die Demodulation, da sind 5 FIR filter in Gange ein Komplexer Mischer der ein IQ Signal erzeugt und ein PLL Demodulator, der die NF erzeugt.

Ich habe nun nach und nach die Betriebsarten durch getestet und die WAV Datei ausgegeben.
Da habe ich mich gefreut wie Bolle das das auf Anhieb ging.
Biss…. FM dran kam.

Sowie die FM Modulation einlegt wird, nix total Absturz, Teensy friert ein und bootet neu.

Ich habe dann irgendwann alles was mit WAV und SD zugriff zu tun hat auskommentiert / gelöscht.
Und immer noch bei FM, Absturz.

Da kann ja nur noch der Teensy defekt sein, dachte ich.

Habe dann die Version 8 aufgespielt und die ging tadellos. Version 0009 nach wie vor geht nicht.
Irgendwann kam mir dann in den Sinn, es kann nur noch das Makro dran schuld sein.

Ich habe drauf hin Version 8, die ja läuft genommen und einfach nur das Makro auf .0011 geädert und zack nix geht mehr.

Der Funktions Aufruf für die FM ist ein wenig komplex:


void Modulation_FM(byte modNr) {
if (modNr != actualModulation) {
AudioNoInterrupts();
if (thisFs < AUDIO_SAMPLE_RATE_EXACT * 2) {
audioOutI2S1.begin(false, AUDIO_SAMPLE_RATE_EXACT * 2);
thisFs = AUDIO_SAMPLE_RATE_EXACT * 2;
}
isModOff = false;
CW_Filter_IIR.end();
if (blinkerTimer) {
delete blinkerTimer;
blinkerTimer = NULL;
}
if (actualModulation == 3) {
detachInterrupt(digitalPinToInterrupt(PIN_HANDTASTE));
}
compressorBypass(false);
FilterLowpassFIR_TX.begin(Coeffs_FM_lowpass, LEN_FM_LOWPASS);
modulationSelect1.setChannel(0);
select_Analog_Blinker.gain(0, 1);
select_Analog_Blinker.gain(1, 0);
select_Analog_Blinker.gain(2, 0);
select_Analog_Blinker.gain(3, 0);
reset8PortMix();
modulationSelect2.gain(0, 1);
FIR_Filter_RX_input.begin(FM_RX_Filter, LEN_FM_BANDPASS_RX);
demodulationSelect1.setChannel(0);
demodulationSelect2.gain(0, 1);
demodulationSelect2.gain(1, 0);
demodulationSelect2.gain(2, 0);
demodulationSelect2.gain(3, 0);
if (last_PTT_value) {
SGTL5000.dacVolume(0, 1);
} else {
SGTL5000.dacVolume(1, 0);
}
if (mqsOut) {
patchCord_i->disconnect();
mqsOut->end();
delete mqsOut;
mqsOut = NULL;
}
if (!fm_out) {
fm_out = new outputFM();
fm_out->setAmplitude(99);
patchCord_i->connect(amp1, 0, *fm_out, 0);
fm_out->enable(true);
}
digitalWrite(WIFI_FS_READY_PIN, HIGH);
actualModulation = modNr;
Serial.println("Modulation FM");
if (Main_Display) {
Main_Display->modulationIdx = 5;
}
AudioInterrupts();
}
}

Witziger weise erscheint noch im Serielenl Monitor Serial.println("Modulation FM");
aber das Display springt nicht mehr auf FM, logisch gerendert wird erst wenn er wider in die loop geht und dazu muss er an AudioInterrupts(); vorbei.
Mittlerweile habe ich nun auch herausgefundenn, dass wenn ich

if (mqsOut) {
patchCord_i->disconnect();
mqsOut->end();
delete mqsOut;
mqsOut = NULL;
}
if (!fm_out) {
fm_out = new outputFM();
fm_out->setAmplitude(99);
patchCord_i->connect(amp1, 0, *fm_out, 0);
fm_out->enable(true);
}

auskommentiere , kann ich auch das Makro nach belieben ändern.

Aber ich versteh den Zusammenhang zwischen der FM Funktion und dem Makro nicht?????
Mittlerweile habe ich ein char array angelegt
const char TRX_VERSION[] = "2.1.0009b";

Das funktioniert auch. Keine Probleme seit dem.

Der einzige zusammen Hang der zwischen dem Makro und der FM liegt ist der FLASH
..es folgt gefährliches Halbwissen:

Das Makro liegt meins wissen nach im Flash und die Funktionen werden auch vom Flash aus aufgerufen, es kann also nur sein ,das sich hier die Wege kreuzen und der Teensy abstürzt.

Ein anderes Problem könnte der Compiler/Linker sein, das der irgendwie defekt ist.
Das Char array liegt ja im RAM und das funktioniert ja. Also ist ein RAM überlaufen/defekt ausgeschlossen.

Ich meine: ich habe das Problem ja "gelöst " aber hat so ein Problem schon mal wer gehabt???

Das ist doch eine reine Textersetzung. Das liegt weder im Flash noch RAM. Das läuft vor dem kompilieren ab.

Wirft dein µC eine Exception, beim Misserfolg, oder liefert es einfach nur Null als Adresse?

Ja Stimmt, wollte ich gestern noch korrigieren.
Das Makro wird ja nur in meine init(TRX_VERSION, WIFI_VERSION); "ein kopiert".

Da passiert gar nix. Ich habe ja auf dem Teensy das Audio shield sitzen um am LineOut habe ich ein Lautsprecher. Kurz vom Absturz hört man ein"Quiek". Es hört sich an wie ein Digital Bus Sound die Clock vom I2s eventuell.

Gestern Abend ist mir dann noch ein Problem aufgefallen.
Die Betriebsarten werden mittels eine Drehschalter (12 Pin) geschaltet, wie gesagt über einen PCF8575.
Dreht man zu weit kommt die Betriebsart "Aus". Also alle dac Ausgänge auf aus setzen

void Modulation_AUS(byte modNr) {
  if (modNr != actualModulation) {
    AudioNoInterrupts();
    if (actualModulation == 3) {
      detachInterrupt(digitalPinToInterrupt(PIN_HANDTASTE));
    }
    CW_Filter_IIR.end();
    FilterLowpassFIR_TX.end();
    FIR_Filter_RX_input.end();
    isModOff = true;
    if (blinkerTimer) {
      delete blinkerTimer;
      blinkerTimer = NULL;
    }
    modulationSelect1.setChannel(3);
    SGTL5000.dacVolume(0);
    amp1.gain(0);
    if (mqsOut) {
      patchCord_i->disconnect();
      mqsOut->end();
      delete mqsOut;
      mqsOut = NULL;
    }
    if (fm_out) {
      patchCord_i->disconnect();
      delete fm_out;
      fm_out = NULL;
    }
    digitalWrite(WIFI_FS_READY_PIN, LOW);
    Serial.println("AUS");
    actualModulation = modNr;
    if (Main_Display) {
      Main_Display->modulationIdx = 8;
    }
    AudioInterrupts();
  }
}

Er friert auch hier komplett ein.
Ich konnte eingrenzen das ea an diesem block liegt:

 if (mqsOut) {
      patchCord_i->disconnect();
      mqsOut->end();
      delete mqsOut;
      mqsOut = NULL;
    }

Der einzige unterschied der Zwischen FM und AUS besteht ist, das patchCord_i->disconnect(); getrennt wird aber nirgendwo wider verbunden.

Verbinde ich dann wider das Patchcord
mqsOut = new AudioOutputMQS();
patchCord_i->connect(amp1, 0, *mqsOut, 0);
Dann funktioniert alles

Hier bei der Sache kann ich mir vorstellen, das das Kritisch ist. Weil die Audio lib will immer ein Trigger Objekt, das ist entweder fm_out oder mqsOut.
Das patchcord wird wie folgt initialisiert AudioConnection *patchCord_i = new AudioConnection(amp1, 0, *mqsOut, 0);

Eigentlich dürfe das nicht stören, weil alle Puffer von amp1 laufen ins leere.

Zudem version 8 funktioniert ja :exploding_head:

Nebenbei fällt mir ein ich hatte auch mal einen Teensy 3.6 mit einem Bug.
Bei dem ersten LIcht TRX auf Basis des T3.6 hatten wir 8 Stück in Umlauf gebracht alle mit der selben Software. Alle Teensy sind auf 250Mhz übertaktet

Aber einer von den ist nach einer Random Zeit X einfach stehen geblieben. Aus dem DAC pin kam nun noch Krach.
Nach langen Hin und her habe ich herausgefunden, wenn man diesen teensy auf nur 240Mhz übertaktet läuft dieser.
Aber weshalb ist unklar.?

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.