EFSL стабильна?, Файловая система на Mega32 подвисает Опции

[freux]

Адаптировал EFSL версии 0.3.4 на ATMega32L на STK-500 под SD. Отладочные строки убрал во flash, все файловые переменные - глобальные, размер стека - 0х180, потребление памяти 1 879 bytes of DATA memory, размер кода несущественен - во flash укладывается.
Examplы - копирование файла, вывод содержимого файла в UART проходят без проблем. Усложнил main - добавил командный процессор - и стал выводить содержимое файлов один за другим. И тут возникли зависания. Отладчика нет. Обложил печатью, и выяснил, что зависания происходят в функции посылки команды - sd_Command. Посмотрел исходники FlashFile v2.10 от Progressive Resources LLC, подправил sd_Command() и sd_readSector() на манер, как это сделано у prllc.
Результат тот же, - несколько раз файл считывается и выводится, затем, при чтении сектора того же файла зависает в sd_Command(). На печать вывожу так же #сектора при вызове sd_readSector() - сектора все те же, что и читались успешно.
Очевидно зависание в while(!(SPSR & (1<<SPIF)));
У Трамперта в "AVR-RISC микроконтроллерах" сказано, что в режиме "мастер" текущая передача может быть прервана подачей 1 в линию SS. Счетчик разрядов и внутрення логика Slave сбрасываются.
Оператор while(!(SPSR & (1<<SPIF))) в sd_Command() я добавил флагом, который взводится таймером через некоторое время после посылки команды так, чтобы исключить зависания. Если флаг взведен, поднимаю линию SS. Однако SD попав в это состояние больше не воспринимает команды - зависание исключено, но и секторы карты больше не читаются.
Теперь подумываю о прерывании питания на карту и ее повторной инициализации в случае продолжительного ожидания в SPI.
F osc = 3.68, F spi пробовал /2, /4 и /8 - безразлично.
Никто не испытывал подобных проблем?
Что посоветуете?

[defunct]

размер стека - 0х180, потребление памяти 1 879 bytes of DATA memory, размер кода несущественен - во flash укладывается.

Чем собираете? Если IAR'ом - отдайте под стек все что есть (так как сейчас - у Вас даже на буфер одного сектора нехватает).
Если WinAVR'ом, тогда как посчитали объем стека?

Теперь подумываю о прерывании питания на карту и ее повторной инициализации в случае продолжительного ожидания в SPI.
F osc = 3.68, F spi пробовал /2, /4 и /8 - безразлично.

Для FS столь низкая тактовая? Может проц захлебывается данными от SD и обработкой UART'a?...
Если нет подходящего кварца, на внутреннем осцилляторе с OSCCAL = 0xFF получите частоту близкую к 13Mhz.

Никто не испытывал подобных проблем?

Всяко бывало. Причиной всему чаще всего - ошибка в программе.

Что посоветуете?

Первое - рассчитать или промониторить количество свободных MIPS'ов проца.
И приведите код функций с этой строчкой:

Очевидно зависание в while(!(SPSR & (1<<SPIF)));

[freux]

Чем собираете? Если IAR'ом - отдайте под стек все что есть (так как сейчас - у Вас даже на буфер одного сектора нехватает).
Если WinAVR'ом, тогда как посчитали объем стека?

Собираю в IAR 3.20. Как уже говорил, все ёмкие файловые переменные EFSL_Filesystem, File, EFSL_Storage, в том числе содержащий кэш сектора да и другие, как -то буфер, куда читается содержимое сектора поместил в глобальные переменные. В листинге глубина main CSTACK=16, понятно, что полную глубину надо просуммировать, на вскидку получится не более 200. Да я и пробовал варианты, когда эти переменные были в стеке, естественно стек был почти максимальным.

Для FS столь низкая тактовая? Может проц захлебывается данными от SD и обработкой UART'a?...
Если нет подходящего кварца, на внутреннем осцилляторе с OSCCAL = 0xFF получите частоту близкую к 13Mhz.

Чтоб не ставить конверторы уровня для SD, я взял L разновидность с Fosc max =8MHz, а STK500 больше 3.68 МГц разгонять не рекомендуют, якобы разводка ПП слишком универсальна - может быть не стабильна. UART много не нагружаю, - вместо отладочных строк вывожу байтовый код, что-то вроде: SendTraceByteToUART(0x34);

Всяко бывало. Причиной всему чаще всего - ошибка в программе.

Гм.., но питание SD не прерываете? т.е. как я понял, прервать питание на карте и затем снова ее инициализировать - это единственный способ сброса SD карты? В Отличие от DataFlash памяти, где есть Reset?

Первое - рассчитать или промониторить количество свободных MIPS'ов проца.
И приведите код функций с этой строчкой:

Стало быть, одной из возможных причин может быть слишком малая скорость взаимодействия с карточкой? Target устройством будет Mega64, пока не отладил все составные части программы не хотелось бы приступать к разводке платы. Из оставшихся модулей это файловая система и алгоритм upgrade, естественно тоже с карточки. Не считаете ли Вы, перенос на Mega64, подъем до 8 МГц может решить проблему?

CODE

euint8 atmega_spi_send(atmegaSpiInterface *iface, euint8 data)
{
euint8 incoming=0;

// PORTB &= ~(iface->pinSelect);

SPDR = data;
while(!(SPSR & (1<<SPIF)))
incoming = SPDR;

// PORTB |= iface->pinSelect;

return(incoming);
}

Пробовал условие цикла заменить на while((!(SPSR & (1<<SPIF))) && (!flagSPIInt))
flagSPIInt взводится в прерывании (пробовал разные продолжительности: CK/256 -> 17.6 mS)
Далее в функции чтения сектора, что-то вроде

CODE

for(uLoop=0; uLoop<4; uLoop++)
{
sd_clear_buff(ssp);
if (sd_Command(ssp,CMDREAD, (euint16) (place >> 16), (euint16) place) != 0)
{
ssp->spi_CS_OFF(ssp->spiHwInterface);
SendTraceByteToUART(0x2F);
continue;
}
SendTraceByteToUART(0x31);

cardresp=sd_Resp8b(ssp); /* Card response */
if (flagSPIInt)
{
ssp->spi_CS_OFF(ssp->spiHwInterface);
SendTraceByteToUART(0x2F);
continue;
}

sd_clear_buff() выглядит следующим образом

CODE

void sd_clear_buff(SdSpiProtocol *ssp)
{
sd_resetSPITimer();
ssp->spi_CS_OFF(ssp->spiHwInterface);
ssp->spiSendByte(ssp->spiHwInterface,0xff);
ssp->spiSendByte(ssp->spiHwInterface,0xff);
}

Это позаимствовал у FlashFile от prllc

Чтоб небыло проблем с SS настройте ее на вывод или включите pullup обязательно.

Про pullup хорошая идея, внутренний сгодится?

Таймеры и т.д. это уже извращения ИМХО.

Когда есть конструкции вида: while(!(SPSR & (1<<SPIF)))
есть вероятность повиснуть там навсегда, и, тогда либо неуправляемый сброс от сторожевой собаки, либо своя управляемая обработка.
Ну это как если бы вынул сидюк из CDROM во время чтения, а Windows завис и потребовалась перезагрузка!

Про pullup хорошая идея, внутренний сгодится?

Ерунду сморозил: SS линия настроена на выход, внутреннего pullupа быть не может:

CODE

...
/* Set as master, clock and chip select output */
DDR_SPI = (1<<DD_MOSI) | (1<<DD_SCK) | 1;
...

PB0 - SlaveSelect

Сообщение отредактировал freux - Feb 17 2009, 10:27