intermittent code execution Audio Rev D + Teensy 4.1

Status
Not open for further replies.

propa

Well-known member
Hi,

Got a Teensy 4.1 and Rev D shield, trying to just get the audio passthrough working, and it's execution is intermittent, not predictable. I uploaded once successfully, but once the board is unplugged and plugged back in it ceases to work.

Just using simple passthrough example, and have neither been able to change the volume from external pot, nor could I get this code to work again after unplugging and pluggin the Teensy once it was working.

Code:
/*
 * A simple hardware test which receives audio from the audio shield
 * Line-In pins and send it to the Line-Out pins and headphone jack.
 *
 * This example code is in the public domain.
 */

#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

// GUItool: begin automatically generated code
AudioInputI2S            i2s1;           //xy=200,69
AudioOutputI2S           i2s2;           //xy=365,94
AudioConnection          patchCord1(i2s1, 0, i2s2, 0);
AudioConnection          patchCord2(i2s1, 1, i2s2, 1);
AudioControlSGTL5000     sgtl5000_1;     //xy=302,184
// GUItool: end automatically generated code


const int myInput = AUDIO_INPUT_LINEIN;
//const int myInput = AUDIO_INPUT_MIC;


void setup() {
  // Audio connections require memory to work.  For more
  // detailed information, see the MemoryAndCpuUsage example
  AudioMemory(12);

  // Enable the audio shield, select input, and enable output
  sgtl5000_1.enable();
  sgtl5000_1.inputSelect(myInput);
  sgtl5000_1.volume(0.8);
  delay(20);
}

elapsedMillis volmsec=0;

void loop() {
  // every 50 ms, adjust the volume
//  if (volmsec > 50) {
    float vol = analogRead(18);
    //Serial.println(vol);
    vol = vol / 1023.0;
    sgtl5000_1.volume(vol); // <-- uncomment if you have the optional
//    volmsec = 0;               //     volume pot on your audio shield
//  }
}

I've never had this sort of problem before with any of the 3.2 or 3.6, or other Audio Shields

Using Teensyduino 1.53, 1.8.13

Is this Audio board a dud? Unplugging while audio was playing into jack wouldn't hurt the audio board?
 
What happens without the code for the pot?
Where is the potentionmeter connected (Audioshield? I remember its pin 15 , not 18) , and which resistance?
Don't use 18! It is needed for I2C!

Normally, this kind of distortions happen with a bad connection between Teensy and Audio shield (and this is the case with a pot on pin 18, too...)
 
hi,
looks like you are setting the volume every cycle of loop (rather than every 50ms) - that must be a lot of times a second, that might be a the problem?

try changing that, press the button on the teensy to enter programme mode and update it,

Cheers, Paul
 
I've got it working again, seems to be this pin 18 issue, I'd set to serial print, and that messes up everything.

I thought I could connect any analog pot to control the audio volume, didn't realise it was hard mapped to 15.

I solved by switching USB to Audio, then uploaded, then switched back to serial, and everything seems to work fine again.

Just now broke it again, but putting

Code:
"float vol = analogRead(18);
 Serial.println(vol);"

Confirms DON'T DO THIS. I could actually print the value when first uploaded, but unplugging and plugging back in borks it.

Hope I can get it back to working mode again
 
So I've completely screwed the audio shield now? Can't get it back to working state again.

Any trick I can do? I tried switching from USB audio device to Serial and sadly it's not un-borking it
 
Had you shorted pin18 to ground or 3.3V via a pot? That could lead to damage.

yeah probably if there's a pot connected to it.

Damage, really, doesn't explain why I've been able to fix twice from same error.

(Like I said I've been able to serial print values from pin 18 while audio was coming out, I guess I would have heard a break up of sound or discontinuity/distortion if that were the case, but seemed fine while doing it, so I don't follow the damage theory)
 
I got it working after the millionth time of uploading. Glad I didn't buy your damaged idea.

It worked at one point, which I why I called the thread intermittent execution, just badgered on with it. But yeah ok never using the 18/19 pins for audio again, lesson learned. My personal list of reserved pins was "7, 8, 20, 21, 23", I didn't write shareable pins, like miss remembering and thinking the shareable meant shareable not just with other i2c devices.
 
Sometimes, with the SGTL, its a good idea to power-cycle it.
It has no reset. The only reset happens on power on, when it gets the first clock cycles.
A teensy reboot does _not_ reset the Audio shield. There is just no way to reset it.
 
ok brilliant thanks, I wondered what got "stuck" as it were.

just random idea thought...

Can we adapt the compiler warnings if SGTL/audio shield is detected in code? For the first time players, just bail from compilation if a reserved pin on audio shield is detected?

“I’ve seen you’ve got a reserved pin in use, I’m sure you know what you’re doing, but here’s a list of reserved pins the Teensy needs for functioning: 7, 8, 20, 21, 23. AAAnd 18/19, define forceCompile if you’re a bad ass and want to ignore these warnings”
 
Can we adapt the compiler warnings if SGTL/audio shield is detected in code? For the first time players, just bail from compilation if a reserved pin on audio shield is detected?

Short answer is "probably not".

There are so many technical issues. In the case of pins 18 & 19, where talking about I2C by the Wire library. On Teensy 4.0 there are no alternate pins, but other models do have alternates. So simply having an instance of Wire doesn't necessarily mean pins 18 & 19 are in use. With boards that support alternate pins, the setSCL() and setSDA() functions could cause Wire to use other pins, making 18 & 19 available. It's also possible to use those functions to dynamically reassign as your program runs (but doing so while Wire is working obviously causes communication errors).

