Freescale Kinetis KE - menulis ke flash

Saya telah menggunakan berbagai mikrokontroler dan mikroprosesor selama bertahun-tahun sekarang, tetapi sepertinya saya terhalang oleh seri Kinetis KE (khususnya S9KEAZN64AMLC).

17 Jan 2015 TL; DR:

Freescale mengonfirmasi bahwa v2.0.0 dari perangkat lunak Kinetis Design Studio mereka tidak berfungsi dengan perangkat ini (termasuk papan eval TRK-KEA64 mereka sendiri). Mereka merekomendasikan untuk menggunakan CodeWarrior MCU V10.6 untuk sementara waktu.

Segger telah merilis v4.96a ("a" penting, saya menggunakan v4.96) yang memperbaiki masalah ini dan memungkinkan Anda untuk menggunakan papan debugger Segger J-Link Lite CortexM dengan KDS dan memiliki kemampuan program / debug penuh.

Sebelum Segger merilis v4.96a, saya berhasil mem-flash chip dengan memprogram ulang debugger OpenSDA pada papan eval FRDM-KL25Z ($ 15) murah Freescale dengan mem-reflashing firmware OpenSDA yang datang bersama dengan USBDM (menggunakan v4.10.6.240). Saya kemudian menggunakan perangkat lunak "ARM Programmer" mandiri USBDM. Saya tidak menghabiskan banyak waktu untuk mencoba debugging berfungsi, karena saya cukup mahir di debug "oldschool" untuk tidak membutuhkannya. Pastikan Anda mem-flash program "jinak" ke target KL25 on-board atau mungkin mengganggu pemrograman karena garis reset target on-board KL25 masih terhubung ke debugger OpenSDA bahkan dengan potongan J11 (lihat posting blog Keith Wakeham) , ditautkan di bawah).

Terima kasih banyak kepada Erich Styger karena telah dengan sangat murah hati membantu saya menentukan masalah dan mengkonfirmasi temuan saya melalui email.

Sekarang kembali ke pertanyaan terjadwal kami:

Saya telah membangun papan breakout 3.3V sederhana-bodoh. Ada beberapa LED di PTA, koneksi UART di PTC dan jalur SWD ada di jalur khusus mereka. Tidak ada yang mewah atau lucu tentang papan ini.

