STM32F103 ile yaptığım kartlar sorunsuz çalıştı. XP makine ile USB haberleşmesi de yaptılar.
Bu kartlardan birisini Win7 makineye taktığımda USB haberleşmesi yapılamadı. Compability vs sorunları ile uğraşırken bir kaç kez usb yuvasından söküp geri taktım. Nihayetinde bu kartı değilde aynı kartdan bir başka ikisini win 7 de çalıştırmayı başardım.
Çalıştıramadığım kartı tekrar taktım gene çalışmadı.
Fakat eminim XP de çalışmıştı. Tekrar XP makineye taktığımda makine sorunlu USB cihaz buldum deyip durdu.
STlinkUtil ile Çipi sildim ve yeniden program attım değişen bir şey olmadı.
Bunun üzerine Keil'de debug ederek sorunun ne olduğunu anlamaya çalıştım. Derlenen program gene sorunsuz çipe yüklendi.
Daha sonra kodları adımlatmaya çalıştığımda bir iki kodu doğru işletip ardından hoop memorynin bir başka noktasına sıçradı.
Defalarca denememe rağmen kodları düzgün adımlatamadım. Her defasında program counter'ın çok saçma adreslere gittiğini gördüm.
Break point koyduğum yerde kimi zaman duruyor. Kimi zaman ise bu noktadan kesin geçilmesi gerektiği halde bambaşka bir adrese gidiyor ve orda duruyor. Durduğu yere de breakpoint koymadım halbuki.
Sorun ne anlamadım.
Eğer USB konnektöre takılı kartı zart diye söktüğüm için bu sorun olduysa vay halime. USB konnektör ile STM data pinleri arasındaki hatta sadece 22 ohm dirençlerim var.
Halbuki daha önce USB haberleşen kartlarımı defalarca söküp taktım. Tek değişiklik bu kez win 7 laptop da deneme yapmış olmam.
mesaj birleştirme:: 02 Haziran 2015, 16:22:34
Gelişme
Reset pininin her 400ms de bir kaç yüz mikrosaniyeliğine lowa indiğini tesbit ettim.
Bu daha da ilginç oldu. Bu güne kadar STM'de hiç WatchDoğ kullanmadım ve aktif etmiyorum. Reset pinindeki kapasitörü lowa çekecek tek şey Reset pininin kendisi ve STM de bu özellik var.
Fikri olan yokmu?
Çipe çok farklı yazılımlar attım. Hepsi de çalışan uygulamalar. Hepsinde de aynı sorun var. Debug etmeye kalktığımda saçmalıyor.
Saçmalaması normal gibi reset pini 400 ms de bir lowa inip çıkıyor.
Besleme voltajı pırıl pırıl 3.3v.
Kart haricen mi yoksa USB'den mi besleniyor?
Herhangi bir output'u gnd'ye yada 3.3V'a bağlamış yada kısadevre ettirmiş olma imkanınız var mı? 400ms dediğinize göre periyodik olarak gerçekleşiyor, sebebi çakışma olabilir gibi geldi.
Vdda nasil bagli ?
Tüm besleme bacakları + - ye bağlı mı?
Besleme bacaklarının direnç değerlerini ölçüp,
sağlam çalışanlarla kıyaslayabilir misiniz hocam.
Reset bacağınında gnd ve Vcc ye göre dirençlerini
sağlam olanlarla kıyaslayabilirsiniz.
Bunları baskı devre üzerinde ve/veya çıplak çipte ölçerek deneyebilirsiniz.
Programı mümkünse hafızada başka bir bölgeye yazıp deneyebilirsiniz.
Garip gelebilir ama buna benzer bir durumda
çipin tüm bacaklarını topraklayıp çözüme ulaşmıştım.
Topraklama derken evet bildiğimiz faz nötr toprakdaki gibi topraklama.
Sanırım statik elektrik problemi olmuştu ve bu sayede çözülmüştü.
Aklıma gelenler bunlar.
Kart USB den besleniyor.
Voltaj sorunu yok. VDDA da bağlı.
Test yazılı yaptım. Reset rutininde hiç bir portu vs aktif etmeden sadece sayı sayıyor.
Bunda bile reset atıyor. Çipp reset yediği için debug da edilemiyor. Saçmalıyor.
Fakat bir iki kod adımlanırken doğru işler yapıyor. Zaten iki kodu da elle yürüttüğümde 400ms anca oluyor.
Tamam çip arızalandıysa arızalandı da. Aynı karttan 100 tane var. Bunun başına gelen onların da başına gelirse kötü olacak.
programda optimizasyon var mı üstad, coide de opt. yaparsam debugda sapıtıyor.
@muhittin_kaplan hocam optimizasyonu sona vurup uygulama derlemek ve sonucunda uygulamanın düzgün çalışması kodun doğru yazıldığının ve tasarımın başarılı olduğunun belirtisidir. Aksi durumda ise yani optimizasyon sonda iken uygulama sorunlu çalışıyorsa büyük olasılıkla yazılım hatalıdır ve mutlaka üzerinden geçilmelidir. Kod 2. ve hatta 3. kişilerle beraber tekrar elden geçirilmeden optimizasyon seviyesi düşürülerek nasıl olsa böyle çalışıyor demek eğer kritik bir uygulama geliştiriyorsanız çok tehlikeli bir durumdur.
konu dağılmasın ama sormadan edemeyeceğim,
Hocam Optimize edilmiş bir kod debug esnasında stepbystep çalıştırıldığında "kodların sıralı işlem yapmaması"(oradan oraya atlaması) normalmidir
ARM işlemcilerde optimize kod yazıldığında bazı işlemler debug edilemez daha doğrusu kolayca anlaşılamaz hale geliyor.
Makine kodu yerine C den ormek vereyim.
if (a==1) b=1 else b=9;
Burada tek satırda yazdığımız içib b=1 durumuna ya da b=9 durumuna break point koyamazsın. Koyarsan if satırına koyarsın bu durumda da her durumda bu satırda durulur.
Halbuki aynı kodu
if (a==1)
b=1
else
b=9;
Şeklinde yazarsak b=1 yada b=9 durumlarından herhangi birisi için breakpoint koyabilirsin.
Arm işlemcinin makine kodlarında da buna benzer yapılar var. İşlemci kodun üstünden geçiyor ama her zaman işlemiyor.
Bu satırın işleyip işlemediğini anlamak için break point koyamıyorsun gibi. Koarsan işleyeceği durumda da işlemeyeceği durumda da işlemciyi durdurmuş oluyorsun.
Debug etmem gereken yerleri klasik usulle yazıyorum. Bu durumda goto tarzı komutlar kullanıyorum bu da performansı düşürüyor. Optimize kodlama yaparsam bu kez bir gözüm flaglarda oluyor ve tamam işlemci bu komutu işletmedi ama bunu işletti yorumunu kendimin yapıyorum.
Yapacak bir şey yok. Derleyiciye güveneceksin. İlla debug edeceksen optimizasyonu kapatıp derle ardından debug et. Tamam diyosan optimizasyonu aç tekrar derle ve derleyiciyi yazanlara güven.
Alıntı yapılan: muhittin_kaplan - 02 Haziran 2015, 23:58:06
konu dağılmasın ama sormadan edemeyeceğim,
Hocam Optimize edilmiş bir kod debug esnasında stepbystep çalıştırıldığında "kodların sıralı işlem yapmaması"(oradan oraya atlaması) normalmidir
Evet normaldir. Şöyle düşünün öyle optimizasyonlar vardır ki siz kodda döngü yapmışsınızdır. Atıyorum 10 kere dönüyordur. Derleyici bunu optimize ederken unroll edip alt alta inline olarak koyarak hız optimizasyonuna gidebilir. Bu durumda siz koda bakarken loop görürsünüz. Ancak asm olarak öyle değildir. Aynı şekilde yazmış olduğunuz bir fonksiyon başka hiçbir yerde kullanılmıyorsa ve yaptığı iş basit bir registerı okuyup durum bildirmekse derleyici bu fonksiyonu optimize ederken direkt kullanıldığı yere açabilir bu durumda siz debug esnasında o fonksiyona dallanamazsınız. Bunlar sadece basit birkaç örnek.
Zaten kodlamada DEBUG flag bunun için kullanılır. Geliştirme aşamasında debug modunda çalışırsınız. Production yani üretim yapacağınızda RELEASE moda geçerek tüm debug fazlalıklarını atarsınız ve yazılımı ürünlere böyle yüklersiniz. Tabi tüm testleri geçtikten sonra. :)
Diğer kartlarınızda da benzer durum oluşmuyorsa suç çipe atılabilir. Bazen alınan ürünlerden bozuk çıkanlar yada zamanla sebebini anlamadığım şekilde bozulanlar olabiliyor. ST'de özellikle birkaç kez başıma geldi. Sistem bugün çalışıyor, yarın pat diye sistem çalışmaz oluyor. Discovery kartta bile bu durum başıma geldi, kart üzerinde bulunan st link için kullanılan işlemci USB'de görünmez oldu. Ancak Flash loader demostrator ile program yükleyebiliyordum.
Bugün sorunlu kartı silip tekrar orjnal programını yükledim. Yaklaşık 1dk boyunca çalıştı. Tüm fonksiyonlarını da yerine getirdi.
Sonra tekrar kendi kendini resetlemeye başladı.
Şöyle bir durumdan şüpheleniyorum.
Mesela clock fault durumunu aktif etmiştim diye hatırlıyorum.
Bunun gibi çok çok kritik fault durumları oluşuyorsa bunlara ait event handler rutinleri şu anda basit bir döngüden ibaret. Belki bu gibi durumlarda xtali devre dışı bırakıp dahili oscye geçmek falan lazım.
Gerçi çipi xtalsiz çalıştırdığımda da bu sorun düzelmiyordu.
Aslında çok güzel bir problemle karşı karşıyayım.
Soru: Çipin sorunu ne?
Debugger işe yaramıyor. Elim kolum bağlı durumda.
Dış dünya ile iletişim kurmam için 400ms zamanım var.
Çip resetlenince tüm sorularımı 400ms içinde bana söyleyebilecek durumda ve bunun için program yazmak gerekecek.
VddA daki gerilimi skopla inceleyebilir misiniz ?
PLL vs buradan besleniyor ya, ben buradan şüpheleniyorum.
Dediğim gibi Vdda Vdd ile aynı beslemeye doğrudan paralel bağlı. Besleme çok güzel bir regülatörle sağlanıyor. Dekuplaj sorunu da yok ve 3.3v scopta pırıl pırıl görünüyor. Gnd de bence mükemmel.
Aynı devreden çokca var. Diğerleri sorunsuz çalışıyor bu sorunlu ise
PCB sorunu vardır. Malzeme sorunu vardır. Lehim sorunu vardır.
PCB ve Lehim sorunu olmadığını gördüm. Malzeme sorunu varsa
Regülatör, xtal, dekuplaj kapasitörleri, MCU.
MCU dışındakileri tel tek değiştiririm.
Tek aradığım MCU sağlam ise neden kendini resetler sorusunun cevabı. (Mesela xtal bir süre sonra bozulursa, Reset kapasitörü bir süre sonra kısa devre olur fakat tekrardan kendine gelirse, Vcc1 bacağına bağlı kapasitör açık devre olursa gibi)
mesaj birleştirme:: 03 Haziran 2015, 15:45:05
Lehimlenmiş devrelerde ilave bir mekanik çalışma yapmam gerekti. Her bir devrede bu çalışmayı yapıyorum.
USB konnektörün karta sımsıkı tutunmasını sağlayan iki yanda Gnd pini var. Bu pinler lehimlenince karttın arka yüzünde yaklaşık 1..2 mm uzantı yapmış.
Bu uzantı usb kutusu kapatıldığında kutuda bombeye neden oluyor. Bende bu pin çıkıntılarını dikkatlice zımpara makinesiyle alıyorum. Bu esnada kart aşırı titreşime maruz kalıyor.
Xtal bu durumdan memnun kalmayacaktır. Öte yandan kartta soğuk lehim riski olan noktalar da kendini gösterebilir.
Hocam STM32'de değil ama STM8'de garip bir hata ile karşılaşmıştım. O hatayı gördükten sora, hiç bir şey garip gelmiyor bana.
STM8S105 MPU , PB0'dan GND'ye bir buton ve butona paralel bir 100n kapasitör var. PA3'te de bir tane led var.
kod sadece şu kadar
void main(void)
{
clock_init();
gpio init(); // pb0 input, pullup olarak pa3 output pushpull olarak init ediliyor.
while(1)
{
Toggle(pa3); // fonksiyon sembolik. kütüphanedeki fonksiyonu hatırlayamadığım için böyle yazdım.
for(unsigned int i=0;i<60000;i++);
}
}
Doğal olarak kodu çalıştırdığım zaman Led belirli aralıklarla yanıp sönecek. Netekim öyle de yapıyor.
Ama butona basılınca ( buton portunu init etmiş olmama rağmen hiç bir yerde kullanılmadığına dikkat et)
program rastgele bir yere dallanıyor , bazen komple uçuyor , bazen bir kaç saniye bekleyip tekrar main'e dallanıyor, bazen butona basınca uçuyor tekrar basınca main'den devam ediyor.
donanımı 3-4 kişi ile tek tek inceledik , grültülere , voltaj seviyelerine vs.. baktık hepsi normal.
butona bağlı kapasiteyi sökünce düzeliyor :)
MPU'nun bozuluş olma ihtimaline karşı bir kaç kartta denedik, sonuç aynı.
Mühendisliğin bittiğ yer , belki de başladığı yer. emin değilim. :)
@Klein
B0 için external interrupt açık olup handler'ı tanımlanmamış olduğundan yapmış olabilir mi?
Hayır. bütün ihtimalleri denedim. Bütün kesme izinlerini kapattım. Zaten oradan olsa kapasitör yokken de aynı şeyi yapması gerekir.
USB ile bağlanan cihazın bilgisayarda tanımlanana kadar 100mA in altında çekmesi gerekli.
USB'nin beslemesi kesilip geri veriliyor bilgisayar tarafından eğer tanımlanmadan 100mA üstüne çıkıyorsa
USB rutinlerinde ayrıca resetleme var mı?
Böyle bir durum yok. Olsa zaten besleme hattındaki anormalliği gözlerdim.
Reset bacağındaki voltaj 3.3v iken içerideki transistör reset kapasitörünü hızlıca boşaltıyor. Ardından kapasitör klasik RC devresindeki davranış biçiminde voltajını artırıyor.
Belliki MCU bir şeye kızıyor ve kendini resetliyor.
Denemeyi usb rutinsiz de yaptım. Çok basit a=a+1 döngüsünde bile aynı durum sözkonusu.
Fakat yarın kartı harici besleme ile tekrar deneyeyim.
hocam ayni devreden birtane daha montaj yapma sansiniz varmi? birde hocam. usb yi aktif etmeden sadece let blink yazilimi icindemi ayni seyler oluyor? :-\
Üstad yazmamışsın ama programı yazarken acaba CubeMx kullandın mı?
Derleyici de Keil galiba.
Derleyici Keil. Cubex kullanmadım.
Kartlardan sadece 1 tanesi sorunlu çalışıyor değilmi ?
Şu zamana kadar 5 tanesine kod yükledim. 5 de 1.
Diğerlerine yüklemenizi engelleyen bir şey varmı ?
5 te 1 bile donanımsal sorun olduğu gösterecek kadar yüksek bir orandır.
Regulator, kristal ve en son mcu değiştirilebilir.
Sorunu buldum.
Dokumanda reset kaynaklarına vs bakarken User Configuration Byte'a atıfta bulunulmuş.
Konunun detaylarına bakmadan birden STlinkUtil de koruma bitleriyle falan uğraştığımı hatırladım.
Derhal stlinkutilde User Configuration sayfasına baktığımda 3 kutucuk gördüm.
WDG_Sw
nRST_Stdby
nRST_Stop
Bu kutuları işaretledim. Çip artık kendini resetlemiyor.
(http://i.hizliresim.com/ZDzyy0.gif) (http://hizliresim.com/ZDzyy0)
Bunun altında yatan sebeb neydi? Yani o kutuları isaretleyince ne değişti? Merak ettim
nRST_STDBY
0: Reset generated when entering Standby mode. 1: No reset generated.
nRST_STOP
0: Reset generated when entering STOP mode. 1: No reset generated.
WDG_SW
1: Software watchdog. 0: Hardware watchdog.
Kutuları işaretleyince herhalde adı geçen bitler 1 oldu.
İlk 2 durumda reset üretilmesi engellendi. Gerçi standby yada stop durumuna girmeye neden olan rutin parçam yok.
3. Kutunun Tickini kaldırınca Hardware Watch Dog'u açmışım. Tıklayınca kapatmış oldum.
Bilinçli yaptığım bir oynama değildi. Watch doğ'u yazılım içinden etkinleştirmediğim için watch doğ kullanmıyorum demiştim. STLinkUtil'de watch doğ'u vs aktifleştirdiğini bilmiyordum.
Dediğim gibi bilinçsizce kutuların tikini kaldırmamdan kaynaklanan bir olay olmuş.
Hocam yani butun sorun watch dog yuzundenmiymis? :P
Malesef.