Other Arduino functions to use the pin include pinMode, analogWrite and attachInterrupt. Those could be in different files or even embedded inside libraries. It's also possible to use direct register access or pointers to registers to manipulate pins, and many libraries do indeed use that more complicated approach because it runs faster on many boards.

Even if the compiler could somehow parse and recognize which pins are used by all those sorts of code, there is also the possibility of code using actual variables for the pins (where the value of the variable can't be known until the program runs), rather than constants that are known to the compiler as it generates code.

So even if you tried to do something really exotic with the linker script, like a dummy memory section of size 1 for each pin, and maybe some really creative use of macros or templates to convert function arguments into dummy allocations, it's just so far outside of how the compiler is meant to work and so many cases can't be parsed or even handled at all when compiling that it's probably not feasible.
 
But it would be possible , if you use the GUI, to add a comment to the exported code that says:
Code:
/*
- IS2 uses pins QWRTY
- SGTL5000 uses pins ABCD, shareable with other I2S devices
- DAC uses pins QW
- ADC uses pins ...
*/
I think that would help a lot. In the GUI, we need a way to select the Teensy model anyway.. it is a bit confusing that it allows to add several devices without knowing the Teensy model.
A select box in the header, maybe.
Another thing is, i guess there is a way to detect the minimum required number of Audioblocks. And if AudioMemory is there, or if it is missing completely. Both are common problems.
 
Short answer is "probably not".

There are so many technical issues. In the case of pins 18 & 19, where talking about I2C by the Wire library. On Teensy 4.0 there are no alternate pins, but other models do have alternates. So simply having an instance of Wire doesn't necessarily mean pins 18 & 19 are in use. With boards that support alternate pins, the setSCL() and setSDA() functions could cause Wire to use other pins, making 18 & 19 available. It's also possible to use those functions to dynamically reassign as your program runs (but doing so while Wire is working obviously causes communication errors).

Other Arduino functions to use the pin include pinMode, analogWrite and attachInterrupt. Those could be in different files or even embedded inside libraries. It's also possible to use direct register access or pointers to registers to manipulate pins, and many libraries do indeed use that more complicated approach because it runs faster on many boards.

Even if the compiler could somehow parse and recognize which pins are used by all those sorts of code, there is also the possibility of code using actual variables for the pins (where the value of the variable can't be known until the program runs), rather than constants that are known to the compiler as it generates code.

So even if you tried to do something really exotic with the linker script, like a dummy memory section of size 1 for each pin, and maybe some really creative use of macros or templates to convert function arguments into dummy allocations, it's just so far outside of how the compiler is meant to work and so many cases can't be parsed or even handled at all when compiling that it's probably not feasible.

Thank you for your considered response Paul. I can see the issue with wire/I2c pins being a bit more complex than just handing off a warning.

Could a "softwarning" for the other reserved audio pins work, based on detection of SGTL in code and a quick search through pins for "7, 8, 20, 21, 23". The combination of selecting a selecting a board implies a certain audio shield and connections, if SGTL is detected + if any of these pins are detected for use, then compilation bails.

Is this an overly complicated task for an idea that wouldn't benefit that many people? Is it hard to detect what's happening specifically inside the .ino? As all of the linked files are concatenated, to a single text the compiler "sees", is it harder to disambiguate parts of the program than I imagine?
 
But it would be possible , if you use the GUI, to add a comment to the exported code that says:
Code:
/*
- IS2 uses pins QWRTY
- SGTL5000 uses pins ABCD, shareable with other I2S devices
- DAC uses pins QW
- ADC uses pins ...
*/
I think that would help a lot. In the GUI, we need a way to select the Teensy model anyway.. it is a bit confusing that it allows to add several devices without knowing the Teensy model.
A select box in the header, maybe.
Another thing is, i guess there is a way to detect the minimum required number of Audioblocks. And if AudioMemory is there, or if it is missing completely. Both are common problems.

that is a very elegant solution, even if just tool tips/hint/reminder is extremely beneficial. I've been caught out assuming equivalence with 3's and 4's, and audio sheilds, a little warnings in exported audio code would be bad ass, or even option to include hints when exporting audio code
 
I added some red dots on my Teensy4 pinout card for each pin used by the Audio shield. The ones that might catch you
out are pins 6 and 10 (which have 10k pullups even if not using the SDcard or extra flash), and more importantly pin 15
which has a big capacitor to ground on it making it unusuable digitally - that should not be necessary really, and should
perhaps have a cuttable trace, as taking a perfectly good pin out of action isn't great.
 
I added some red dots on my Teensy4 pinout card for each pin used by the Audio shield. The ones that might catch you
out are pins 6 and 10 (which have 10k pullups even if not using the SDcard or extra flash), and more importantly pin 15
which has a big capacitor to ground on it making it unusuable digitally - that should not be necessary really, and should
perhaps have a cuttable trace, as taking a perfectly good pin out of action isn't great.

ahh thanks for the heads up about 6 and 10, currently using pin 6 connecting to 470ohm resistor and led, will that cause any issue with proper functioning? An extra 10k resistor, would that just mean the led is less bright when setting to high?

And dammit I've got 15 connected to my DCO ramp, and that's the thing generating my square wave, but I've been having issues debugging where this (odd)harmonic is coming from. Damn, damn, damn, this might be the culprit, I might make a new thread for debugging this whistle-y noise from the osc, seems like processor noise, but actually come to think of it, wouldn't the cap help in this situation, as it'd be filtering to a certain extent? Apologies for consciousness
 
The 10k pullup is usually not an issue for standard logic signals, or if used as an output, but sometimes might
cause issues when bussed to some chip with internal 100k pull-downs or something like that.
 
Status
Not open for further replies.
Back
Top