Freescale Kinetis KE - flaş yazma

Uzun yıllardır çeşitli mikrodenetleyiciler ve mikroişlemciler kullanıyorum, ancak Kinetis KE serisi (özellikle S9KEAZN64AMLC) tarafından uyarıldım.

17 Oca 2015 TL; DR:

Freescale onaylar onların kinetis Tasarım Stüdyosu yazılımının v2.0.0 (kendi TRK-KEA64 eval pansiyon dahil) bu cihazla işi değil bu. Şimdilik CodeWarrior MCU V10.6 kullanılmasını öneriyorlar.

Segger, sorunu düzelten ve KDS ile bir Segger J-Link Lite CortexM hata ayıklayıcı kartı kullanmanıza ve tam program / hata ayıklama yeteneğine sahip olmanızı sağlayan v4.96a'yı ("a" önemli, v4.96 kullanıyordum) yayınladı.

Segger v4.96a'yı yayınlamadan önce Freescale'in ucuz (15 $) FRDM-KL25Z değerlendirme kartında OpenSDA hata ayıklayıcısını yeniden programlayarak çipin yanıp sönmesini başardım (v4.10.6.240 kullanarak). Daha sonra USBDM'nin bağımsız "ARM Programmer" yazılımını kullandım. "Oldschool" hata ayıklamada ihtiyaç duymayacak kadar yetkin olduğum için, hata ayıklamayı çalışmaya çalışırken fazla zaman harcamadım. Yerleşik hedef KL25'e "iyi huylu" bir programın yanıp söndüğünden emin olun, ya da yerleşik hedef KL25'in sıfırlama hattı J11 kesimi ile bile OpenSDA hata ayıklayıcısına hala bağlı olduğundan programlamaya müdahale edebilir (bkz. Keith Wakeham'ın blog yazısı , aşağıda bağlantılıdır).

Sorunu belirlememe ve bulgularımı e-posta yoluyla onaylamama yardımcı olduğu için Erich Styger'e çok teşekkür ederim .

Şimdi düzenli olarak planlanan sorumuza dönelim:

Aptalca basit bir 3.3V koparma kartı yaptım. PTA'da bazı LED'ler var, PTC'de bir UART bağlantısı ve SWD hatları özel hatlarında. Bu tahtada tam anlamıyla süslü veya eğlenceli bir şey yok.

