New / updated HAL breaks RADDS SDcard

driv3l

I am running the latest repetier firmware (0.92) and have been trying to get the SDCard working on my RADDS board. Someone with a working SDCard running Repetier 0.91 sent me their firmware and I managed to trace the problem to something that has changed in HAL.

I used the configurator tool to generate a fresh 0.91 firmware, and that was also broken. I visually compared the 2 HALS between the working version and the broken versions, and it seems like it might be related to the eeprom changes that were introduced (where it is copied to RAM for faster access).

The working version that was sent to me looks like it was generated before the copy to RAM eeprom changes were introduced.

I don't think the problem is specificaly related to the copy to ram changed since I tested this by disabling eeprom and I still get the SD Card errors. I think the problem was introduced at the same time as the eeprom copy to ram changes.

Btw.. the actual error I get running the broken HAL is "SD init failed" when I insert an SD card. With the older version of 0.91, the SD card detection works without a problem and the files are displayed (on the LCD as well as in Repetier host).

On a slightly different note... on 0.92, I always seem to get errors when I connect to the printer. The errors are:

16:57:03.915 : Error:expected line 4 got 7

16:57:03.915 : Resend:4

16:57:11.942 : Error:Wrong checksum

16:57:11.942 : Resend:7

16:57:11.989 : SD card inserted

16:57:13.941 : SD init fail

16:57:13.941 : Begin file list

16:57:13.957 : End file list

16:57:15.957 : Error:expected line 8 got 15

16:57:15.957 : Resend:8

Thanks.

driv3l

I managed to trace the problem to 2 locations. I first discovered that you had changed the following function in HAL.h:

static inline void delayMicroseconds(unsigned int delayUs);

{

     microsecondsWait(delayUs);

}

This had changed from an earlier version of 0.91 (where the SD card works perfectly) to a newer function which uses inline assembler. It seems the newer function is probably faster and is affecting the overall timing of the system (loops / waits / inits probably run faster than they should).

If I replace the newer delay function (which has assembler) with the older delay function, then the latest version of 0.91 works fine with the SD Card.

I decided to dig further and leave the newer delay function in place and found that I can resolve the SD init issue in SDFat.cpp in the function bool Sd2Card::init(uint8_t sckRateID, uint8_t chipSelectPin).

In Repetier 0.91 (the latest code), I can get the SD card to init by changing the loop:

  // must supply min of 74 clock cycles with CS high.

  for (uint8_t i = 0; i < 10; i++) spiSend(0XFF);

If I change this loop to be 20 iterations, then the SD init seems to work. However, I did run into a problem when it was printing from SD card where it complained it couldn't read from the card about 1/4 of the way into the print. I am not sure if that was related to this overall timing problem, or there was an actual issue reading from the card.

However, the same SDFat fix does *not* work for 0.92.

It does seem like there some overall timing init issue related to the HAL and SD stuff. 

Another problem that surfaces in 0.92 with the SD init is that if you have an SD card in the RADDS slot, the LCD rotary slows down to a crawl and mostly does not respond since it's constantly trying to init the SD card (which is always failing).

The system should probably have a global SD fail after N tries until a new SD card is inserted. This will prevent the SD init loop from killing the UI / response.

It may be that the newer delay function is actually too fast and is preventing proper initialization of the SPI or something else.

Hopefully someone else with more knowledge of this stuff can figure out what the exact issue is since I don't know this stuff well enough to resolve the issue myself.

Repetier

First, you should know that the new delay method is essential. The old one could deadlock every few hours stopping your print with heaters leving on, so do not use it! The change revealed, that the new delay has less overhead and as a result it is a bit faster. I have changed several delays for lcd to fix that problem.

The lcd slowdown is as you already detected the init loop repeting with no success.

If you have the RADDS display, only the sd reader on the display will work since the chip select is different, just in case.

Despite this I'm using sd card over radds display all the time with big success. So if everything else matches, I think it is in deed a timing issue with your (and similar) cards and I have luck to have a sd card that works with current timing. I will test with all my sd cards if one of them gets the same problem with 0.92.

driv3l

Are you using the SD slot on the RADDS board itself, or the SD slot on the LCD display?

The problem I am having is with the slot on the RADDS board. I did not hook up the SD Slot on the LCD yet (waiting for more cables / molex plugs). Also, I don't have the RADDS specific LCD. I modified the RepRap LCD to plug into the RADDS board.

Repetier

At the beginning I had a display without sd card I used the one on radds, now the one lcd. The RADDS LCD controller changes the chip select to use the one on display now (not sure when I added it, so maybe 0.91 does not do this). That change is not in ui.h with the pin settingSo maybe if you use the same feature controller this is your problem in combination with you extended delay you described.

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

driv3l

on 0.91, this is set correctly in pins.h i.e. SDSS is 4 which sets the SPI_PIN to 87 and the SPI_CHAN to 1. This is why it works in 0.91 when I fix the init delay.

On 0.92, the SDSS value in pins.h is 53 which seems to set it to use a SW SPI. Is this correct? Do you know why it would be setting a SW SPI?

I can change that to 4, which should then set the SPI_PIN and SPI_CHAN to 87 and 1.

driv3l

Sorry... was looking at the wrong motherboard. SDSS was already 4 in pins.h, but was being overridden by ui.h.

I commented out the settings in ui.h and changed the delay loop in SDFat.cpp and now the SD Card is initializing properly.

I will do a test print tomorrow to check if there are any other issues.

It looks like just changing the init loop in SDFat to be 20 iterations instead of 10 might fix the problem.

driv3l

Btw, This was on 0.92

Repetier

Ok, I updated loop to 20 for next update.

The rest was just that you used the ui.h spi settings instead, if I understood you right.