Recently doing a project with a client of SPI clock 4Mhz send us data, and initially thought the reception SPI simulation software, the result was I too young too simple.
Although it sounds 4Mhz speed is not high, but the equivalent of a level duration is 125ns, read by the library functions stm32, simply can not do, just needs to respond to interrupt a dozen instruction cycle, it is tens of nanoseconds out, then let alone read level to judge the state.
So I have to change the circuit board, was forced to accept the fate of using hardware SPI. Because the previous stm32 hardware IIC know there are problems, they are able to own their own simulation simulate all, this is a disadvantage SCM, has already done the hardware features they can not change, you do not know what happened inside it in the end, this is still time FPGA feel really fragrant.
After doing the configuration, use FPGA launched a wave, stm32 use SPI3 interrupt is received, the normal reception no problem. This aside.
After some time, the project started, the customer should send us once every 200us data (terrible, but fortunately did not use the software SPI, or else they should not have done what matter), this time the problem emerged: packet loss.
Troubleshoot the following possible factors:
- Whether the frequency is too high, resulting in the ability to keep up with hardware SPI receive?
- LE whether the SPI enable signal and the clock signal spacing between stm32 short lead time to the determination spi?
- Interference signal transmission?
For the first possibility , attempt to reduce the transmission frequency, no effect; try to lower the reception frequency, no effect;
For a second possible , try to start signal CLK and elongated NSS test, no effect;
It is time to think not interrupt too frequently result in failure to receive, so the DMA reception with SPI tried it, the configuration did not succeed, so give up. Of course, the reason to give is that I want to understand, even if the data is received by DMA, I have to respond immediately, so there is or has been interrupted.
That's when I Emmanuel line. Might as well try to close with a spontaneous self-development board? ?
Once you've configured the program, a test, found no packet loss! ! ! This fully demonstrates stm32 hardware SPI is no problem, the speed can keep up, try to enhance the transmission frequency is no problem.
A third possibility is that the
- The connection between the plates to our customers with temporary plates are being welded wire, whether due to a clock signal line too messy cause too much disturbance such readings fail?
- Due to the tight structure, board connectors and customer connections between the microcontroller IO port adapter through the multi-layer, is causing a disturbance signal too?
- Colleagues draw the PCB not very professional, there have been more cases go right angles to the line, is causing interference signal received is too big?
Next, grasping logic analyzer data, we first grasping plate to plate clients connecting line roots, found normal waveform; then grab the waveform microcontroller IO port roots, or do not know what hand shake, LE jitter signal, the remaining signal more normal. Specific crux lies in what, up to now have no idea, but definitely the board to determine the design problem.
At this time, we remind customers that grab data on the falling edge of the clock , often because of falling is clean, because of the rising edge of the PCB or lines may appear jitter.
So in the program into a falling edge of the clock to capture the data, sure enough, this phenomenon no loss of ~
Summary: explanation of this phenomenon, the circuit board design itself has a problem, leading to instability rising, then the board has been done since, in order to realize the function, it had to be to capture data falling into the rising edge of the clock capture data, so that it can improve the reliability of the transmission.
So back to the question I have thought about, stm32 SPI hardware design in the end there is no problem? The answer is determined. SPI hardware used to know, if the NSS stm32 end configured as hardware mode, then the entire communication is unable to complete the whole process, the NSS will be a low level state. By other relevant information, stm32 the NSS should be connected to a pull-up resistor externally to output timing properly. This design is more sick people, but I do not have specific tests it can not be achieved not jump to conclusions. You can test.