Saya menggunakan J-Link Lite untuk Cortex-M (J-Link LITE CortexM-9, lihat https://www.segger.com/jlink-lite-cortexm.html ) dan di bawah OSX dan Windows saya mendapatkan hasil yang sama: utilitas J-Link Commander dapat mengidentifikasi chip, saya dapat membaca dan menulis ke SRAM dan bermain-main dengan periferal dengan manual membaca dan menulis ke alamat I / O yang dipetakan dengan memori yang benar. Namun, ketika saya mencoba mem-flash perangkat, gagal.

$ 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 benar-benar baik-baik saja (saya dapat membaca dan menulis ke SoR nRF58122, prosesor Cortex-M0 lainnya, dengan itu) dan perangkat tampaknya bekerja sebaliknya. Saya tahu Kinetis tidak dikunci karena mereka adalah stok pabrik baru dari DigiKey, tetapi meskipun begitu perintah "kinetis terbuka" di JLinkExe habis tanpa kesalahan atau informasi yang berguna.

Pada titik ini saya yakin saya melakukan sesuatu yang bodoh, tetapi saya bingung apa yang bisa terjadi.

Adakah yang pernah menggunakan perangkat ini sebelumnya? Bagaimana Anda memprogramnya?

edit untuk menambahkan langkah-langkah:

Beberapa informasi lebih lanjut:

Saya membaca bahwa pin NMI # diaktifkan dari reset (dan memverifikasi ini dengan membaca SIM_SOPT) tetapi juga memiliki pin internal ketika diaktifkan. Pada bagian khusus ini PTB4 ada pada pin 10 yang tidak terhubung dalam desain saya. Menonaktifkan pin NMI tidak ada bedanya. RST # serupa; Terhubung ke tombol tekan yang menjadi dasar pin dan juga pergi ke J-Link Lite tetapi tidak ada pullup eksternal. Ini seharusnya tidak masalah karena seperti NMI #, pin RST # memiliki pullup internal yang diaktifkan ketika PTA5 dikonfigurasi untuk menjadi reset.

Melihat pencatatan jam kerja sekarang ... Di luar reset, ICS adalah sumber jam ke FLL dan BDIV di ICS_C2 diatur ke 001 (default reset). Jika saya mengerti dengan benar, ini berarti bahwa osilator internal 32kHz dikalikan dengan 1024 oleh FLL dan kemudian dibagi dengan 2, membuat ICSOUTCLK 32kHz * 1024/2 atau 16.8MHz. Saya dapat memverifikasi melalui J-Link CLI bahwa FLL dikunci dengan membaca ICS_S:

J-Link>mem8 40064004 1
40064004 = 50

(LOCK dan IREFST diatur, ini benar.)

Saya kemudian beralih untuk memverifikasi bahwa SIM mengaktifkan jam untuk pengontrol flash dengan membaca SIM_SCGC. Saya juga dapat dengan cepat memeriksa untuk memastikan bahwa BUSDIV di SIM_BUSDIV diatur ke nol yang berarti bahwa BUSCLK adalah frekuensi yang sama dengan ICSOUTCLK (yaitu tidak dibagi ke bawah):

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

Sejauh ini, semuanya terlihat baik-baik saja. BUSCLK adalah 16.8MHz dan jam pengontrol flash tidak terjaga keamanannya.

Sekarang mari kita beralih ke pengontrol flash. Out of reset FCLKDIV adalah nol, dan kami membutuhkan clock 1MHz. Tabel 18-2 dalam KEA64RM menunjukkan bahwa FDIV harus diatur ke 0x10.

Tidak diatur ulang:

J-Link>mem8 40020000 1
40020000 = 00

Menyiapkan pembagi dan memverifikasi hal-hal baik:

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

FDIVLD diatur dan nilai yang benar dalam FDIV ditampilkan.

Sebelum melangkah terlalu jauh, mari pastikan flash tidak terlindungi:

J-Link>mem8 40020001 1
40020001 = FE

KEYEN = 11 (dinonaktifkan) dan SEC = 10 (tidak aman). Baik. Mari kita coba memverifikasi perangkat kosong:

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

Di sini kita melihat bahwa bit MGSTAT di FSTAT menunjukkan bahwa pemeriksaan kosong telah gagal dan juga ditemukan kesalahan yang tidak dapat diperbaiki. Aneh. Mari kita coba menghapusnya sendiri:

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

Perintah hapus semua berhasil. Sekarang mari kita coba cek kosong:

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

Sekarang cek kosong baik-baik saja?

Pada titik ini saya hampir siap untuk menyerah, makan kerugian pada prototipe ini dan pergi dengan prosesor dari ST di mana saya belum pernah mengalami masalah seperti ini sebelumnya. Dokumentasi Kinetis cukup menyeluruh tetapi sangat padat dan saya merasa sangat sulit untuk memulai. Saya dapat menggoyangkan I / O melalui memori membaca dan mengakses periferal lain tetapi saya tidak bisa selama hidup saya mencari tahu apa yang salah dengan pengontrol flash. Saya telah bekerja dengan micros selama lebih dari 20 tahun dan kesulitan semacam ini adalah sesuatu yang belum pernah saya temui sebelumnya.

Sunting 20150102:

Jadi tetap tidak pergi ke sini. Saya sebenarnya telah membeli papan eva FRDM-KL25Z ($ 15 dari DigiKey) dan memodifikasinya dengan meletakkan perangkat lunak CMSIS-DAP generik pada OpenSDA debugger dan memotong J11 sesuai blog Keith Wakeham . Saya mempunyai target on-board (KL25Z) yang menjalankan program sederhana sehingga tidak mengganggu garis reset dan saya dapat melihat SKEAZN64 saya dengan OpenOCD dan bermain dengannya, tetapi sayangnya itu tidak dapat memprogramnya juga. Perangkat lunak Kinetis Design Studio (KDS) tidak akan mem-flash Kinetis saya karena dikatakan dilindungi dan saya perlu melakukan penghapusan massal, tetapi OpenOCD (sebagai bagian dari KDS) tampaknya tidak tahu bagaimana melakukan ini. Versi git master OpenOCD yang saya bangun di Mac saya mengerti Kinetis, tetapi bukan seri KEA tertentu, jadi saya kembali ke titik awal.

Kembali ke J-Link ...

@AdamHaun memiliki petunjuk yang sangat bagus, dan jika saya mengatur tipe reset J-Link (perintah rsettype) untuk mengetikkan '6' (Kinetis) J-Link seharusnya menonaktifkan watchdog setelah mengatur ulang core. Melihat register WDOG_CS1 (0x40052000) tampaknya memang demikian, tetapi masih belum ada dadu. Operasi hapus sepertinya keluar dari rel dengan PC pada 0xfffffffe dan kode kesalahan -5, dan perintah "membuka kinetis" hanya berfungsi jika saya menonaktifkan pin reset menggunakan SIM_SOPT (dengan menulis nilai 32-bit 0x00000008 ke 0x40048004). Sayangnya jika saya lakukan itu CPU tidak akan pernah bisa dihentikan lagi, mungkin karena antarmuka SWD tidak dapat menggunakan garis reset untuk memaksa SWD DAP ke keadaan yang diketahui.

Sunting 20150103:

Saya MEMILIKI LED berkedip

ULANG

Saya MEMILIKI LED berkedip

TL; versi DR: letakkan gambar USBDM di papan FRDM-KL25Z (sebuah cerita tersendiri), gunakan aplikasi mandiri ARM Programmer untuk mengirimkan tes .diri ke papan. Siklus daya dan voila.

Versi panjang akan datang nanti. Saya sekarang memiliki kurang dari 48 jam untuk menulis dan men-debug perangkat lunak untuk papan KEAZN64 ini, selesai memodifikasi / menguji perangkat lunak lain yang menyertainya, dan mengerjakan beberapa dokumentasi untuk klien lain. Saya berjanji akan memperbarui pertanyaan ini dengan jawaban terperinci. Saya hanya ingin membagikan kesuksesan saya. Terima kasih SEMUA ORANG atas bantuan Anda. Saya mungkin harus berbicara dengan mod karena saya benar-benar ingin memberikan hadiah kepada beberapa dari Anda khususnya.

Saya sebenarnya tidak dapat menemukan kesalahan logis dalam prosedur Anda, tetapi berikut adalah beberapa saran:

• ada juga register FTMRH_FERSTAT (pada 4002_0007h). Seharusnya memberi tahu Anda apa yang salah ... tetapi hanya dalam kasus paritas (atau kesalahan paritas ganda). Saya tidak yakin ini akan merekam apa pun jika ada atau menghapus kesalahan, tetapi mungkin perlu dicoba.

• dokumentasi KEA juga menyebutkan bahwa interupsi dapat dipicu oleh kesalahan flash (bagian "18.3.5 Flash dan EEPROM interupsi"). Saya tidak tahu apakah itu yang terjadi ketika SEGGER menghapusnya, tetapi ini adalah penjelasan yang masuk akal mengapa PC berubah juga karena Anda melihat kesalahan ditandai pada register FSTAT. Sayangnya bagian dokumentasi KEA untuk pengontrol interupsi ("konfigurasi 3.3.2 Nested Vectored Interrupt Controller (NVIC)") agak samar-samar menunjuk ke arah situs web ARM untuk dokumentasi lengkap. Saya tidak dapat mencari tahu apakah ada pengaturan interrupt handler default (saat boot) untuk kesalahan flash.

• Anda hanya melakukan penghapusan di tingkat sektor secara manual, jadi cobalah untuk secara manual (seperti dengan menulis daftar yang sesuai sendiri) mengeluarkan perintah penghapusan kilat penuh; satu-satunya cara untuk melakukan ini dalam satu perintah tampaknya adalah "Perintah flash tidak aman" yang didokumentasikan dalam bagian 18.3.9.10 (p. 246) dari manual. Ini akan "tidak aman" perangkat dan melakukan flash penuh dan menghapus EEPROM. Anda dapat polling bit FSTAT (CCIF) untuk melihat kapan itu seharusnya selesai dan memeriksa flag kesalahan lagi setelahnya. Sunting: ada juga bagian "18.3.9.7 Hapus Perintah Semua Blok" di manual, ya.

• coba frekuensi jam bus yang lebih rendah. Apa pun di atas 0,8 Mhz berfungsi sesuai dengan dokumentasi. Saya menyarankan ini karena ada satu utas di forum Freescale di mana flash eksternal berfungsi dengan baik, tetapi tidak di atas frekuensi tertentu yang masih dalam kisaran yang didokumentasikan dengan baik. Jadi mungkin saja pengontrol flash di chip serpihan dan tidak dapat beroperasi pada rentang frekuensi yang dinyatakan penuh.

• juga, chip Anda berbeda. Ini tidak masuk akal mengingat berapa banyak biaya ini (sekitar $ 3) Anda punya yang buruk. Saya ingat memiliki chip x86 tertanam yang bekerja dengan baik dalam banyak hal tetapi memiliki kesalahan aneh pada instruksi mode terlindungi tertentu; masalah saya hilang dengan perangkat berbeda dengan merek yang sama. Tidak jelas bagi saya apakah Freescale memiliki steppings dan errata untuk perangkat ini atau tidak.

Ini yang bisa saya pikirkan dalam hal saran debugging yang tidak dikatakan oleh orang lain di halaman ini.

Sunting 20150103:

(Pindah materi di sini dari komentar saya & diperluas)

Tampaknya tidak semua Seri Kinetis (secara resmi, setidaknya) diuji dengan semua flasher. Seri EA yang cukup baru yang benar-benar Anda gunakan tampaknya secara resmi hanya didukung oleh Freascale sendiri / OEM Cyclone MAX flasher; itu satu-satunya yang terdaftar di halaman Freescale untuk layanan EA . Sekarang diberikan, untuk Kinetis yang lebih tua seperti KL0 daftarnya jauh lebih lama, termasuk SEGGER . Saya tidak tahu apakah itu hanya karena kurangnya pengujian flasher lain untuk seri EA atau apakah sebenarnya ada beberapa kekhasan pemrograman yang terlibat yang hanya diketahui oleh Cyclone MAX mereka saat ini. Saya berharap mungkin ini hanya Freescale yang lambat dalam mendaftarkan flasher lain, tetapi setelah memeriksa manual J-link (mudah-mudahan yang benar), tidak ada seri Kinetis E atau EA yang terdaftar di sana (hlm. 249) yang diuji, tetapi hanya Kinetis K10 hingga perangkat K60 (dan beberapa MAC7 lama).

Patut dicatat bahwa perangkat lunak / firmware PExDrv untuk Cyclone MAX memiliki paket layanan (v10.3) tertanggal 3/20/2014, yang "Menambahkan dukungan untuk MKE04Z64, MKE04Z128, MKE06Z64, MKE06Z128, SKEAZ64 , dan SKEAZ128." Petunjuk lain adalah bahwa perangkat lunak open-source bootloader / flashloader milik Freescale untuk Kinetis, meskipun diperbarui lebih baru pada 12/2014, tidak mencantumkan perangkat seri E atau EA apa pun yang didukung. Jadi saya pikir ada sesuatu yang cukup berbeda mengenai flashing antara seri E / EA dan Kinetis lain seperti K10, meskipun saya tidak tahu apa sebenarnya perbedaan itu. Oleh karena itu saya berpikir bahwa mengharapkan EA flashing berfungsi secara otomatis dengan apa pun kecuali Cyclone MAX mungkin tidak realistis pada saat ini. Anda mungkin pada akhirnya dapat mengetahui bagaimana melakukannya pada level "bare metal" (perintah register langsung) dari dokumentasi EA-series, tetapi saya setuju bahwa dokumentasinya cukup bodoh; itu tentu saja tidak memiliki petunjuk langkah demi langkah yang hanya menjadi manual referensi. Seandainya open-source bootloader / flashloader Freescale mendukung seri E / EA, Anda

Eksperimen Anda dengan FRDM-KL25Z (yang dilengkapi dengan seri Kinetis L) menunjuk ke arah yang sama, yaitu Anda tidak dapat menukar seri-L dengan seri EA dan menggunakan flasher yang sama (OpenSDA dalam kasus ini).

Dan jika Anda seperti Keith (blogger) yang "berpikir $ 100 dolar untuk seorang programmer itu konyol", Anda mungkin tidak akan senang dengan perspektif menjatuhkan $ 900 + di Siklon itu. Saya tidak tahu apakah Freescale melakukan ini dengan sengaja untuk mengelabui pelanggan otomotif mereka atau apa ... Pasti terlihat aneh bahwa perkakas untuk sebagian besar seri Kinetis tidak bekerja dengan E / EA.

Berhati-hatilah juga bahwa fungsi flashing OpenSDA hanya berfungsi di bawah MS Windows .

Jika Anda ingin mencoba (meretas) lebih banyak papan, papan dengan E-series Kinetis mungkin ide yang lebih baik, misalnya FRDM-KE02Z ($ 13 di Digi-Key); juga menggunakan OpenSDA sehingga mungkin bisa diretas. Mereka tidak membuat / menjual papan dengan seri-EA, sejauh yang saya tahu. Namun, tampaknya Anda tidak dapat menggunakan satu prosesor / papan OpenSDA untuk memprogram jenis Kinetis yang berbeda dari yang ada di papannya sendiri , bahkan jika kedua prosesor tersebut dalam seri yang sama (misalnya L), tetapi jumlahnya berbeda. Sayangnya "Open" di OpenSDA hanya berarti spec SDA terbuka, bukannya mereka memberikan kode sumber sebagai open-source; jadi saya bahkan tidak dapat menemukan kode sumber untuk memprogram flash E-series. Rupanya, saya hanya setengah benar tentang itu. OpenSDA v1 bukan open-source, tetapi v2 adalah .

Jadi, inilah lowdown pada OpenSDAv2 . Ini pada dasarnya hanya CMSIS-DAP / booted booter & flasher. Jadi mungkin tidak memiliki fitur yang sama atau mendukung chip yang sama dengan v1 ... dan itu ternyata menjadi sebab flash_features.h tidak mencantumkan MKE (Kinetis E-series) apalagi SKE (EA-series) perangkat. Ringkasnya, proposisi Freescale untuk seri EA tampaknya adalah: beli flasher Siklon seharga $ 900 atau semoga sukses menulis sendiri dari bit open source apa pun yang telah kami rilis.

Namun ternyata ada proyek open source yang dapat memprogram setidaknya E-series Kinetis, yaitu USBDM . Bit yang relevan dari changelog-nya adalah:

V4.1.6.140 (April 2014)

Perangkat Kinetis tambahan (MKE04, MKE06, MK64F)

• Perbaikan untuk perangkat MKE (gagal diprogram kecuali setelah Mass Erase)

Dan berdasarkan entri log itu, tampaknya seri-E unik. Tidak ada dukungan langsung untuk EA-series (SKE), tetapi basis kode itu mungkin pilihan terbaik Anda jika Anda ingin meretas flasher Anda sendiri; atau mungkin Anda dapat meyakinkan penulis USBDM untuk menambahkan dukungan EA-series (SKE). Sebagai perangkat keras untuk USBDM ternyata Anda dapat menggunakan FRDM-KL25Z yang telah Anda peroleh sebelumnya; tetapi Anda masih harus meretas perangkat lunak USBDM untuk mendukung chip SKE.

The Master file konfigurasi untuk USBDM tampak agak menakutkan. Dalam USDBM, flasher yang berbeda (basis kode) digunakan untuk perangkat seri MKE yang berbeda: sesuatu yang disebut "FTMRE" digunakan untuk MKE04 & MKE06, tetapi "FTMRH" digunakan untuk MKE02. Setelah melihat diri saya secara singkat di dua basis kode, Anda hampir pasti menginginkan basis kode FTRMH bukan yang FTRME. Yang terakhir memiliki struktur FTMRH yang berbeda dari perangkat SKEA64 Anda, misalnya, pembagi jam bukan yang pertama tetapi bidang ke-4. FTRME juga mengatur bus FIDV ke 0x17 = 24Mhz, yang tampaknya di luar jangkauan chip Anda (hlm. 224 dalam manual KEA64 menyarankan maks 20Mhz). FTMRH menetapkannya ke 0x0F = 16Mhz (seperti yang Anda lakukan), yang sepertinya baik-baik saja.

Pada titik ini, (kecuali jika Anda ingin membeli Cyclone MAX), taruhan terbaik Anda adalah menghubungi Podonoghue agar chip Anda bekerja dengan basis kodenya. Dia tampak aktif dan sangat bersedia membantu dengan perangkat baru (di forum freescale) .

Dari kode sumber USDBM itu saya bisa menubuatkan bahwa tidak mungkin SEGGER Anda dapat mem-flash SKEA Anda dengan sendirinya kecuali jika mendapat pembaruan firmware sendiri terlebih dahulu. Mengapa saya mengatakan itu? Karena basis kode FTMRH USDBM digunakan oleh tepat satu perangkat di sana, MKE02, yang sepertinya SEGGER Anda tidak tahu apa-apa tentang keduanya (berdasarkan manualnya). Lainnya, perangkat yang lebih umum seperti seri Kinetis L dan K menggunakan flasher USDBM yang berbeda berdasarkan pada basis kode "FTFA". Jika Anda melihat kode FTFA , struktur register pengontrol flash (juga mulai dari 0x40020000) berbeda untuk ini; bidang pertama bahkan bukan pembagi jam, tetapi register stat, dll. Cara yang bagus bagi Freescale untuk membuat perangkat yang tidak kompatibel ... tetapi anugerah bagi pembuat flasher, tidak diragukan lagi.

Apakah Anda mencoba ini: Membuka dan Menghapus FLASH dengan Segger J-Link

Diduga Anda harus:

Untuk memprogram ulang sektor FLASH yang dilindungi dengan Segger J-Link, saya harus terlebih dahulu membuka kunci dan menghapus perangkat secara massal. Untuk ini, ada utilitas J-Link Commander yang memiliki antarmuka baris perintah untuk melindungi dan menghapus perangkat. Untuk menghapus saja, J-Flash (dan Lite) adalah alat yang sangat berguna, terutama untuk mendapatkan memori perangkat 'bersih'.

Yang saya temukan menarik adalah Anda harus membuka kuncinya dan menghapusnya di langkah berikutnya jika Anda ingin kuncinya menjadi permanen:

Tapi sepertinya saya perlu melakukan unlock, diikuti dengan erase agar permanen. Untuk menghapus perangkat, saya dapat menggunakan utilitas baris perintah yang sama. Tetapi saya harus menentukan nama perangkat terlebih dahulu, dan kemudian saya dapat menghapusnya (contoh untuk KL25Z):

EDIT1: menambahkan data yang salah.

EDIT2: bisakah Anda membaca register Flash Security (FSEC)? Apakah kamu sudah mencoba?

EDIT3: dari Menggunakan Fitur Keamanan Kinetis dan Flash, Rev. 1, 6/2012

Penghapusan masal melalui Debugger / JTAG Alat debugger dan JTAG memiliki akses yang sangat terbatas ke perangkat saat prosesor diamankan. Satu-satunya register yang dapat diakses melalui JTAG adalah register Status dan Kontrol MDM-AP. Untuk memungkinkan alat debug untuk menghapus komponen, bit 0 dari register Kontrol MDM-AP dapat diatur untuk meminta penghapusan massal prosesor. Untuk menggunakan metode ini untuk menonaktifkan keamanan, FSEC [MEEN] harus diatur ke nilai selain 10 untuk memungkinkan kemampuan penghapusan massal. Jika penghapusan massal dinonaktifkan, FSEC [MEEN] = 10, maka permintaan penghapusan massal akan diabaikan oleh blitz dan perangkat tidak dapat tidak aman menggunakan metode ini. Banyak debugger akan secara otomatis menggunakan bit 2 dari register Status MDM-AP untuk menentukan apakah suatu perangkat diamankan ketika mencoba untuk membuat koneksi. Jendela pop-up debugger mungkin digunakan untuk mengingatkan bahwa perangkat diamankan dan menanyakan apakah penghapusan massal diinginkan untuk tidak mengamankan perangkat. Setelah penghapusan massal selesai dan diverifikasi, keamanan akan dinonaktifkan. Beberapa debugger mungkin secara otomatis memprogram bidang konfigurasi flash untuk menempatkan flash ke keadaan tidak aman setelah penghapusan massal selesai, FSEC = 0xFE.

Saya juga menemukan tulisan yang menyebutkan keluarga kinetis yang berbeda membutuhkan manipulasi sinyal RESET yang berbeda ketika mencoba membaca / menulis register MDM-AP.

EDIT4: apakah Anda mencoba menambahkan pull-up yang kuat di SWD_DIO? Ini tembakan dalam gelap, tapi Freescale merekomendasikannya.

Anda harus menghentikan prosesor terlebih dahulu. Jelas bahwa Anda mendapatkan gejala dari prosesor yang berjalan. Saya menggunakan openocd; sebelum menginstal perangkat saya menggunakan perintah "reset halt". Itu "berhenti" adalah sub-perintah "reset", untuk berhenti segera setelah reset, sementara ada juga perintah berhenti mandiri.

Jadi mencari perintah "reset berhenti", berhenti saja tidak akan cukup karena Anda harus mendapatkan pra-inisialisasi vektor, saya kira.

Saya belum melihatnya disebutkan, jadi saya akan melanjutkan dan berspekulasi bahwa masalahnya adalah bagian ini memiliki cache yang diaktifkan saat reset. Ini konsisten dengan perilaku "aneh" yang Anda amati dengan cek kosong. Flash yang mendasarinya telah diperbarui tetapi cache tidak. Untuk memperbaikinya, matikan cache data dan instruksi dengan menulis MCM_PLACRdi F000_300Chdan juga menghapus cache saat Anda melakukannya. Perilaku aneh yang sama ini kemungkinan telah membingungkan Segger juga.

Karena pesan kesalahan adalah tentang nilai PC, sepertinya CPU keluar dari rel di suatu tempat. Ini kemungkinan besar, tetapi apakah Anda sudah mencoba menonaktifkan pengawas waktu?