този SPI CS, правилно ли го вдигаш/сваляш
погледни го на осцилскоп

Това беше първото за което се хванах и аз . Ама уви. И това не е . Нов проект направих в който имам само един дисплей и флаша. И ефекта продължава да е същият.
За това ако някой извади някоя библиотека която е тествана - да свирка. Имам студена бира

Хубаво де, ще ти дам библиотека, ама това не е голям проблем можеше сам да си го решиш, важното бе, да си конфигурираш правилно SPI на STM-ката. Сега, когато не пускаш никакъв код поставяш колегите в режим "врачка". От къде да знаем къде ти е проблема?

Бе аз да питам пак - вие осцилоскопи не ползвате ли? Туряш скопа, синхронизираш по чип селкта и виждаш всичко.

... Карай, лаф да става!

п.с. А бе важното е накрая бира да има, ама май само ще се надяваме...
Трябва да махнеш реда:
SPI_SSOutputCmd(SPI1,ENABLE);

Да не я държиш в HOLD тая памет?? Подаваш ли правилните команди?
Опитай първо да прочетеш STATUS и след това подай команда за четене или запис!
Ако искаш да четеш на висока скорост след трите байта с адреса пускаш един паразитен байт и след това четеш.

Ето ти тест, като основа за това, което ще надграждаш за STM32F103xx тествано и работещо!

ето кода:

void main(void)
{
InitializeSystem();
SPI_Configuration();
flasha=0;
while(1)
{
if (miga==1)
{
temp_flash=0;
temp_flash=Flash_ReadByte(flasha);
flasha++;
if (flasha==255) flasha=0;
miga=0;
}
}
}
съответно инициализацията на SPI и четенето на флаша са това:
void SPI_Configuration(void)
{
GPIO_InitTypeDef GPIO_InitStructure;
SPI_InitTypeDef SPI_InitStructure;

/* SPI1 Periph clock enable */
RCC_APB2PeriphClockCmd(RCC_APB2Periph_SPI1, ENABLE);

/* Configure SPI1 pins: SCK, MISO and MOSI */
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_5 | GPIO_Pin_6 | GPIO_Pin_7;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;
GPIO_Init(GPIOA, &GPIO_InitStructure);

/* Configure PE3 pin: CS pin */
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_4;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
GPIO_Init(GPIOA, &GPIO_InitStructure);

GPIO_SetBits(GPIOA, GPIO_Pin_4);

/* SPI1 Config */
SPI_InitStructure.SPI_Direction = SPI_Direction_2Lines_FullDuplex;
SPI_InitStructure.SPI_Mode = SPI_Mode_Master;
SPI_InitStructure.SPI_DataSize = SPI_DataSize_8b;
SPI_InitStructure.SPI_CPOL = SPI_CPOL_High;
SPI_InitStructure.SPI_CPHA = SPI_CPHA_1Edge;
SPI_InitStructure.SPI_NSS = SPI_NSS_Soft;
SPI_InitStructure.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_256;
SPI_InitStructure.SPI_FirstBit = SPI_FirstBit_MSB;
SPI_InitStructure.SPI_CRCPolynomial = 7;
SPI_Init(SPI1, &SPI_InitStructure);

/* SPI1 enable */
SPI_Cmd(SPI1, ENABLE);
}

u8 Flash_ReadByte(u32 Data)
{
u8 Receive_Data=0;
GPIO_ResetBits(GPIOA, GPIO_Pin_4);

while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE) == RESET);
SPI_I2S_SendData(SPI1, 0x03);
while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE) == RESET);
SPI_I2S_SendData(SPI1,(Data & 0xFFFFFF) >>16);
while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE) == RESET);
SPI_I2S_SendData(SPI1,(Data & 0xFFFF)>>8);
while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE) == RESET);
SPI_I2S_SendData(SPI1, Data & 0xFF);
// while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE) == RESET);
// SPI_I2S_SendData(SPI1, 0xFF);

while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE) == RESET);
Receive_Data = SPI_I2S_ReceiveData(SPI1);