Cortex-M için bir J-Link Lite kullanıyorum (J-Link LITE CortexM-9, bkz. Https://www.segger.com/jlink-lite-cortexm.html ) ve hem OSX hem de Windows altında aynı sonuç: J-Link Commander yardımcı programı çipi tanımlayabilir, SRAM'a okuyabilir ve yazabilirim ve manuel okuma ve doğru bellek eşlemeli G / Ç adresine yazarak çevre birimleriyle oynayabilirim. Yine de cihazı yanıp sönmeye çalıştığımda başarısız oluyor.

$ JLinkExe
SEGGER J-Link Commander V4.94c ('?' for help)
Compiled Oct 31 2014 20:08:55
DLL version V4.94c, compiled Oct 31 2014 20:08:48
Firmware: J-Link Lite-Cortex-M V8 compiled Jul 17 2014 11:40:12
Hardware: V8.00
S/N: 518107921
Feature(s): GDB
VTarget = 3.332V
Info: Could not measure total IR len. TDO is constant high.
Info: Could not measure total IR len. TDO is constant high.
No devices found on JTAG chain. Trying to find device on SWD.
Info: Found SWD-DP with ID 0x0BC11477
Info: Found Cortex-M0 r0p0, Little endian.
Info: FPUnit: 2 code (BP) slots and 0 literal slots
Cortex-M0 identified.
Target interface speed: 100 kHz

J-Link>device skeazn64xxx2
Info: Device "SKEAZN64XXX2" selected (64 KB flash, 4 KB RAM).
Reconnecting to target...
Info: Found SWD-DP with ID 0x0BC11477
Info: Found SWD-DP with ID 0x0BC11477
Info: Found Cortex-M0 r0p0, Little endian.
Info: FPUnit: 2 code (BP) slots and 0 literal slots

J-Link>r
Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.

J-Link>erase
Erasing device (SKEAZN64xxx2)...

(...several second pause while it communicates with the MCU...)



****** Error: PC of target system has unexpected value after erasing sector. (PC = 0xFFFFFFFE)!
---------------------------------------------------------------------- Registers -------------------------------------------------------------------------------------
    PC   = FFFFFFFE
Current: R0   = 00F3E3BE, R1   = 00000001, R2   = 4004801C, R3   = 00000001
    R4   = 00000000, R5   = 00000000, R6   = 000000F4, R7   = 1FFFFD61
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------


Info: J-Link: Flash download: Total time needed: 2.174s (Prepare: 0.894s, Compare: 0.000s, Erase: 0.736s, Program: 0.000s, Verify: 0.000s, Restore: 0.542s)
ERROR: Erase returned with error code -5.

J-Link Lite gayet iyi (onunla başka bir Cortex-M0 işlemci olan nRF58122 SoC'yi okuyabilir ve yazabilirim) ve cihaz başka şekilde çalışıyor gibi görünüyor. DigiKey fabrika taze stok oldukları gibi Kinetis kilidini biliyorum, ama o zaman bile JLinkExe "kinetis unlock" komutu herhangi bir hata veya yararlı bilgi olmadan zaman aşımına uğradı.

Bu noktada, aptalca bir şey yaptığımdan eminim, ama ne olabileceği için kaybım var.

Daha önce bu cihazlarla çalışan var mı? Onları nasıl programlıyorsunuz?

geçiş yolu eklemek için düzenle:

Biraz daha bilgi:

NMI # pininin sıfırlama dışında etkinleştirildiğini (ve SIM_SOPT okuyarak bunu doğruladığını) değil, aynı zamanda etkinleştirildiğinde dahili bir çekmeye sahip olduğunu okudum. Bu belirli kısımda PTB4, tasarımımda bağlantısız olan pim 10 üzerindedir. NMI pinini devre dışı bırakmak hiçbir fark yaratmaz. RST # benzerdir; Pimi topraklayan ve aynı zamanda J-Link Lite'a giden bir düğmeye bağlanır, ancak harici bir çekme yoktur. NMI # gibi, RST # pimi de PTA5 sıfırlama olarak yapılandırıldığında etkinleştirilen dahili bir çekme özelliğine sahip olduğundan bu önemli değildir.

Şimdi saate bakılıyor ... Sıfırlama dışında, ICS FLL için saat kaynağıdır ve ICS_C2'deki BDIV 001 (varsayılan sıfırlama) olarak ayarlanmıştır. Doğru anlarsam, 32kHz dahili osilatörün FLL ile 1024 ile çarpılıp 2'ye bölünerek ICSOUTCLK 32kHz * 1024/2 veya 16.8MHz anlamına gelir. J-Link CLI aracılığıyla ICS_S okuyarak FLL kilitli olduğunu doğrulayabilirsiniz:

J-Link>mem8 40064004 1
40064004 = 50

(LOCK ve IREFST ayarlanmıştır, bu doğrudur.)

Daha sonra SIM_SCGC'yi okuyarak SIM'in flaş denetleyicisi için saati etkinleştirdiğini doğrulamak için devam ediyorum. SIM_BUSDIV içindeki BUSDIV'in sıfıra ayarlandığından emin olmak için hızlı bir şekilde kontrol edebilirim, bu da BUSCLK'nin ICSOUTCLK ile aynı frekansta olduğu anlamına gelir (yani bölünmez):

J-Link>mem32 4004800c 1
4004800C = 00003000
J-Link>mem32 40048018 1
40048018 = 00000000

Şimdiye kadar her şey iyi görünüyor. BUSCLK 16.8MHz'dir ve flaş denetleyicisi saatine geçilmez.

Şimdi flaş denetleyicisine geçelim. Sıfırlama dışında FCLKDIV sıfırdır ve 1MHz saat gerekir. KEA64RM'deki Tablo 18-2, FDIV'nin 0x10 olarak ayarlanması gerektiğini göstermektedir.

Sıfırlandı:

J-Link>mem8 40020000 1
40020000 = 00

Bölücüyü kurmak ve işleri doğrulamak iyi:

J-Link>w1 40020000 10
Writing 10 -> 40020000
J-Link>mem8 40020000 1
40020000 = 90

FDIVLD ayarlanır ve FDIV'deki doğru değer gösterilir.

Çok ileri gitmeden önce, flaşın korunmadığından emin olalım:

J-Link>mem8 40020001 1
40020001 = FE

KEYEN = 11 (devre dışı) ve SEC = 10 (güvenli değil). Tamam. Cihazın boş olduğunu doğrulamaya çalışalım:

J-Link>mem8 40020006 1
40020006 = 80
J-Link>w1 40020002 0
Writing 00 -> 40020002
J-Link>w1 4002000a 1
Writing 01 -> 4002000A
J-Link>mem8 40020006
J-Link>w1 40020006 80
Writing 80 -> 40020006
J-Link>mem8 40020006 1
40020006 = 83

Burada FSTAT'taki MGSTAT bitlerinin boş denetimin başarısız olduğunu ve düzeltilemeyen hataların bulunduğunu gösterdiğini görüyoruz. Garip. Kendimizi silmeyi deneyelim:

J-Link>w1 40020002 0
Writing 00 -> 40020002
J-Link>w1 4002000a 8
Writing 08 -> 4002000A
J-Link>w1 40020006 80
Writing 80 -> 40020006
J-Link>mem8 40020006 1
40020006 = 80

Tümünü sil komutu başarılı oldu. Şimdi boş bir çek deneyelim:

J-Link>w1 40020002 0
Writing 00 -> 40020002
J-Link>w1 4002000a 1
Writing 01 -> 4002000A
J-Link>w1 40020006 80
Writing 80 -> 40020006
J-Link>mem8 40020006 1
40020006 = 80

Şimdi boş çek iyi mi?

Bu noktada vazgeçmeye, bu prototiplerin kaybını yemeye ve daha önce hiç bu tür sorunları yaşamadığım bir işlemci ile devam etmeye hazırım. Kinetis belgeleri yeterince kapsamlı ancak çok yoğun ve başlamak çok zor. Bellek okumaları ile I / O'yu kıpırdatıp diğer çevre birimlerine erişebilirim ama hayatım boyunca flaş kontrol cihazında neyin yanlış olduğunu anlayamıyorum. 20 yılı aşkın süredir mikroslarla çalışıyorum ve bu tür bir zorluk daha önce hiç karşılaşmadığım bir şey.

20150102 düzenleme:

Yani hala buraya gitme. Aslında bir FRDM-KL25Z değerlendirme kartı (DigiKey'den 15 $) satın aldım ve genel CMSIS-DAP yazılımını OpenSDA hata ayıklayıcısına koyarak ve J11'i Keith Wakeham'ın bloguna göre keserek değiştirdim . Sıfırlama hattına müdahale etmemesi için basit bir program çalıştıran yerleşik hedefim (KL25Z) var ve SKEAZN64'ümü OpenOCD ile görebilir ve onunla oynayabilirim, ama ne yazık ki de programlayamaz. Kinetis Design Studio (KDS) yazılımı, Kinetis'imi yanıp sönmeyecek çünkü korumalı olduğunu ve toplu silme yapmam gerektiğini söylüyor, ancak OpenOCD (KDS'nin bir parçası olarak) bunu nasıl yapacağını bilmiyor gibi görünüyor. Mac'im üzerinde oluşturduğum OpenOCD'nin git master sürümü Kinetis'i anlıyor, ancak belirli KEA serisini anlayamıyor, bu yüzden kareye geri dönüyorum.

J-Link'e geri dönüyoruz ...

@AdamHaun gerçekten iyi bir ipucuna sahipti ve J-Link sıfırlama türünü (rsettype komutu) '6' (Kinetis) türüne ayarlarsam J-Link'in çekirdeği sıfırladıktan sonra bekçi köpeğini devre dışı bırakması gerekiyor. WDOG_CS1 kaydına (0x40052000) bakıldığında durum böyle görünüyor, ancak hala zar yok gibi görünüyor. Silme işlemi, 0xfffffffe ve hata kodu -5'te PC ile raylardan çıkıyor gibi görünüyor ve "kinetis kilidini aç" komutu yalnızca SIM_SOPT kullanarak sıfırlama pinini devre dışı bıraktığımda çalışır (32 bit değeri 0x00000008 - 0x40048004 yazarak). Ne yazık ki, CPU'nun bir daha durdurulamaması durumunda, muhtemelen SWD arayüzü SWD DAP'ı bilinen bir duruma zorlamak için sıfırlama hattını kullanamaz.

20150103 düzenleme:

Yanıp Sönen LED'im Var

TEKRAR ET

Yanıp Sönen LED'im Var

TL; DR sürümü: USBDM görüntüsünü FRDM-KL25Z panosuna (tek başına bir hikaye) koyun, testi kendiniz tahtaya göndermek için ARM Programcı bağımsız uygulamasını kullanın. Güç çevrimi ve ses.

Uzun versiyon daha sonra gelecek. Şimdi bu KEAZN64 kartı için yazılım yazmak ve hatalarını ayıklamak, onunla birlikte gelen diğer yazılımları değiştirmek / test etmek ve başka bir istemci için bazı belgeler üzerinde çalışmak için 48 saatten az zamanım var. Ben söz veriyorum olacak detaylı bir cevabı olan bu soruyu güncelleyin. Sadece başarımı paylaşmak istedim. Yardımınız için HERKESE teşekkür ederim. Modlarla konuşmak zorunda kalabilirim, çünkü özellikle birkaç kişiye lütuf vermek istiyorum.

İşleminizde herhangi bir mantıksal hata bulamıyorum, ancak bazı öneriler:

• ayrıca bir FTMRH_FERSTAT kaydı (4002_0007 saatte). Size neyin yanlış gittiğini söylemeliyiz ... ama sadece eşlik (veya çift eşlik hataları) durumunda. Bu durumda herhangi bir şeyi kaydedecek veya hataları silebileceğine ikna olmadım, ama muhtemelen kontrol etmeye değer.

• KEA dokümantasyonunda ayrıca bir kesintinin flaş hataları nedeniyle tetiklenebileceğinden bahsedilmektedir (bölüm "18.3.5 Flaş ve EEPROM kesintileri"). SEGGER onu sildiğinde ne olduğunu bilmiyorum, ama FSTAT kaydında işaretlenmiş hataları gördüğünüz için PC'nin neden değiştiğine dair makul bir açıklama. Ne yazık ki kesinti kontrolörünün ("3.3.2 İç İçe Vektörlenmiş Kesme Kontrolörü (NVIC) yapılandırması") için KEA dokümantasyon bölümü tam dokümantasyon için ARM web sitesinin yönünü oldukça belirsiz bir şekilde gösteriyor. Flaş hataları için varsayılan bir önyükleme işleyicisi (önyükleme sırasında) ayarlanmış olup olmadığını anlayamadım.

• Yalnızca sektör düzeyinde silme işlemleri yaptınız, bu nedenle manuel olarak (uygun kaydı kendiniz yazarak olduğu gibi) tam bir flaş silme komutu verin; bunu tek bir komutta yapmanın tek yolu kılavuzun 18.3.9.10 (s. 246) bölümünde belgelenen "Güvenli olmayan flaş komutu" gibi görünmektedir. Bu hem cihazı "güvenli hale getirmez" ve tam flaş ve EEPROM silme işlemi yapar. Ne zaman tamamlandığını görmek için bir FSTAT bitini (CCIF) yoklayabilir ve daha sonra hata bayraklarını tekrar kontrol edebilirsiniz. DÜZENLEME: ayrıca kılavuzda "18.3.9.7 Tüm Blokları Sil komutu" bölümü var, duh.

• daha düşük bir bus saat frekansı deneyin. 0.8 Mhz üzerindeki her şey belgelere göre çalışır. Bunu öneriyorum çünkü Freescale forumunda harici bir flaşın iyi çalıştığı, ancak hala ok-belgelenmiş aralıkta olan belirli bir frekansın üzerinde olmayan bir iplik vardı. Bu nedenle, çipteki flaş kontrolörünün pul pul olması ve belirtilen frekansların tümünde çalışmaması mümkündür.

• aynı şekilde, farklı bir çip. Bu maliyetin (yaklaşık 3 $) ne kadar kötü olduğu göz önüne alındığında akıl almaz değil. Çoğu yönden iyi çalışan ancak belirli korumalı mod talimatlarında garip hatalar içeren gömülü bir x86 çipine sahip olduğumu hatırlıyorum; benim sorunum aynı marka farklı bir cihazla gitti. Freescale'in bu cihazlar için (kamuya açık olarak belirtilmiş) basamaklar ve hatalar olup olmadığı açık değil.

Bu sayfadaki başkaları tarafından söylenmeyen önerileri hata ayıklama açısından aklıma gelen tek şey bu.

20150103 düzenleme (ler):

(Malzeme yorumlarımdan buraya taşındı ve genişletildi)

Görünüşe göre tüm Kinetis Serileri (en azından resmi olarak) tüm flaşörlerle test edilmemiştir. Aslında kullandığınız oldukça yeni EA serilerinin resmi olarak sadece Freescale'in kendi / OEM Cyclone MAX flaşörü tarafından desteklendiği görülmektedir; EA seres için Freescale sayfasında listelenen tek kişi . Şimdi, KL0 gibi eski Kinetis için liste SEGGER dahil olmak üzere çok daha uzundur . Bunun sadece EA serisi için diğer flaşörlerin testinin eksikliğinden mi yoksa aslında sadece Cyclone MAX'in şu anda bildiği bir programlama tuhaflığı nedeniyle olup olmadığını bilmiyorum. Belki de bu Freescale'in diğer flaşörleri listelemede yavaş olmasını umuyordum, ama J-link kılavuzunu kontrol ettikten sonra (umarım doğru olanı), orada test edilen Kinetis E veya EA serisi yoktur (s. 249), ancak sadece Kinetis K10 ila K60 cihazları (ve bazı eski MAC7'ler).

Cyclone MAX için PExDrv yazılımının / ürün yazılımının 3/20/2014 tarihli ve "MKE04Z64, MKE04Z128, MKE06Z64, MKE06Z128, SKEAZ64 ve SKEAZ128 türevleri için destek ekleyen" bir hizmet paketine (v10.3) sahip olması dikkat çekicidir. Bir başka ipucu da Freescale'in Kinetis için kendi açık kaynaklı önyükleyici / flashloader yazılımının, daha önce 12/2014'te güncellenmesine rağmen, E veya EA [alt] serisi cihazları desteklendiği gibi listelemez. Bu nedenle, E / EA serisi ve K10 gibi diğer Kinetis arasında yanıp sönme konusunda yeterince farklı bir şey olduğunu düşünüyorum, ancak tam olarak bu farkın ne olduğu hakkında hiçbir fikrim yok. Bu nedenle, EA yanıp sönmesinin Cyclone MAX dışında herhangi bir şeyle otomatik olarak çalışmasını beklemenin muhtemelen bu noktada gerçekçi olmadığını düşünüyorum. Sonunda EA serisi belgelerden "çıplak metal" seviyesinde (doğrudan kayıt komutları) nasıl yapılacağını anlayabilirsiniz, ancak belgelerin oldukça geniş olduğunu kabul ediyorum; kesinlikle bir referans el kitabı olan adım adım talimatlardan yoksundur. Freescale'in açık kaynaklı önyükleyici / flashloader'ı E / EA serisini destekleseydi,

FRDM-KL25Z (Kinetis L serisi ile birlikte gelir) ile denemeniz aynı yönü gösterir, yani bir L serisini EA serisi ile değiştiremez ve aynı flaşörü (bu durumda OpenSDA) kullanamazsınız.

Ve eğer "bir programcı için 100 dolar [s] saçma olduğunu düşünen Keith" gibiyseniz, muhtemelen o Siklon'a 900 $ + düşürme perspektifinden memnun olmayacaksınız. Freescale'in otomotiv müşterilerini uçurmak için bunu yapıp yapmadığını bilmiyorum ... Kinetis serisinin çoğu için takımın E / EA ile çalışmaması kesinlikle garip görünüyor.

Ayrıca OpenSDA'nın yanıp sönen fonksiyonunun sadece MS Windows altında çalıştığını da unutmayın .

Daha fazla tahta denemek (hacklemek) istiyorsanız, E serisi Kinetis'li bir tane daha iyi bir fikir olabilir, örneğin FRDM-KE02Z (Digi-Key'de 13 $); ayrıca OpenSDA kullanır, böylece hacklenebilir. Anlayabildiğim kadarıyla EA serisi ile kurul yapmıyor / satmıyorlar. Bununla birlikte, her iki işlemci aynı (örneğin L) serisinde, ancak farklı sayılarda olsa bile , kendi kartındakinden farklı bir Kinetis tipi programlamak için bir OpenSDA işlemci / kart kullanamazsınız . Ne yazık ki OpenSDA'daki "Open" (Açık), SDA spesifikasyonunun açık olduğu anlamına gelir, kaynak kodunu açık kaynak olarak verdikleri anlamına gelmez; bu yüzden bir E serisi flaş programlamak için kaynak kodu bile bulamıyorum. Görünüşe göre, bu konuda sadece yarı sağım. OpenSDA v1 açık kaynak kodlu değil, v2 kodlu .

