SD undefined

G

GTiRHil

Member
Apologies. This probably comes from me mostly programming in Free Pascal ...

I keep on getting the following message when compiling my C code in Visual Studio 2022:

ld.exe: CIS030925.cpp.o: in function setup
CIS030925.ino:61: undefined reference to SDClass begin(unsigned char)
ld.exe: D:\CISRewrite030924\CIS030925\CIS030925.ino:65: undefined reference to SD

collect2.exe*: error: ld returned 1 exit status

**The error is generated at the line if (!SD.begin(BUILTIN_SDCARD))

I have tried copying the SD.h file in with my working files, I've tried pointing to it with the full path and I've tried pointing to it in the default location. I've tried putting it after all the other includes in case it was being supplanted. I've assumed that the type of BUILTIN_SD is correct.

Many thanks for telling me that I am an idiot and should stick with Pascal ... :)

Here is the main module:

Code: 
#include <Arduino.h>
#include <TimeLib.h> //for teensy
#include <Wire.h>
//#include "dispatchTimer.hpp"
//#include <SD.h>
#include <SPI.h>



#include <math.h>

#include "consts.hpp"
#include "globals.hpp"
#include "errors.hpp"
#include "macros.hpp"
#include "hutils.hpp"
#include "analogi2c.hpp"
#include "dispatchTimer.hpp"
#include "hsd_read.hpp"
#include "rpm.hpp"

#include "timing.hpp"
#include "fuelPump.hpp"
#include "readpins.hpp"
#include "pwm.hpp"
#include "pinInit.cpp"
#include "initialiseSystem.hpp"
//#include <C:\Users\hkems\AppData\Local\arduino15\packages\teensy\hardware\avr\1.59.0\libraries\SD\src\SD.h>
#include <SD.h>

void setup()
{
  setPins();

  initialiseErrors();

  // Open serial communications and wait for port to open:
  Serial.begin(115200);
  while (!Serial1) {
      ; // wait for serial port to connect.
  }

  if (!bitRead(USB1_PORTSC1, 7))
  {
      //usb connected
      ;
  }
  else
  {
      //usb disconnected
      setError (SERIALCONNECTIONFAIL);
  }

  setMyTime (now());

  //Initialise onboard SD

  if (!SD.begin(BUILTIN_SDCARD))
  {
      setError(SDFOUNDFAIL);

      return;
  }

 // initialiseSystem();
}

void loop()
{
 //This is the operating system
 dispatchTimer () ;  //

}
 
Is the build setting the appropriate teensy one of these to have BUILTIN_SD defined?

Code: 
#if defined(__MK64FX512__) || defined(__MK66FX1M0__) || defined(__IMXRT1062__)
#define BUILTIN_SDCARD 254
#endif
 
I tried entering 254 instead of the constant and got the same error.

Sorry for my slow reply - Christmas shoppingand an unexpected visitor.
 
The Arduino IDE automatically compiles all the extra code used in libraries based on files that the main sketch includes. I don't know how this is intended to work with VS2022, but it's obviously not compiling and linking the code from the SD library. Have you tried starting off with a simple "Hello World" program first?
 
I would try first

Code: 
#include <Arduino.h>
#include <SD.h>

void setup()
{
  while(millis()<10000) {if(Serial) break;}
 
  if (!SD.begin(BUILTIN_SDCARD))
  {
      Serial.println("failing SD.begin");
      return;
  }
}

void loop()
{
}

If this compiles and runs. then the issue is with one of the additional libraries that redefines class SD
 
Can you reproduce this problem if you compile your program with Arduino IDE?