GPIO_SetBits(GPIOA, GPIO_Pin_4);
return Receive_Data;
}

А в атача е клипче от осцилоскопа. Зеленият канал е чип селект, жълтият е клок, синият е предаването към флаша, а съответно лилавият е какво ми връща флашчето ( в случая -нищо)
Интересни са две неща които не мога да си обясня.
1. защо се вдига чип селекта някъде по средата преди да е предадено още всичко, като командата за вдигането е след последният предаден байт(младшия от адреса) и приемането на данните...
2 защо клока спира след като предаде последния байт от адреса който е за четене и не клопа още за получаване на данни...т.е. не трябва ли още 8 клока да има за Receive_Data = SPI_I2S_ReceiveData(SPI1);

Съжалявам ако не съм се изразил нещо правилно, но вижте клипчето и мисля, че ще ме разберете.

ПС. Благодаря на fan, за архива, но не намерих някаква разлика с моите писания. И не си чеша само устата за бирата Давай координати и я имаш. Тя е най-малкия проблем.

Умишлено съм махнал всичко останало и въртя само една команда за да направя клипчето да се виждат проблемите.

Виж сега, явно самочувствието ти си играе лоша шега с теб?!
Ами, ти прегледа ли кода на библиотеката поне, която ти дадох?
И защо не конфигурира пиновете на SPI така, както е по описание? Нищо, че в случая работи и така, но все пак е някакъв ред в кода съобразен с изискванията на фирмата производител.


Следващата ти стъпка, ако пак "не работи" ще е да си погледнеш свързването на пиновете.
Успех!

Само това е достатъчно, за да не работи нищо. Как очакваш паметта да захапе какво и подаваш, като и вдигнеш чипселекта по средата на поредицата? Затова ти казах, да хванеш скопа и да провериш какво си надробил.

Мога да ти кажа и какво си надробил.....макар, че ако вместо просто да караш по метода на пробата и грешката, беше седнал и помислил, щеше отдавна да си го хванал....

Първо за да предадеш данните ползваш флага TXE. Това е коректно, но само при еднопосочно предаване. Защо? Защото това е флаг за външния буфер на интерфейса, а той е двойно буфериран. Т.е. това значи, че външния буфер е празен, но вероятно през същото това време се предава предишния байт през SPI. Докато само предаваш всичко е коректно. Но в момента в, който решиш да четеш става гафа. Що? Ами щото след последната проверка на TXE, ти мяташ още един пакет данни за предаване. В този момент имаш един байт който в момента се предава и един дето чака ред във външния буфер. В следващия момент започваш да следиш флага RXNE - той трябва да се вдигне когато имаш приет байт (или поне това се очаква). Оставяме настрана факта, че никъде не си го изчистил преди това, т.е. той си е перманентно вдигнат и в момента в, който го пулваш, ще реагираш, ще изчетеш едни грешни данни от ресивера и ще излезнеш, като си вдигнеш чип-селекта. И това ще стане някъде още докато предаваш предпоследния байт (което и виждаш на скопа). Но даже и да го чистиш преди четене - пак ще излезнеш преди края, заради двойното буфериране - RXNE ще ти се вдигне и на предпоследния и ще реагираш на него, а не на последния както очакваш, защото процесора е много по - бърз от SPI интерфейса. Т.е. като пуснеш последния байт, ти текущо предаваш предпоследния. И проверката на RXNE ще ти даде положителен резултат още на предпоследния, ще излезнеш ще си вдигнеш чип селекта и ..... манджа с грозде.

Какво трябва да направиш - единия и по-лесния вариант е още от начало да си гониш само флага RXNE. Изчистваш го преди да почнеш, пускаш един байт в трансмитера и чакаш RXNE като знак за край на предаването. Той е знак, че ресивера е готов, но в твоя случай това значи, че и байта е предаден. И си работиш само с него, като всеки път си го почистваш (чрез четене на данните от SPI, независимо дали ти трябват или не). Това ти препоръчва колегата fan. Работи безотказно, но губиш двойното буфериране на трансмитера. Другия вариант е да предаваш със сигнал през TXNE както ти го правиш, но след последното да изчакаш докато всичко се предаде. Това ставa в комбинация TXE с BSY флага. Но е малко по - сложно и може да вкара в друг един проблем. Та според мен направи предаването както ти е препоръчал колегата fan. И СЕ УБЕДИ НА ЕКРАНА НА СКОПА, ЧЕ ЧИП-СЕЛЕКТА СЕ ДРАЙВИ КАТО ХОРАТА и се вдига като всичко приключи.

