HELP 'SD init fail' Repetier 0.92.9

mils24

Hello guys, 

I have been wrecking my brain all night over this and cannot get my printer to work. I have just yesterday updated my firmware from a very old version (2014) to the latest 0.92.9. My main reason for doing that was that I needed to configure a new thermistor type for my E3D V6 clone as my old firmware did not have the NTC 3950 100K option.

To populate the 0.92.9 version I used the online configuration tool and dropped in my old firmware configuration.h file. I only changed my thermistor from 3 to 14 and downloaded.

I have flashed my board and re calibrated. I was just about to hit print when I have now run into the 'SD init failed' error and my SD is displaying blank on the LCD controller.

Board is a Arduio Due with RADDS shield. Also using the RADDS LCD controller 40x20. SD Card is the same SD Card I have been using for years on that machine - 8GB SDHC, Formatted to FAT32. Also there are no other SD cards or Micro SD card plugged in to any of the other ports.

I have also tried re formatting the card tonight too but that did not make a difference.

I have googled this issue a lot tonight and there seems to be quite a few people with the same problem but I am yet to see a solution.

Please help!!

Thanks

Repetier

If you flash the old version does it still fail? I ask because you might have moved cables so communication fails, but since it worked with old this would be a simple test to rule out hardware changes - and since sd card can be very sensible even moving a cable might be enough.

With RADDS LCD activated you need to use the lcd sd card which is the active one then. Do not add on ein the RADDS board directly.

Also is the error just once or does it repeat slowing down everything?

mils24

I have just refreshed the old firmware from 2014 and it worked fine. No SD card errors. 

I then re flashed my new 0.92.9 firmware and the SD init fail error is still there.

I am only using the SD card slot on the LCD screen. Not the one on the board itself.

Also the error only shows up once in Repetier host, it does not echo.

Repetier

Ok, then lets assume spi speed is the cause as default is full speed which is pretty fast since it is a due. Go to SDCard.cpp and search initsd. There are 2 lines that init speed. Possible values are

uint8_t const SPI_FULL_SPEED = 0;

/** Set SCK rate to F_CPU/3 for Due */

uint8_t const SPI_DIV3_SPEED = 1;

/** Set SCK rate to F_CPU/4. See Sd2Card::setSckRate(). */

uint8_t const SPI_HALF_SPEED = 2;

/** Set SCK rate to F_CPU/6 for Due */

uint8_t const SPI_DIV6_SPEED = 3;

/** Set SCK rate to F_CPU/8. See Sd2Card::setSckRate(). */

uint8_t const SPI_QUARTER_SPEED = 4;

/** Set SCK rate to F_CPU/16. See Sd2Card::setSckRate(). */

uint8_t const SPI_EIGHTH_SPEED = 6;

/** Set SCK rate to F_CPU/32. See Sd2Card::setSckRate(). */

uint8_t const SPI_SIXTEENTH_SPEED = 8;

/** MAX rate test - see spiInit for a given chip for details */

So maybe just start with 1/16th and see if it works. If it does you can check how fast you can go or compare with your old version what speed was used there.

mils24

I can't see the string of code you are talking about above. 

Please see my old and new initsd code from SDCard.cpp below:

- OLD firmware that works -

void SDCard::initsd()

{

    sdactive = false;

#if SDSS >- 1

#if SDCARDDETECT>-1

    if(READ(SDCARDDETECT) != SDCARDDETECTINVERTED)

        return;

#endif

    /*if(dir[0].isOpen())

        dir[0].close();*/

    if(!fat.begin(SDSS, SPI_FULL_SPEED))

    {

        Com::printFLN(Com::tSDInitFail);

        return;

    }

    sdactive = true;

    Printer::setMenuMode(MENU_MODE_SD_MOUNTED, true);

    fat.chdir();

    if(selectFile("init.g", true))

    {

        startPrint();

    }

#endif

}


- New 0.92.9 Firmware that doesn't work -

void SDCard::initsd()

{

    sdactive = false;

#if SDSS > -1

#if SDCARDDETECT > -1

    if(READ(SDCARDDETECT) != SDCARDDETECTINVERTED)

        return;

#endif

HAL::pingWatchdog();

HAL::delayMilliseconds(50); // wait for stabilization of contacts, bootup ...

    fat.begin(SDSS, SPI_FULL_SPEED);  // dummy init of SD_CARD

    HAL::delayMilliseconds(50);       // wait for init end

HAL::pingWatchdog();

    /*if(dir[0].isOpen())

        dir[0].close();*/

    if(!fat.begin(SDSS, SPI_FULL_SPEED))

    {

        Com::printFLN(Com::tSDInitFail);

sdmode = 100; // prevent automount loop!

        return;

    }

    sdactive = true;

    Printer::setMenuMode(MENU_MODE_SD_MOUNTED, true);

HAL::pingWatchdog();

    fat.chdir();

    if(selectFile("init.g", true))

    {

        startPrint();

    }

#endif

}

RAyWB

