Freescale Kinetis KE - viết cho flash

Tôi đã sử dụng nhiều bộ vi điều khiển và bộ vi xử lý trong nhiều năm, nhưng dường như tôi bị cản trở bởi dòng Kinetis KE (cụ thể là S9KEAZN64AMLC).

Ngày 17 tháng 1 năm 2015 TL; DR:

Freescale xác nhận rằng v2.0.0 của phần mềm Kinetis Design Studio của họ không hoạt động với thiết bị này (bao gồm cả bảng eval TRK-KEA64 của riêng họ). Họ khuyên bạn nên sử dụng CodeWar Warrior MCU V10.6 trong thời điểm hiện tại.

Segger đã phát hành v4.96a ("a" rất quan trọng, tôi đã sử dụng v4.96) để khắc phục sự cố và cho phép bạn sử dụng bảng gỡ lỗi Segger J-Link Lite CortexM với KDS và có khả năng gỡ lỗi / chương trình đầy đủ.

Trước khi Segger phát hành v4.96a, tôi đã có thể flash chip bằng cách lập trình lại trình gỡ lỗi OpenSDA trên bảng eval FRDM-KL25Z rẻ tiền của Freescale bằng cách khởi động lại firmware OpenSDA đi kèm với USBDM (sử dụng v4.10.6.240). Sau đó tôi đã sử dụng phần mềm "Lập trình viên ARM" độc lập của USBDM. Tôi đã không dành nhiều thời gian để cố gắng để gỡ lỗi làm việc, vì tôi đủ thành thạo tại gỡ lỗi "oldschool" để không cần nó. Vui lòng đảm bảo rằng bạn flash chương trình "lành tính" vào mục tiêu trên tàu KL25 hoặc nó có thể gây trở ngại cho việc lập trình vì dòng đặt lại của mục tiêu trên tàu KL25 vẫn được kết nối với trình gỡ lỗi OpenSDA ngay cả khi bị cắt J11 (xem bài đăng trên blog của Keith Wakeham , liên kết dưới đây).

Xin chân thành cảm ơn Erich Styger vì đã giúp tôi xác định vấn đề và xác nhận những phát hiện của tôi qua email.

Bây giờ trở lại câu hỏi thường xuyên theo lịch trình của chúng tôi:

Tôi đã xây dựng một bảng đột phá 3.3V đơn giản ngu ngốc. Nó có một số đèn LED trên PTA, kết nối UART trên PTC và các đường SWD nằm trên các đường chuyên dụng của chúng. Thực sự không có gì lạ mắt hay hài hước về bảng này.