İşte OpenSDAv2'deki düşüş . Temelde sadece bir CMSIS-DAP / mbed bootloader ve flaşör. Bu nedenle , v1 ile aynı özelliklere sahip olmayabilir veya aynı yongaları desteklemeyebilir ve aslında durum böyle olur çünkü flash_features.h , SKE'yi (EA serisi) yalnız bırakan herhangi bir MKE'yi (Kinetis E-serisi) listelemez. cihazlar. Özetle, Freescale'in EA serisi için önerisi şöyle görünüyor: 900 dolarlık Siklon flaşörümüzü ya da serbest bıraktığımız herhangi bir eksik açık kaynak parçasından kendi şansınızı yazın.

Bununla birlikte, en azından E serisi Kinetis'i, yani USBDM'yi programlayabilecek açık kaynaklı bir proje olduğu ortaya çıkıyor . Değişiklik günlüğünden ilgili bit :

V4.1.6.140 (Nisan 2014)

Ek Kinetis cihazları (MKE04, MKE06, MK64F)

• MKE aygıtları için düzeltmeler (Toplu Silme dışında programlanamadı)

Ve bu günlük girişine dayanarak, kesinlikle E-serisi ilginç görünüyor. EA serisi (SKE) için doğrudan destek yoktur, ancak kendi flaşörünüzü kesmek istiyorsanız bu kod tabanı muhtemelen en iyi bahistir; veya USBDM'nin yazarını EA serisi (SKE) desteği eklemeye ikna edebilirsiniz. USBDM donanımı olarak, satın aldığınız FRDM-KL25Z'yi kullanabilirsiniz ; ancak yine de SKE yongalarını desteklemek için USBDM yazılımını hacklemeniz gerekir.