Repetier mentioned this part :

    fat.begin(SDSS, SPI_FULL_SPEED);  // dummy init of SD_CARD

    HAL::delayMilliseconds(50);       // wait for init end

HAL::pingWatchdog();

    /*if(dir[0].isOpen())

        dir[0].close();*/

    if(!fat.begin(SDSS, SPI_FULL_SPEED))


change it to :

  fat.begin(SDSS, SPI_SIXTEENTH_SPEED);  // dummy init of SD_CARD

    HAL::delayMilliseconds(50);       // wait for init end

HAL::pingWatchdog();

    /*if(dir[0].isOpen())

        dir[0].close();*/

    if(!fat.begin(SDSS, SPI_SIXTEENTH_SPEED))


for beginning , if that works change to SPI_EIGHTH_SPEED and so on

mils24

I have made the changes as described to (SDSS, SPI_SIXTEENTH_SPEED) and Im still getting the 'SD init fail' error.

RAyWB

so may be increasing the delay time helps, i would try 150 instead of 50 in both cases

mils24

Ive set both to 150 and re uploaded without no success.

code looked like the following:

HAL::pingWatchdog();

HAL::delayMilliseconds(150); // wait for stabilization of contacts, bootup ...

    fat.begin(SDSS, SPI_SIXTEENTH_SPEED);  // dummy init of SD_CARD

    HAL::delayMilliseconds(150);       // wait for init end

HAL::pingWatchdog();

    /*if(dir[0].isOpen())

        dir[0].close();*/

    if(!fat.begin(SDSS, SPI_SIXTEENTH_SPEED))


On a side note my 'back' option on the menu has been removed. I have changed #define UI_HAS_BACK_KEY from 1 to 0 and uploaded but it has not brought the 'back' option back.
Is there maybe something I am not doing correctly or something preventing the upload being done correctly. Surly changing this to '0' should of brought back my 'back' button or is it override by another code? 

If my flashing is not happening correctly then regardless what I try here for the SD init fair problem it will never work.

mils24

Ok so I changed the name that appears on my LCD and refreshed and it did work. So my compiling and flashing is working ok. 

Therefore my SD init fail and missing 'back' button problems are still unsolved!

mils24

Ok, So the 'Back' Issue is now solved and my compiling and flashing is definitely working!

So back to the 'SD init fail' it is still a mystery and not working. It may also be worth noting that on my old firmware that as soon as inserted the SD card it automatically took you to the SD card menu of file. On this firmware it does nothing.

Anything else I can try?

Repetier

Due is critical with spi - you should only use one spi device at the moment with hardware spi. Do you have anything else spi related configured - thermistor maybe? 

Also if you try later to mount sd does it also fail (to rule out timing at the beginning).

mils24

What do you mean by 'spi'. Sorry my knowledge of coding is not great. Im learning as I go.

I did have to move to the 0.92.9 firmware to suit my new hotend thermistor. Its type 14.

Also how do you mean mount the SD?

mils24

Can someone please point me to instruction on how to mount the SD card as Repetier mentioned above? I will test this later tonight or tomorrow.

Or if anyone else's has anything else I can try??

MartinH

In repetier host, far right side click 'sdcard', then click the 'mount sd' icon (down arrow)

mils24

Thanks MatrinH,


Ive tried mounting it and on Repetier Host it says 

< 17:16:42: SD init fail

< 17:16:42: Begin file list

< 17:16:42: End file list

Ive tried it several time and each time I get the same response.

One of the times when I pressed the 'mount' button it triggered the Watchdog Reset and reset the printer.

mils24

Repetier said:

Due is critical with spi - you should only use one spi device at the moment with hardware spi. Do you have anything else spi related configured - thermistor maybe? 

Can anyone please explain what Repetier meant by the above? How do I check if 'anything else SPI configured'?

Thanks 

mils24

Hello guys,

I have read post after post about this issue and no one can seem to get to the bottom of it. I really want to get this working again as I do not want to have to leave my laptop plugged into my printer while its printing.

Repetier seems to think its a timing issue, does anyone know to fix it?

Repetier

Timing was just a guess. Problem is no one really understands how file systems work and we are just happy the file library normally works. That make sit hard to analyse why it now says it doe snot work even if initialized with same parameter. Simple cases are wrong slave select pin, not detected cd detect. But I have that display/board combination myself and it is working with my sd card (cheap 4gb) so the default config for the display is correct and working.

That is also why I said that other spi devices might interfere if you have any. board has none, so only if you added something or configured something not connected.

What you could try is start new config in tool and only select board and display, nothing else. This is just to test if you have added something causing the problem.

mils24

Hello Repetier.

Thanks for the reply. I have done what you have said tonight with the online configuration tool. I created a new one with just the control board and the LCD display configured. I left everything else standard. I compiled and flashed my board and still I am getting the 'SD init fail' error. Therefore I don't think there are any more SPI devices interfering (whatever they are).