Всичко по горе отговаря и на втория ти въпрос - що няма поредицата клокове когато се опитваш да четеш. Може да имаш и други проблеми в кода, ама оправи първо това, пък после ще търсим другото.

П.С. Всъщност незнам дали си наясно, но функциите SendData и ReceiveData на SPI библиотеката не са блокиращи. Демек те не правят нищо друго освен да четат и пишат DR регистъра. Т.е. това, че си сложил нещо с SendData функцията, съвсем не значи, че като излезнеш от нея то е предадено. Просто данните са сложени в DR rрегистъра, всъщност в момента се предават или по-вероятно ще бъдат предадени в бъдеще време. Както и обратното, това че си прочел нещо с ReceiveData функцията не значи, че тя е изчакала байта да се приеме и след това ти го е върнала. Тя просто ти е върнала текущото съдържание на DR регистъра, а какво си подсигурил да има вътре си е лично твой проблем Всъщност в случая тези две функции са просто опаковка на простичкото SPI1->DR = x и x = SPI1->DR.

Както винаги колегата "Цецо" разяснява подробно и точно проблема!
Само това с двойното буфериране от къде му дойде не знам - предполагам от пиковете?!
Предлагам на "eddiesoft" да подкара комуникацията така, както съм му я дал, пък ако не го удовлетворева да търси други решения, а има и DMA на разположение...

Двойно буфериран му викам аз, щото така са ме учили в ТУ-то. Пък е ясно - имаш един шифт регистър в SPI-я и един допълнителен буфер. Като се замисля, не виждам нищо двойно в цялата работа, ама така съм научен така си приказвам Единично буфериран си е.

Както и да е - смисъла на цялата плеяда дето я изписах е - ако ползваш само TXE имаш буфериране (по-висока скорост при предаване), ама имаш ядове при приемане. Ако ползваш само RXNE нямаш синхронизационни ядове при приемане и предаване, ама губиш малко скорост. Микс от двете + бъзи флага дава най-добри резултати, ама там вече се иска, човек да прочете и да се позамисли по задълбочено...Пак добре, че не е пробвал с DMA + прекъсване, че представям си тогава какво щеше да се види на скопа

Аз точно тоя проблем (на 100% същия) на колегата съм го изпитал на гърба си. Затова и толкова лесно му видях къде бърка, само по осцилограмата. Ама аз го реших за 2 часа. Щото първо гледам осцилограмата. А не да пробвам различни парчета код, докато случайно вземе та тръгне. Не мога да го разбера аз тоя начин на девелопмент - абе нещо не става. Пиши, мажи - а стана. супер, забравяме за проблема. Ако случайно след 1000 опита с парчета код не стане, пробвам помощ от публиката. Ако и с техния код не стане, пускаме онова досадно нещо наречено осцилоскоп и установяваме, че то изначало комуникацията ни е сбъркана, та тръгваме да търсим проблема. И то добре, че му е толкова кардинално сбъркан проблема, та не може да го замаже, че иначе ще има след време при някое състезание на процеси веднъж на 1000 пъти да му гърми и да пита тука - абе що така.

И тук не коментираме въобще досадния "фитчър" на STM32, да не драйви сам CS пина. На кой ли пък му е притрябвало CS пина да се драйви автоматично?
Ако колегата беше взел куртекс на друг производител, вероятно нямаше да го види тоя проблем въобще, щото те повечето имат достатъчно акъл да си драйвят сами CS пина

Три дена опити спестяват половин час досадно четене!

Тряс, вие с дедо ми оправяте настроението.