This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Bug in DM368 SPI hardware?

We have problems with our SPI-EEPROM. Sometimes the last written data is lost after reboot.

We use the SPI driver of the PSP 03.21.00.04. It looks like it's a problem with the chip select.

After SPI transfer, the chip select remains asserted. Although the driver writes 0x00ff to the upper 16 bit of SPIDAT1.

I reproduced the following strange behaviour. After reading any address in the range of the SPI device, the chip select will be de-asserted.

For example, reading address 0x01c66ffc will do it for SPI1.

As crosscheck I wrote 0x10fe to the upper 16 bit of SPIDAT1. After reading any address, the chip select was asserted again.

I tested it with SPI0/CS1 and SPI1/CS0. Could this be an undocumented hardware bug?

Probably this problem only becomes important, if the last action before reboot/turn off is a write access. Because between two transfers, chip select will be de-asserted.

regards,

Martin