Search results

I'm a retired programmer, so I take long periods away from projects. I left this one in a 'page of design notes and some test code' state. The test code is included in this thread. I will pick the project up again in November, and anything I come up with will be share-able. If you have any...

Sounds like a very useful way to perform field upgrades. I do not know much about the SD side, but it is certainly possible to perform 'partial' code replacements on the Teensy. Anything I write (to perform field upgrades over CANBus) will eventually find its way onto github. If there is...

So, to fix the erroneous data being read back after flashing a Teensy 3.6, the code bus cache must be cleared. The following lines were added after flashing a phrase with a 3.6: //Invalidate any cached lines in the CODE bus cache LMEM_PCCCR |=...

I have a clue as to why the read back of flashed code is incorrect. It is a cache issue. In the teensy core ResetHandler routine (in the mk20dx128.c file), called at powerup, is the following code: #if defined(__MK66FX1M0__) LMEM_PCCCR = 0x85000003; #endif If I comment out this Teensy 3.6...

I, too, am interested in performing 'Over the Air' firmware updates of the Teensy - except replace 'Over the Air' with CANBus, since I am placing the Teensy 3.6 in an automotive environment. I began with the flash code provided by Jon Zeeff for Teensy 3.0/3.1/3.2. Thank you Jon! Refer to...

I clear the read fifo at the top of every txrx call, before entering the write/read for loop. I also added this line after the SPI_WAIT call but before reading the fifo: while (!(SPI0_SR & SPI_SR_RXCTR)); //Make sure rx fifo has data before reading This should not be necessary, but once...

I was receiving corrupted data, particularly the first received byte. The manual specifies the SPI module must be halted before clearing the receive fifo. Doing so fixed my problem. Here is an example of before and after: Before: SPI0_MCR |= SPI_MCR_CLR_RXF; After: SPI0_MCR |= SPI_MCR_HALT...