There seems to be a significant difference (when it comes to my application and its SPI communication) between a software reset/reprogramming and a power on/off action by toggling the USB power. In case of reprogramming or teensy_reboot, the SPI communication fails consitently whereas after a hard reboot by removing and replugging the uUSB connector the SPI communication works as expected. Any idea what could be causing this and/or how to solve this strange behaviour?
Difference between software reset and power on/off
- Thread starter quaketurn
- Start date
- Status
defragster
Senior Member+
The Teensy may be starting too fast. Put a delay in setup() before SPI .begin. Not sure how to read as far as the power state of the SPI device - it is either a warm start in one case and it is ready in time, or a cold start and too fast Teensy .begin catches it unprepared. If it is already 'warm' powered when the problem presents - perhaps it is being confused as configured by the Teensy reset. Are there any pullups on the CS or the other line that likes one? Are there any other SPI device on the bus - or just a single device?
PaulStoffregen
Well-known member
Any chance that other SPI chip is being left in some special configured state? Any chance your init code depends on the SPI chip being in its default power-up state? To support warm boot, your init code needs to be able to deal with all possible prior config of the SPI chip, or have a way to reset it.
We see this sort of problem with I2C, where Teensy rebooted right in the middle of a 8 bit byte transfer. The I2C chip is still expecting more bits to arrive. The i2c_t3 library has long supported a feature to detect if the bus is locked up and generate several dummy clock cycles to get chips back to an idle state. This was recently ported to the Wire library. It was a pretty common issue.
Usually SPI is less susceptible. Most chips go back to an idle state and "forget" any partially delivered bytes when their CS signal goes back high. However, one common problem is SPI chips "hearing" random stuff while in programming mode, where the I/O pins are high impedance. A real pullup resistor on the CS pin is recommended.
- Status