Tôi đang sử dụng J-Link Lite cho Cortex-M (J-Link LITE CortexM-9, xem https://www.segger.com/jlink-lite-cortexm.html ) và trong cả OSX và Windows tôi đều nhận được kết quả tương tự: tiện ích J-Link Commander có thể xác định chip, tôi có thể đọc và ghi vào SRAM và chơi xung quanh với các thiết bị ngoại vi bằng cách đọc thủ công và ghi vào địa chỉ I / O được ánh xạ bộ nhớ chính xác. Tuy nhiên, khi tôi cố gắng flash thiết bị, nó đã thất bại.

$ 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 hoàn toàn ổn (tôi có thể đọc và ghi vào nRF58122 SoC, một bộ xử lý Cortex-M0 khác, cùng với nó) và thiết bị dường như hoạt động. Tôi biết Kinetis được mở khóa vì chúng là nhà máy mới từ DigiKey, nhưng ngay cả khi đó lệnh "mở khóa kinetis" trong JLinkExe không có bất kỳ lỗi hay thông tin hữu ích nào.

Tại thời điểm này, tôi chắc chắn rằng mình đang làm điều gì đó ngu ngốc, nhưng tôi không biết nó có thể là gì.

Có ai đã làm việc với các thiết bị này trước đây? Bạn đang lập trình chúng như thế nào?

chỉnh sửa để thêm hướng dẫn:

Một số thông tin khác:

Tôi đọc rằng chân NMI # được bật khỏi thiết lập lại (và đã xác minh điều này bằng cách đọc SIM_SOPT) nhưng cũng có pin kéo lên bên trong khi được bật. Về phần đặc biệt này, PTB4 nằm ở chân 10, không có kết nối trong thiết kế của tôi. Vô hiệu hóa pin NMI không có sự khác biệt. RST # tương tự; Nó được kết nối với một nút bấm đặt chốt và cũng đi đến J-Link Lite nhưng không có pullup bên ngoài. Điều này không quan trọng vì giống như NMI #, chân RST # có một pullup bên trong được bật khi PTA5 được cấu hình để thiết lập lại.

Nhìn vào đồng hồ ngay bây giờ ... Hết thiết lập lại, ICS là nguồn đồng hồ cho FLL và BDIV trong ICS_C2 được đặt thành 001 (mặc định đặt lại). Nếu tôi hiểu chính xác, điều này có nghĩa là bộ dao động bên trong 32kHz được nhân với 1024 bởi FLL và sau đó chia cho 2, tạo ra ICSOUTCLK 32kHz * 1024/2 hoặc 16.8 MHz. Tôi có thể xác minh thông qua CLI J-Link rằng FLL bị khóa bằng cách đọc ICS_S:

J-Link>mem8 40064004 1
40064004 = 50

(LOCK và IREFST được đặt, điều này là chính xác.)

Sau đó tôi chuyển sang xác minh rằng SIM đã bật đồng hồ cho bộ điều khiển flash bằng cách đọc SIM_SCGC. Tôi cũng có thể nhanh chóng kiểm tra để đảm bảo rằng BUSDIV trong SIM_BUSDIV được đặt thành 0, điều đó có nghĩa là BusCLK có cùng tần số với ICSOUTCLK (nghĩa là nó không bị chia nhỏ):

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

Cho đến nay, mọi thứ đều ổn. BusCLK là 16,8 MHz và đồng hồ điều khiển flash không bị kiểm soát.

Bây giờ hãy chuyển sang bộ điều khiển flash. Hết thiết lập lại FCLKDIV bằng 0 và chúng ta cần xung nhịp 1 MHz. Bảng 18-2 trong KEA64RM cho thấy FDIV nên được đặt thành 0x10.

Hết cài đặt lại:

J-Link>mem8 40020000 1
40020000 = 00

Thiết lập dải phân cách và xác minh mọi thứ là tốt:

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

FDIVLD được đặt và giá trị chính xác trong FDIV được hiển thị.

Trước khi đi quá xa, hãy đảm bảo rằng đèn flash không được bảo vệ:

J-Link>mem8 40020001 1
40020001 = FE

KEYEN = 11 (bị vô hiệu hóa) và SEC = 10 (không bảo đảm). Đồng ý. Hãy thử xác minh thiết bị trống:

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

Ở đây chúng ta thấy rằng các bit MGSTAT trong FSTAT chỉ ra rằng kiểm tra trống đã thất bại và cũng tìm thấy các lỗi không thể sửa được. Lạ Hãy thử tự xóa nó đi:

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

Lệnh xóa tất cả đã thành công. Bây giờ hãy thử kiểm tra trống:

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

Bây giờ kiểm tra trống là tốt?

Tại thời điểm này, tôi đã sẵn sàng để từ bỏ, ăn mất những nguyên mẫu này và đi với bộ xử lý từ ST nơi tôi chưa bao giờ gặp phải những vấn đề này trước đây. Tài liệu Kinetis đủ kỹ lưỡng nhưng nó rất dày đặc và tôi thấy rất khó để bắt đầu. Tôi có thể ngọ nguậy I / O thông qua bộ nhớ đọc và truy cập các thiết bị ngoại vi khác nhưng tôi không thể tìm ra điều gì sai với bộ điều khiển flash. Tôi đã làm việc với micros trong hơn 20 năm và loại khó khăn này là điều mà tôi chưa bao giờ gặp phải trước đây.

20150102 chỉnh sửa:

Vì vậy, vẫn không đi đến đây. Tôi thực sự đã mua một bảng eval FRDM-KL25Z ($ 15 từ DigiKey) và sửa đổi nó bằng cách đưa phần mềm CMSIS-DAP chung vào trình gỡ lỗi OpenSDA và cắt J11 theo blog của Keith Wakeham . Tôi đã có mục tiêu trên tàu (KL25Z) đang chạy một chương trình đơn giản để nó không can thiệp vào dòng thiết lập lại và tôi có thể thấy SKEAZN64 của tôi với OpenOCD và chơi với nó, nhưng tiếc là nó cũng không thể lập trình được. Phần mềm Kinetis Design Studio (KDS) sẽ không flash Kinetis của tôi vì nó nói rằng nó được bảo vệ và tôi cần phải xóa hàng loạt, nhưng OpenOCD (như một phần của KDS) dường như không biết cách thực hiện. Phiên bản git master của OpenOCD mà tôi xây dựng trên máy Mac của mình hiểu Kinetis, nhưng không phải là dòng KEA cụ thể, vì vậy tôi quay lại hình vuông.

Quay trở lại J-Link ...

@AdamHaun có đầu mối thực sự tốt và nếu tôi đặt loại đặt lại J-Link (lệnh rsettype) thành loại '6' (Kinetis) thì J-Link có nghĩa vụ vô hiệu hóa bộ giám sát sau khi đặt lại lõi. Nhìn vào thanh ghi WDOG_CS1 (0x40052000), có vẻ như đó là trường hợp, nhưng vẫn không có xúc xắc. Một thao tác xóa dường như tắt đường ray với PC ở 0xfffffffe và mã lỗi -5 và lệnh "mở khóa kinetis" chỉ hoạt động nếu tôi vô hiệu hóa pin đặt lại bằng SIM_SOPT (bằng cách viết giá trị 32 bit 0x00000008 đến 0x40048004). Thật không may nếu tôi làm điều đó CPU không bao giờ có thể bị dừng lại một lần nữa, có lẽ vì giao diện SWD không thể sử dụng dòng thiết lập lại để buộc DAP SWD vào trạng thái đã biết.

20150103 chỉnh sửa:

Tôi có đèn LED

NÓI LẠI

Tôi có đèn LED

Phiên bản TL; DR: đặt hình ảnh USBDM trên bảng FRDM-KL25Z (một câu chuyện hoàn toàn riêng), sử dụng ứng dụng độc lập Lập trình viên ARM để gửi bản thử nghiệm lên bảng. Chu kỳ điện và voilà.

Phiên bản dài sẽ đến sau. Bây giờ tôi có ít hơn 48 giờ để viết và gỡ lỗi phần mềm cho bảng KEAZN64 này, hoàn tất sửa đổi / kiểm tra phần mềm khác đi kèm với nó và làm việc trên một số tài liệu cho một khách hàng khác. Tôi hứa tôi sẽ cập nhật câu hỏi này với một câu trả lời chi tiết. Tôi chỉ muốn chia sẻ thành công của tôi. Cảm ơn MỌI NGƯỜI đã giúp đỡ tôi. Tôi có thể phải nói chuyện với các mod vì tôi thực sự muốn đưa tiền thưởng cho một vài bạn nói riêng.

Tôi thực sự không thể tìm thấy bất kỳ lỗi logic nào trong quy trình của bạn, nhưng đây là một số gợi ý:

• cũng có một thanh ghi FTMRH_FERSTAT (tại 4002_0007h). Nó được cho là đã cho bạn biết những gì đã sai ... nhưng chỉ trong trường hợp tương đương (hoặc lỗi chẵn lẻ kép). Tôi không tin điều này sẽ ghi lại bất cứ điều gì trong trường hợp hoặc xóa lỗi, nhưng có lẽ đáng để kiểm tra.

• tài liệu KEA cũng đề cập rằng một ngắt có thể được kích hoạt bởi các lỗi flash (phần "18.3.5 Flash và EEPROM bị gián đoạn"). Tôi không biết liệu đó có phải là điều xảy ra khi SEGGER xóa nó hay không, nhưng đó là một lời giải thích hợp lý về lý do tại sao PC cũng thay đổi vì bạn đã thấy các lỗi được gắn cờ trong thanh ghi FSTAT. Thật không may, phần tài liệu KEA cho bộ điều khiển ngắt ("Cấu hình bộ điều khiển ngắt lồng nhau (NVIC)" 3.3.2 khá mơ hồ chỉ theo hướng trang web của ARM để có tài liệu đầy đủ. Tôi không thể tìm ra nếu có một trình xử lý ngắt mặc định được thiết lập (lúc khởi động) cho các lỗi flash.

• Bạn chỉ thực hiện xóa ở cấp ngành theo cách thủ công, vì vậy hãy thử thủ công (như bằng cách tự viết thanh ghi thích hợp) đưa ra lệnh xóa flash hoàn toàn; cách duy nhất để làm điều này trong một lệnh duy nhất dường như là "Lệnh flash không an toàn" được ghi lại trong phần 18.3.9.10 (tr. 246) của hướng dẫn. Điều này sẽ vừa "không bảo mật" thiết bị vừa thực hiện xóa flash hoàn toàn và xóa EEPROM. Bạn có thể thăm dò bit FSTAT (CCIF) để xem khi nào nó được hoàn thành và kiểm tra lại các cờ lỗi sau đó. EDIT: cũng có phần "Lệnh xóa tất cả các khối" 18.3.9.7 trong hướng dẫn, duh.

• thử tần số đồng hồ xe buýt thấp hơn. Bất cứ điều gì trên 0,8 Mhz hoạt động theo các tài liệu. Tôi đang đề xuất điều này bởi vì có một luồng trên diễn đàn Freescale nơi đèn flash ngoài hoạt động tốt, nhưng không vượt quá tần số nhất định vẫn nằm trong phạm vi tài liệu ok. Vì vậy, có thể bộ điều khiển flash trong chip không hoạt động và không thể hoạt động trên toàn dải tần số đã nêu.

• Tương tự như vậy, thy một chip khác. Không thể tưởng tượng được rằng với chi phí bao nhiêu (khoảng 3 đô la), bạn đã có một cái xấu. Tôi nhớ có một chip x86 nhúng hoạt động tốt trong hầu hết các cách nhưng có lỗi lạ trên các hướng dẫn chế độ được bảo vệ nhất định; vấn đề của tôi đã biến mất với một thiết bị khác cùng loại. Tôi không rõ ràng nếu Freescale có (tuyên bố công khai) các bước và lỗi cho các thiết bị này hay không.

Đây là tất cả những gì tôi có thể nghĩ về các đề xuất gỡ lỗi mà những người khác không nói trên trang này.

20150103 chỉnh sửa:

(Đã chuyển tài liệu ở đây từ nhận xét của tôi và mở rộng)

Có vẻ như không phải tất cả các dòng Kinetis (chính thức, ít nhất) được thử nghiệm với tất cả các đèn flash. Sê-ri EA khá mới mà bạn thực sự đang sử dụng dường như chỉ được hỗ trợ chính thức bởi flasher MAX / Cyclone MAX của Freescale; đó là người duy nhất được liệt kê trên trang của Freescale cho các serires EA . Hiện đã được cấp, đối với Kinetis cũ như KL0 , danh sách dài hơn nhiều, bao gồm cả SEGGER . Tôi không biết liệu đó có phải đơn giản chỉ vì thiếu thử nghiệm các đèn flash khác cho sê-ri EA hay thực sự có một số vấn đề lập trình liên quan đến việc chỉ có Cyclone MAX của họ hiện biết. Tôi đã hy vọng rằng có lẽ đây chỉ là Freescale chậm trong việc liệt kê các flashers khác, nhưng khi kiểm tra hướng dẫn sử dụng J-link (hy vọng là đúng), không có dòng Kinetis E hoặc EA nào được liệt kê ở đó (tr. 249) như đã được thử nghiệm, nhưng chỉ có các thiết bị Kinetis K10 đến K60 (và một số MAC7 cũ hơn).

Đáng chú ý là phần mềm / phần mềm PExDrv cho Cyclone MAX có gói dịch vụ (v10.3) ngày 3/20/2014, trong đó "Thêm hỗ trợ cho các dẫn xuất MKE04Z64, MKE04Z128, MKE06Z64, MKE06Z128, SKEAZ64 và SKEAZ64." Một manh mối khác là phần mềm bootloader / flashloader mã nguồn mở của Freescale dành cho Kinetis, mặc dù được cập nhật gần đây hơn vào tháng 12/2014, nhưng không liệt kê bất kỳ thiết bị dòng E hoặc EA [phụ] nào được hỗ trợ. Vì vậy, tôi nghĩ rằng có một cái gì đó đủ khác biệt liên quan đến việc nhấp nháy giữa dòng E / EA và Kinetis khác như K10, mặc dù tôi không biết chính xác sự khác biệt đó là gì. Do đó, tôi nghĩ rằng việc mong đợi EA flash tự động hoạt động với mọi thứ trừ Cyclone MAX có lẽ là không thực tế vào thời điểm này. Cuối cùng, bạn có thể tìm ra cách thực hiện ở mức "kim loại trần" (các lệnh đăng ký trực tiếp) từ tài liệu sê-ri EA, nhưng tôi đồng ý rằng tài liệu này khá khó hiểu; nó chắc chắn thiếu bất kỳ hướng dẫn từng bước chỉ là một hướng dẫn tham khảo. Có bộ tải khởi động / flashloader mã nguồn mở của Freescale hỗ trợ dòng E / EA không, bạn '

Thử nghiệm của bạn với FRDM-KL25Z (đi kèm với sê-ri Kinetis L) theo cùng một hướng, nghĩa là bạn không thể trao đổi sê-ri L với sê-ri EA và sử dụng cùng một flasher (OpenSDA trong trường hợp này).

Và nếu bạn giống như Keith (blogger), người "nghĩ rằng 100 đô la cho một lập trình viên là vô lý", có lẽ bạn sẽ không hài lòng với viễn cảnh giảm 900 đô la trên Cyclone đó. Tôi không biết liệu Freescale có làm điều này nhằm mục đích làm xấu khách hàng ô tô của họ hay không ... Có vẻ kỳ lạ là công cụ cho hầu hết các dòng Kinetis không hoạt động với E / EA.

Cũng cần lưu ý rằng rõ ràng chức năng nhấp nháy của OpenSDA chỉ hoạt động trong MS Windows .

Nếu bạn sẵn sàng thử (hack) nhiều bảng hơn, một bảng có Kinetis E-series có thể là một ý tưởng tốt hơn, ví dụ FRDM-KE02Z ($ 13 tại Digi-Key); cũng sử dụng OpenSDA để có thể hack được. Họ không tạo / bán bảng với EA-series, theo như tôi có thể nói. Tuy nhiên, có vẻ như bạn không thể sử dụng một bộ xử lý / bảng OpenSDA để lập trình một loại Kinetis khác với loại trên bảng của chính nó , ngay cả khi cả hai bộ xử lý nằm trong cùng một chuỗi (ví dụ L), nhưng các số khác nhau. Thật không may, "Mở" trong OpenSDA chỉ có nghĩa là thông số SDA là mở, chứ không phải họ đưa ra mã nguồn dưới dạng nguồn mở; vì vậy tôi thậm chí không thể tìm thấy mã nguồn để lập trình flash E-series. Rõ ràng, tôi chỉ đúng một nửa về điều đó. OpenSDA v1 không phải là nguồn mở, nhưng v2 là .

Vì vậy, đây là sự hạ thấp trên OpenSDAv2 . Về cơ bản, nó chỉ là một bộ tải khởi động & flasher CMSIS-DAP / mbed. Vì vậy, nó có thể không có các tính năng tương tự hoặc hỗ trợ các chip giống như v1 ... và thực tế đó là trường hợp vì flash_features.h không liệt kê bất kỳ MKE (Kinetis E-series) chứ đừng nói đến SKE (EA-series) thiết bị. Tóm lại, đề xuất của Freescale cho loạt EA dường như là: mua flasher Cyclone 900 đô la của chúng tôi hoặc chúc may mắn tự viết từ bất kỳ bit nào của nguồn mở mà chúng tôi đã phát hành.

Tuy nhiên, hóa ra có một dự án nguồn mở có thể lập trình ít nhất là Kinetis E-series, cụ thể là USBDM . Các bit có liên quan từ thay đổi của nó là:

V4.1.6.140 (tháng 4 năm 2014)

Các thiết bị Kinetis bổ sung (MKE04, MKE06, MK64F)

• Sửa lỗi cho các thiết bị MKE (không thể lập trình ngoại trừ sau khi xóa hàng loạt)

Và dựa trên mục nhật ký đó, chắc chắn xuất hiện dòng E là kỳ quặc. Không có hỗ trợ trực tiếp cho EA-series (SKE), nhưng cơ sở mã đó có lẽ là lựa chọn tốt nhất của bạn nếu bạn muốn hack flasher của riêng bạn; hoặc có lẽ bạn có thể thuyết phục tác giả của USBDM thêm hỗ trợ EA-series (SKE). Là phần cứng cho USBDM, hóa ra bạn có thể sử dụng FRDM-KL25Z mà bạn đã mua được; nhưng bạn vẫn phải hack phần mềm USBDM để hỗ trợ chip SKE.

Tệp cấu hình chính cho USBDM trông khá khó xử. Trong USDBM, các đèn flash khác nhau (cơ sở mã) được sử dụng cho các thiết bị dòng MKE khác nhau: thứ gọi là "FTMRE" được sử dụng cho MKE04 & MKE06, nhưng "FTMRH" được sử dụng cho MKE02. Sau khi nhìn sơ qua về hai cơ sở mã, bạn gần như chắc chắn muốn cơ sở mã FTRMH không phải là cơ sở mã FTRME. Cái sau có cấu trúc FTMRH khác với thiết bị SKEA64 của bạn, ví dụ, bộ chia đồng hồ không phải là trường đầu tiên mà là trường thứ 4. FTRME cũng đặt FIDV bus thành 0x17 = 24Mhz, có vẻ như nằm ngoài phạm vi cho chip của bạn (trang 224 trong hướng dẫn KEA64 gợi ý tối đa 20Mhz). FTMRH đặt nó thành 0x0F = 16Mhz (giống như bạn), có vẻ ổn.

Tại thời điểm này, (trừ khi bạn muốn mua Cyclone MAX), cách tốt nhất của bạn là liên hệ với Podonoghue để chip của bạn hoạt động với cơ sở mã của anh ấy. Anh ta có vẻ năng động và khá sẵn lòng giúp đỡ các thiết bị mới (trên diễn đàn freescale) .

Cũng từ mã nguồn USDBM đó, tôi có thể tiên đoán rằng không có cách nào SEGGER của bạn có thể tự flash chính xác SKEA của bạn trừ khi nó được cập nhật firmware trước. Tại sao tôi nói vậy? Bởi vì cơ sở mã FTMRH của USDBM được sử dụng bởi chính xác một thiết bị ở đó, MKE02, mà SEGGER của bạn dường như không biết gì về cả (dựa trên hướng dẫn sử dụng). Các thiết bị khác, phổ biến hơn như dòng Kinetis L và K sử dụng bộ flasher USDBM khác nhau dựa trên cơ sở mã "FTFA". Nếu bạn xem mã của FTFA , cấu trúc thanh ghi bộ điều khiển flash (cũng bắt đầu từ 0x40020000) sẽ khác với các mã này; trường đầu tiên thậm chí không phải là bộ chia đồng hồ, mà là thanh ghi stat, v.v ... Cách "tuyệt vời" để Freescale tạo ra các thiết bị không tương thích ... nhưng là một lợi ích cho các nhà sản xuất flasher, không còn nghi ngờ gì nữa.

Bạn đã thử điều này chưa: Mở khóa và xóa FLASH bằng Segger J-Link

Bị cáo buộc là bạn phải:

Để lập trình lại các khu vực FLASH được bảo vệ bằng Segger J-Link, trước tiên tôi cần mở khóa và xóa hàng loạt thiết bị. Đối với điều này, có tiện ích J-Link Commander có giao diện dòng lệnh để bảo vệ và xóa thiết bị. Chỉ để xóa, J-Flash (và Lite) là một công cụ rất hữu ích, đặc biệt là để có bộ nhớ thiết bị 'sạch'.

Điều tôi thấy thú vị là bạn phải mở khóa và xóa nó trong bước tiếp theo nếu bạn muốn mở khóa là vĩnh viễn:

Nhưng có vẻ như tôi cần phải mở khóa, sau đó là xóa để làm cho nó vĩnh viễn. Để xóa thiết bị, tôi có thể sử dụng tiện ích dòng lệnh tương tự. Nhưng tôi cần chỉ định tên thiết bị trước, sau đó tôi có thể xóa nó (ví dụ cho KL25Z):

EDIT1: thêm dữ liệu sai.

EDIT2: có lẽ bạn có thể đọc đăng ký Flash Security (FSEC) không? Bạn đã thử chưa?

EDIT3: từ việc sử dụng các tính năng bảo mật và bảo vệ flash của Kinetis, Rev. 1, 6/2012

Xóa hàng loạt thông qua Debugger / JTAG Debuggers và các công cụ JTAG có quyền truy cập rất hạn chế vào thiết bị khi bộ xử lý được bảo mật. Các thanh ghi duy nhất có thể được truy cập thông qua JTAG là các thanh ghi Điều khiển và Trạng thái MDM-AP. Để cho phép các công cụ gỡ lỗi thành các phần không an toàn, bit 0 của thanh ghi MDM-AP Control có thể được đặt để yêu cầu xóa hàng loạt bộ xử lý. Để sử dụng phương pháp này để vô hiệu hóa bảo mật, FSEC [MEEN] phải được đặt thành giá trị khác 10 để cho phép khả năng xóa hàng loạt. Nếu xóa khối lượng bị vô hiệu hóa, FSEC [MEEN] = 10, thì yêu cầu xóa khối sẽ bị bỏ qua bởi đèn flash và thiết bị không thể được bảo đảm bằng phương pháp này. Nhiều trình gỡ lỗi sẽ tự động sử dụng bit 2 của thanh ghi Trạng thái MDM-AP để xác định xem một thiết bị có được bảo mật khi cố gắng thiết lập kết nối hay không. Cửa sổ bật lên trình gỡ lỗi có thể được sử dụng để cảnh báo rằng thiết bị được bảo mật và hỏi xem có muốn xóa hàng loạt để bảo mật thiết bị không. Khi việc xóa hàng loạt được hoàn thành và xác minh, bảo mật sẽ bị vô hiệu hóa. Một số trình gỡ lỗi có thể tự động lập trình trường cấu hình flash để đưa đèn flash vào trạng thái không bảo mật sau khi quá trình xóa hàng loạt hoàn tất, FSEC = 0xFE.

Ngoài ra, tôi tình cờ thấy một bài viết đề cập đến các họ kinetis khác nhau đòi hỏi các thao tác tín hiệu RESET khác nhau khi cố gắng đọc / ghi thanh ghi MDM-AP.

EDIT4: bạn đã thử thêm một pull-up mạnh mẽ trên SWD_DIO chưa? Đó là một phát súng trong bóng tối, nhưng Freescale đề nghị nó.

Bạn phải tạm dừng bộ xử lý trước. Rõ ràng là bạn nhận được một triệu chứng của một bộ xử lý đang chạy. Tôi sử dụng openocd; trước khi flash thiết bị, tôi sử dụng lệnh "reset halt". "Tạm dừng" đó là một tiểu ban của "thiết lập lại", để tạm dừng ngay sau khi đặt lại, trong khi đó cũng có một lệnh tạm dừng độc lập.

Vì vậy, hãy tìm kiếm lệnh "thiết lập lại tạm dừng", chỉ cần dừng lại là không đủ vì bạn phải chuyển sang trạng thái khởi tạo trước các vectơ mà tôi đoán.

Tôi chưa thấy nó được đề cập, vì vậy tôi sẽ tiếp tục và suy đoán rằng vấn đề là phần này có bộ đệm được bật khi thiết lập lại. Điều này phù hợp với hành vi "kỳ lạ" mà bạn quan sát thấy với kiểm tra trống. Flash cơ bản đã được cập nhật nhưng bộ đệm thì không. Để khắc phục điều này, hãy tắt cả bộ đệm dữ liệu và hướng dẫn bằng cách ghi MCM_PLACRvào F000_300Chvà cũng xóa bộ đệm khi bạn làm như vậy. Hành vi kỳ lạ tương tự này cũng có khả năng đã làm Segger bối rối.

Vì thông báo lỗi là về giá trị PC, nên có vẻ như CPU ​​đang đi ra khỏi đường ray ở đâu đó. Đây là một cú sút xa, nhưng bạn đã thử vô hiệu hóa đồng hồ bấm giờ chưa?