What I do notice is that when I put my SD card into the printer and it says 'SD Card inserted' if I press the knob button it will not go into the menu for a few seconds. Its almost like its froze. I assume this is while the board tries to read/initialise the SD card. This never happened on my old firmware and intact if I put my SD card in it would automatically jump into the SD Card menu.

Don't know if this is relevant or not but I thought I would share as it make me think there is a speed/timing issue. 

Does anyone have anything else to try?

Thanks

Repetier

You are right, no other spi is now configured which was why I suggested it and it should have worked like it did for me. Not sure what the difference is. Apparently there must be one.

mils24

- SOLUTION -

I finally got it working!!!!! 

Currently running a 3 hour test print to ensure it does not drop out in the middle of a print but so far all is looking good!

So the solution:

After my last test of creating a brand new configuration with just the RADDS board and RepRap 40x20 LCD set as options and it still not working I knew it had to be something different within the 0.92.9 code vs my old 2014 firmware. As Repetier says above it couldn't be SPI conflict from something I configured wrong so I opened the two side by side in TextEdit (notepad) and started to read through them looking for differences. This was very difficult as I am not good at reading code!

I remember reading another forum post about the same thing ( https://forum.repetier.com/discussion/199/new-updated-hal-breaks-radds-sdcard ) in that post Repetier says the following about the pin allocation for the SD card reader:

// pins.h for on board sd card:
#define SDSS    4// 4,10,52 if using HW SPI.

// these are set at bottom based on SDSS

#define SPI_PIN         87

#define SPI_CHAN        1

// Setting in ui.h for RADDS display

#define SDSS            10

#define SPI_PIN         77

#define SPI_CHAN        0

so I started looking at pins.h of the two firmware files.

Both the Pins.h for the 2014 firmware and the 0.92.9 firmware matched: #define SDSS   4

I then looked at the ui.h files as 'driv3l' from the other post said he had issues with it conflicting.

When I looked at the ui.h there were quite a few differences. Firstly there is a lot more information in the 0.92.9 version of ui.h compared to the 2014 firmware. (not surprising due to the timescale).

In my 2014 version I had the following:

#if FEATURE_CONTROLLER == CONTROLLER_RADDS

//#define SDSS            10

//#define SPI_PIN         77

//#define SPI_CHAN        0

In my 0.92.9 version I had the following:

#endif // Controller 6

#if FEATURE_CONTROLLER == CONTROLLER_RADDS

#undef SDSS

#define SDSS            10

#undef SPI_PIN

#define SPI_PIN         77

#undef SPI_CHAN

#define SPI_CHAN        0

I noticed that in 2014 version all of these had been commented out so first I tried that on 0.92.9. Once I pressed compile I got a compiling error. It said missing values for SPI_PIN and SPI_CHAN. I then thought that this must mean in my 2014 firmware the ui.h is not overriding the pins.h values as they are commented out.
I then thought why is my pins.h file saying #define SDSS   4   but my ui.h file saying #define SDSS   10. I understood from the post above that to get the SD to read from the LCD that I needed:

#define SDSS            10

#define SPI_PIN         77

#define SPI_CHAN        0
so my SPI_PIN and SPI_CHAN values were fine but my SDSS value was wrong. Therefore I tried changing my SDSS value to 4 and left the other two. This then meant that my SDSS values in pins.h and ui.h matched.

I saved the file, compiled and flashed -> BINGO!! IT WORKED!!

Maybe this is obvious and I should of picked up on it before now but as I said Im not too good with all this.

Hopefully this will help someone else that encounters the same issues as I had as it seems to be quite common to have the SD init fail error.

Thanks guys for all the help you gave me.

Repetier

So you need SDSS to be 4? I rechecked and saw that the sd card port has CS0 and CS1 pin which are 4 and 10 and I also checked that 10 is what I needed. So now I ask myself if they changed the pin after sending me the display or if you have a different display that is just compatible but uses 4 as slave select.

Strangely if you check what SS pin needs which channel

#if (SDSS == 4) || (SDSS == 10) || (SDSS == 52) || (SDSS == 77) 

#if (SDSS == 10)

#define SPI_PIN         77

#define SPI_CHAN        0

#else

#if (SDSS == 52) 

#define SPI_PIN         86

#define SPI_CHAN        2

#else // SDSS == 4

#if (SDSS == 4)

#define SPI_PIN         87

#define SPI_CHAN        1

#else //SDSS == 77

#define SPI_PIN         77

#define SPI_CHAN        0

  #endif

#endif

You see that 4 would be mapped to 87/1.

In any case good work finding out the reason.

mils24

Yea for some reason SDSS 4   SPI_PIN 77 and SPI_CHAN 0 works. 

I wonder what would happen if I changed SDSS to 10 in ui.h and also SDSS to 10 in pins.h? To me it seemed like the difference of having SDSS as 10 in ui.h and SDSS as 4 in pins.h was the problem. So maybe if both were 10 they would also work.

Now that I have it working I'm just going to leave it and not test my theory! lol Also my 3hr test worked fine, not communication or drop out issues ( just bed adhesion ones   )