EDIT: just to explain a bit further, this error message is from the linker which is pretty much the last step of compiling. Since no errors were found the earlier stages of compiling, it's pretty unlikely to be a problem in your code, especially when we can see you have a clear usage of the SD object. This type of error very likely means the software creating the compiler commands is omitting something. But before you contact Visual Micro or whoever publishes the plugin you're using to compile Teensy programs in Visual Studio, the very first question everyone will ask is whether the problem happens in Arduino IDE. If your program compiles correctly in Arduino IDE but gives this linker error in Visual Studio, that should persuade whoever wrote the Visual Studio plugin to investigate. But if the same error happens in Arduino IDE, then perhaps there is something wrong with your program? Or maybe you've discovered a bug in SD or other widely used libraries, which nobody has noticed until now? Either way, if the problem does happen in Arduino IDE, you'll need to show us a complete program to reproduce the problem. Nobody can be expected to diagnose such an elusive problem without the ability to compile the code to reproduce the issue. But please understand the very first step is to check whether the problem even happens with Arduino IDE. Obviously if the problem is only when using Visual Studio, then effort needs to focus on what the tools for Visual Studio are doing wrong.
 
Last edited:
Thanks folks for your input. As we approach Christmas I keep getting dragged away.

I'll try the code above in the Arduino IDI first.
 
OK, the code above compiled and linked to Teensy 4.1 and loaded to the board, in the Arduino IDE.

As I expected!

With regard to posting all the code, I hoped that I was just being a wee bit Pascal and that the answer was immediately apparent to the cognoscenti.

I'll have a look at the VS setup first in case something jumps out with a fresh look.
 
OK, the same code failed in VS2022. You can see that it didn't recognise BUILTIN_SDCARD.

I had trouble setting up the VS2022 for teensy and maybe it's come back to bite me.

1766126811547.png
 
This simply indicates that the VS2022 configuration does not point to Teensyduino but only to Arduino. (SD of Arduino does not know BUILTIN_SDCARD
 
If we assume that your include path in VS2022 is correct and you are actually including the correct SD.h, then the next thing to check would be what defines are present on the command line of the build. SD.h includes the following:

Code: 
#if defined(__MK64FX512__) || defined(__MK66FX1M0__) || defined(__IMXRT1062__)
#define BUILTIN_SDCARD 254
#endif

So, are any of those symbols defined?
 
OK, so I replaced my #include <SD.h> with
#include <C:\Users\hkems\AppData\Local\arduino15\packages\teensy\hardware\avr\1.59.0\libraries\SD\src\SD.h>

It recognised BUILTIN_SDCARD (it read the header) but still doesn't find the code:

Harold.ino:11: undefined reference to SDClass begin(unsigned char)

ld.exe: Harold.cpp.o: in function Print::println(char const*)
Print.h:114: undefined reference to SD

So, my path to the code is not working, even though the header is being recognised.
 
I'm still trying to find how to point it at the right library. The Arduino ide automatically grabs the Teensy 4.1 library. But even though I am using the same Arduino IDE (2) in VS, it's going to the wrong place, as we have seen...
 
One thing I noticed a couple of years ago, the link order may not be the same as the include order, which is not an issue with Arduino, but with VSCode/VS2022 environments.
original thread: https://forum.pjrc.com/index.php?threads/changing-include-order.44930/
I don't know if something in the last 8 years has changed.
Also, if I have link issues, I always delete the temporary directory where the .o are placed. I do not know where VS2022 places the .o and .a files, but a log file will show it.
 
Thanks. I saw something about the link order before but had forgotten. With the short program here, there don't seem to be many link order options.

I went through the log file from the compile and it seemed to be getting code from the right library, Teensy.

I'm going to try the Visual Micro forum as it seems to be more related to that side of the operation. But when I solve the problem, I'll post back here.
 
My guess is this may be a link location problem (linking the wrong SD library even after compiling the right one) rather than a link order problem (correct library but given in different order on the linker command line).

Any chance you could share a link to the conversation on that other forum? I'm curious to take a quick look.
 
GTiRHil said:
I sabotaged SD
Click to expand...
Having an alternate copy of the SD files when it properly works should never be needed, and will prove the solution.
it would be best to work through this without any efforts toward sabotage of the expected use.
Those alternate errors will point to the real root of the problem and will go away when the build is working.
 
Yup, I agree. Once I get the first include to find the correct SD.h, the rest should follow.

I wish that I understood where it WAS going to and why. I'll keep working on it. Christmas is coming and more free time!

Thanks.
 
You must log in or register to reply here.
Back
Top