USBDM için ana yapılandırma dosyası oldukça korkutucu görünüyor. USDBM'de farklı MKE serisi cihazlar için farklı flaşörler (kod tabanları) kullanılır: MKE04 ve MKE06 için "FTMRE" adı verilen bir şey kullanılır, ancak MKE02 için "FTMRH" kullanılır. Kendimi iki kod tabanına kısaca baktıktan sonra, FTRME kod tabanını değil, kesinlikle FTRMH kod tabanını istiyorsunuz . İkincisi SKEA64 cihazınızdan farklı bir FTMRH yapısına sahiptir, örneğin saat bölücü ilk değil 4. alan. FTRME ayrıca FIDV veriyolunu çipiniz için aralık dışında görünen 0x17 = 24Mhz olarak ayarlar (KEA64 kılavuzundaki s. 224, maksimum 20Mhz olduğunu gösterir). FTMRH, 0x0F = 16Mhz (yaptığınız gibi) olarak ayarlıyor, ki bu iyi görünüyor.

Bu noktada, (Cyclone MAX'ı satın almak istemiyorsanız) en iyi seçenek, çipinizin kod tabanı ile çalışmasını sağlamak için Podonoghue ile iletişime geçmektir. Aktif ve yeni cihazlarla (freescale forumunda) yardımcı olmak için oldukça istekli görünüyor .

Ayrıca bu USDBM kaynak kodundan, ilk olarak kendi ürün yazılımı güncellemesini almadığı sürece SEGGER'inizin SKEA'nızı doğru bir şekilde flaş edebilmesinin hiçbir yolu olmadığını kehanet edebilirim. Bunu neden söylüyorum? USDBM'nin FTMRH kod tabanı tam olarak bir cihaz tarafından kullanıldığından, SEGGER'inizin her ikisiyle ilgili hiçbir şey bilmediği görünen MKE02 (kılavuzuna göre). Kinetis L ve K serisi gibi diğer daha yaygın cihazlar, "FTFA" kod tabanına dayalı farklı bir USDBM flaşör kullanır. FTFA'nın koduna bakarsanız , flaş denetleyici kayıt yapısı (0x40020000'dan başlayarak) bunlar için farklıdır; ilk alan bile bir saat bölücü değil, stat sicili vb. Freescale'in uyumsuz cihazlar yapması için "Harika" bir yol ... ama şüphesiz flaşör üreticileri için bir nimet.

