На кои крачета си извел SPI шината ? Какви им са другите периферни функции, да не би те да те бъркат ? Въпреки че като периферия са неактивни хардуерно си остават свързани. SPI шина на dsPIC/PIC24 никога не ми е забивала, а шумове колкото искаш наоколо.

Не виждам нещо особено с пиновете. Използвам 13, 14, 15, 22. Изключил съм изрично аналоговите входове, ADC, компаратор, Vref, PMP.
Линукса бичи толкова здраво 24часа/7дни по SPI порта и чете от него и нищо му няма - тоест доказано железен е. А този PIC24FJ64GA002 в SPI SLAVE режим се забива. Вече много трудно мога да го забия с обичайните електроуреди наоколо. Днес тествах с една BOSH бормашина с четков мотор - не забива изобщо. Но го убивам гарантирано с нещо доста изненадващо - поялник WELLER с основа PU81 Вътре има един голям траф и останалото е доста компактна електроника, нищо не прави видимо впечатление да е кофти като изработка или компоненти.
Надолу се вижда CLK сигнала добре семплиран, после малко по сбито и накрая е целия пакет накуп + момента в който изключвам WELLER-а. Това е действието с което забивам SPI SLAVE модула на пика. Примерно от 3 опита 1-ин е успешен средно.
Този WELLER чат пат успява да шашне и PICkit3 който си мисли, че съм му дал пауза при дебъгване. Но за сериозните тестове програматора е изключен от платката, само Линукса и моята платка са галванично свързани. Мисля, че нещата са доста зле като цяло щом повтаряемостта е 90%. Ще тесвам UART-а да видим там какво ще има, но тия смущения са доста мощни така или иначе.

2 часа четене на чаршафи с данни обикновено спестява около 2 седмици копане ...
Погледнал ли си, че точно този професор има errata на SPI и най-вероятно касае твоят случай ??


Отделно не бих използвал SDA/SCL да ремапвам на тях SPI, освен ако нямам друг избор.
Някъде по документите им бях чел, че SDA/SCL имат специфична структура, затова не
се ремапват на други крачета. От което съм си направил бележка да не ремапвам върху
тях, въпреки че върху тях може и да си работи. Не знам, така бих направил

Мерси за инфото. Бях го забравил, но ще тествам това предложение. Пренебрегвах го понеже четох из форумите за него и ситуацията е малко по-различна от моята, но току виж се окаже решение. В конкретния случай мисля, че се получаваше байт въпреки, че SS сигнала не позволява да се получи и го заобикалят така. А при мен спира да получава - ако се окаже реален бъг, то той е недокументиран. Свалил съм ератите на всички процесори които обмислям като алтернативи и работата също е зле. Следващия който съм "харесал" е още зелен и има само първа хардуерна ревизия, а настоящия мисля имаше 4 ревизии, така че е доста по-шлайфан уж.

А според мен, като изключим случая от errata-та, проблема ти съвсем не е в SPI-то. Има нещо хардуерно, дето не е както трябва, или просто си попаднал на куца бройка MCU, макар че последното ме съмнява да е случая.

Сетих се, че не завърших тази тема след като прочетох друга подобна: Справяне със смущения по SPI
В моя случай след като борбата със SPI се оказа твърде неравна минах на USB конвертор. От към PIC24 е UART-FTDI-USB към линукса. Но се оказа, че USB драйвера не е най-стабилното нещо.

Като крайна мярка се премина на директна връзка между UART-вете на двете платки и нещата са от стабилни по-стабилни.

Косвен извод - производителите най-много се стараят да работи UART-а, за другите интерфейси се правят компромиси. Не казвам всички производители разбира се.

Ако USB HID ти върши работа като скорост, взимаш кой да е PIC-льо и го подкарваш така. Драйвери не трябват и поне от опитите ми с 3-4 екземпляра от различни семейста на PIC, работи абсолютно безгрижно и идиотоустойчиво. С CAN-а опита ми е същия - абсолютно безпроблемна работа, даже върху разни инверторни платки и прочие.