Renesas RA6M2 ile SPI EEPROM erişimi

[taydin]

RA6M2 işlemci ile bir SPI EEPROM arasında iletişim kurmam gerekiyordu. Önce okuma işini halletmekle işe başladım. Bu önemli, çünkü ne kadar okuma yaparsan yap, EEPROM için herhangi bir aşınma durumu sözkonusu değil. Ama yazma için aşınma sözkonusu. Programda bir bug varsa ve sürekli döngü halinda, maksimum hızda yazma yapıyorsa, kısa sürede EEPROM kullanılamaz hale gelebilir.

Datasheet'e göre okuma timing aşağıdaki gibi:

Yani CE# düşüyor, sonra okuma komutunu gönderiyoruz (03H), sonra 3 byte adress gönderiyoruz, sonra da EEPROM ilgili adresteki verileri göndermeye başlıyor.

 

[taydin]

Sonrasında bu timing'i elde etmek için RA6M2 nin SPI çevre birimini incelemeye başladım. Varsayılan ayarda RA6M2 her byte erişimi için ayrı ayrı CE# üretiyor. Bu benim işime yaramaz. Daha ayrıntılı çalışma modlarını inceleyince, bir dizi okuma veya bir dizi yazma için CE# nin aktif kalması sağlanabiliyor. Bu da benim işime yaramıyor, çünkü EEPROM okuma işleminde önce 4 byte yazıyoruz, sonra da N tane byte okuyoruz, ve bütün bu süreç boyunca CE# nin low kalmasını istiyoruz. Ama RA6M2 nin SPI çevre birimi bunu desteklemiyor.

Hatta biraz bakınca, çoğu MCU da durumun böyle olduğunu görüyorum. Çözüm olarak, CE# nin SPI çevre birimi tarafından değil de, yazılım tarafından bir GPIO ile kontrol edilmesini sağlayabilirim. Ama böyle yapınca da, CE# nin düşmesi ile transferin başlaması arasında belirsiz bir süre geçiyor, osiloskopta sinyali inceleyince sürekli sağa sola dans eden bir sinyal resmi ortaya çıkıyor, inceleme zorlaşıyor.

 

[taydin]

Ben de şöyle bir çözüm kullandım: RA6M2 nin SPI çevre birimi, full duplex erişimi destekliyor. Mesela 10 byte'lık bir data okuyacağım zaman, 14 byte'lık bir buffer ayırıyorum. Bu buffer'ın ilk 4 byte'ına okuma komutu ve adresi yazıyorum. Sonra da SPI işlemini full duplex olarak başlatıyorum. Bu durumda ne oluyor? 4 byte'lık komut ve adres zinciri yazılıyor. Bu sırada 4 byte da veri okunuyor, ama bu veri anlamsız bir veri ve buffer'ın ilk 4 byte'ını işgal ediyor. Sonrasında EEPROM da saklı olan veri okunmaya başlarken, buffer'da daha önce arta kalan veriler de yazılmaya başlanıyor. Ama EEPROM o aşamada okuma modunda olduğu için yazılan veriler havaya yazılmış oluyor ve herhangi bir sonuç doğurmuyor.

Test etmek için normal okuma yerine JEDEC-READ-ID komutu kullanman daha mantıklı. EEPROM'u yeni lehimledim, içerisi herhalde boş. Bu durumda FFH okuyacağım, bu da SPI bus iletişiminin doğru çalıştığı hakkında fikir vermeyecek. Çünkü EEPROM hiç takılı olmasa da muhtemelen FFH okuyacağım. Ama JEDEC-READ-ID komutunun ne döndürmesi gerektiği belli:

 

[taydin]

Sonuçta okunması gereken verileri doğru bir şekilde okumuş oluyoruz. CE# de doğrudan SPI çevre birimi tarafından kontrol edildiği için CE# nin düşmesi ile ilk veri akışının başlaması tamamen deterministik bir zamanlama ile gerçekleşiyor. Mesela ben şimdi persistence modunu açsam ve herhangi bir glitch var mı diye incelemek istesem, bunu yapabilirim ve uzun süre veri biriktirebilirim. Eğer CE# nin yazılımla kontrol edilmesini sağlasaydım bu mümkün olmayacaktı. Sinyaller tamamen birbirinin üstüne binecek ve içerisi grafik renkleriyle doldurulmuş 3 tane dikdörtgen görecektim.

 

[Ahmet]

hız önemli değilse ı2c eeprom kullanırım