Bunu denediniz mi: Segger J-Link ile FLASH kilidini açma ve silme

İddiaya göre:

Korumalı FLASH sektörlerini Segger J-Link ile yeniden programlamak için önce cihazın kilidini açıp toplu olarak silmem gerekiyor. Bunun için, cihazın korumasını kaldırmak ve silmek için bir komut satırı arabirimine sahip J-Link Commander yardımcı programı vardır. Sadece silmek için J-Flash (ve Lite), özellikle 'temiz' bir cihaz belleği almak için çok kullanışlı bir araçtır.

İlginç bulduğum şey, kilidini açmak için bir sonraki adımda kilidini açmanız ve silmeniz gerektiğidir:

Ama öyle görünüyor ki bir kilit açma ve ardından kalıcı hale getirmek için bir silme yapmam gerekiyor. Aygıtı silmek için aynı komut satırı yardımcı programını kullanabilirim. Ama önce aygıt adını belirtmeliyim ve sonra silebilirim (KL25Z için örnek):

EDIT1: yanlış veri eklendi.

EDIT2: Flash Güvenlik (FSEC) kaydını belki okuyabilir misiniz? Denedin mi?

EDIT3: Kinetis Güvenlik ve Flaş Koruma Özelliklerini Kullanarak, Rev. 1, 6/2012

