spi slave weird data on mid-high speeds ?!

[arhi]

I am having weird issue with STM32F767 (configured to run at 200mhz) that needs to be SPI slave .. I configured it with 0,1 (clock low, second edge), hardware cs.. when master sends data at 350kbps everything is ok, when master sends at higher speeds output is random (like bits are swallowed).

code is super simple just hal_spi_transmitreceive() in a loop sending 2 same bytes non stop

it behaves like hardware can't catch up and start sending data late and slower than the clock...

[AScha.3]

so why not:

..in 3 days you have it. :)

+ in 5 weeks..

[arhi]

I don't get it ? 767 is in your image 17 weeks factory lead time (and those 17 weeks is there for months, they do not have them planned at all, they are just out of stock and no idea when will be available) ... where do you see 3 days? you trust that "expected" :D ... mouser have them on order for years and is expecting them "in few weeks", comet too, avnet too, farnell too... but if you go directly to ST they are not making them ... we had bunch of those but had to use them up during chip shortage ..

I am doing now development on some discovery board I do have (I have ton of them) but it is not 767 that will be in final product (that needs to be in final product for whatever reason client decided, but among other things availability at the company making pcb's and assembling everything) ... so I will be assembling code from different products when we fix the final board... but with shipping blocked as post office is in strike for months... that will take some time too..

and no, final board cannot be nucleo, dunno if you read the licence agreement for nucleo or discovery ... they are great for development, you can't use them in commercial products

[AScha.3]

>17 weeks factory lead time

yes, if you want order 500 pcs.

but -hey- i just want show you some boards, to use for your test. very similar...but not the target. right.

and those are in stock...so 3 days. (at least here in Germany, if i order from US /mouser .)

and nucleo-F767 - no stock. right now. but Jan/24 ->

but the F767 chip, in 144 lqfp, 1600 in stock -- how many you need in 3 days ??

so why not take one of your ton of nucleo boards to verify the spi working...

then order the 500 F767 or whatever you need , next week you can deliver some boards.

maybe from jlcpcb.com  with 24 hour service for double sided prototype...

+

yes, i know about the problem, to get the chip you need from STM - i fighting since years with this problem, as most of us here :)

[arhi]

> yes, if you want order 500 pcs

we already have some 20pcs on backorder in digikey, mouser and farnell :D so if ST decides to make them and digikey / mouser / farnell gets them on stock we'll have them in germany (ordered to germany as our post...) ... anyhow it's handled by my friend who's dealing with hw, I'm too blind and shaky to handle any tiny hw any more :( ...

> so why not take one of your ton of nucleo boards to verify the spi working...

started yesterday (on f4discovery with 407) after I gave up on fixing this board, should be done tonight, I'll then just copy the code ... same HAL thing should be copy/paste solution :) .. just wasted time till I found that I'm having weird issues .. .this boards handles megahertz without issues with jumper wires :( wtf is wrong with this 676 is beyond me... I'll do some tests ppl here asked to see maybe someone have idea

> next week you can deliver some boards.

as I mention, I'm rather close to you few hundreds km east, but our post is in strike, NOTHING arrives via post so if I order from JLCPCB it will arrive and wait in our customs till strike is over and then it will wait our turn before they deliver everything arrived before our boards... total mess.. we were driving to Hungary to collect some chips and boards we ordered to friends address.. not a normal situation otherwise neither we'll be working on the board this damaged nor...

[arhi]

UPDATE:

sw is done on another board, tested, so I'm sure my part works, PCB is out for HW team to fix :D but what I found this morning testing for the last time it looks like miso and mosi are mixed on the transciever side so output from slave is actually HiZ and transciever is picking up signal from ether and pushing it to it's output ... the point that output on transciever "looks like what I'm trying to send" is probbly output on slave affecting said ether and influencing that floating pin on the transciever... unfortunately my eyesight is *** and my hands are shaky and my microscopes and fine tools are not yet moved to my new lab so I cannot try to measure between mcu and transciever but the HW guy is young and with steady hands so he'll figure it out :D :D I'm sure :)

weird how ppl start to question basic sanity when this type of things start to happen, thanks everyone for the help!! These are the by far slowest few lines of code I written in 40 years of coding :( but we learn while we live :D