Hata ayıklayıcı / JTAG aracılığıyla toplu silme Hata ayıklayıcılar ve JTAG araçları, bir işlemci sabitlendiğinde aygıta çok sınırlı erişime sahiptir. JTAG üzerinden erişilebilen kayıtlar yalnızca MDM-AP Durum ve Kontrol kayıtlarıdır. Hata ayıklama araçlarının parçaları güvenli hale getirmesine izin vermek için MDM-AP Kontrol kaydının bit 0'ı işlemcinin toplu olarak silinmesini isteyecek şekilde ayarlanabilir. Güvenliği devre dışı bırakmak için bu yöntemi kullanmak amacıyla, toplu silme özelliğine izin vermek için FSEC [MEEN] değerinin 10 dışında bir değere ayarlanması gerekir. Toplu silme devre dışı bırakılmışsa, FSEC [MEEN] = 10 ise, toplu silme isteği flaş tarafından yok sayılır ve aygıt bu yöntem kullanılarak güvenli hale getirilemez. Birçok hata ayıklayıcı, bir bağlantı kurmaya çalışırken bir aygıtın güvenli olup olmadığını belirlemek için MDM-AP Durum kaydının 2. bitini otomatik olarak kullanır. Bir hata ayıklayıcı açılır penceresi, aygıtın sabitlendiğini uyarmak ve aygıtın güvenliğini kaldırmak için toplu silme istenip istenmediğini sormak için kullanılabilir. Toplu silme işlemi tamamlanıp doğrulandıktan sonra güvenlik devre dışı bırakılır. Bazı hata ayıklayıcılar, toplu silme işlemi tamamlandıktan sonra flaşı güvenli olmayan bir duruma getirmek için flaş yapılandırma alanını otomatik olarak programlayabilir, FSEC = 0xFE.

Ayrıca MDM-AP yazmacı okuma / yazma çalışırken farklı kinetis aileleri farklı RESET sinyal manipülasyonlar gerektiren bir mesaj tökezledi.

EDIT4: SWD_DIO'ya güçlü bir pull-up eklemeyi denediniz mi? Karanlıkta bir atış, ama Freescale bunu tavsiye ediyor.

Önce işlemciyi durdurmalısınız. Çalışan bir işlemcinin belirtisi olduğu açıktır. Ben openocd kullanıyorum; cihazı yanıp sönmeden önce "reset stop" komutunu kullanıyorum. Bu "durma", sıfırlamadan hemen sonra durdurmak için bir "sıfırlama" alt komutudur ve bağımsız bir durdurma komutu da vardır.

Bu yüzden bir "durmayı sıfırla" komutu arayın, sadece durma yeterli olmayacaktır çünkü sanırım vektörlerin ön başlatma durumuna geçmek zorundasınız.

Henüz bahsettiğim görmedim, bu yüzden devam edin ve sorunun bu bölümün sıfırlamada etkinleştirilen bir önbelleğe sahip olduğunu tahmin edeceğim. Bu, boş çekle gözlemlediğiniz "garip" davranışla tutarlıdır. Temel Flash güncellendi, ancak önbellek güncellenmedi. Bunu düzeltmek için MCM_PLACR, adresine yazarak hem veri hem de talimat önbelleğini kapatın F000_300Chve aynı zamanda önbelleği de temizleyin. Aynı garip davranışın Segger'i de karıştırması muhtemeldir.

Hata mesajı PC değeri ile ilgili olduğundan, CPU bir yerde raylardan çıkıyor gibi görünüyor. Bu uzun bir atış, ancak bekçi zamanlayıcısını devre dışı bırakmayı denediniz mi?