ko chạy được application code sau khi download

[namqn]

Nguyên văn bởi dvdsoul

Trả lời namqn:

1. mình bắt buộc viết 1 bootloader mới. Ko có kiến thức về assembly, lại fải viết thêm vài ứng dụng nhỏ dùng C nữa, nên mình xài MCC18.

2. Mình dùng Hyperterminal trên PC để download file xuống PIC

3. Sau khi download xong app code. Mình clear stack pointer và gọi lệnh goto <address của reset vector của app code>.

Tại đây con trỏ sẽ đọc instruction cũng là lệnh goto <address của app code> và sẽ nhảy đến fần _startup của app code. Tại đây mình nghĩ nó bị reset nên tiếp theo nó nhảy đến _startup của bootcode (mà ko thực thi gì trong đoạn app code)

Hiện mình mới đang thử test bootloader nên tạm thời đặt app code và bootloader code trong vùng nhớ nhỏ để dễ truy xuất và debug. Theo mình đc biết thì goto có thể nhảy đc trong vòng 64 kb cho 18F67J10 (hay 128kb nhỉ?? ) nên sau này sẽ đặt boot code gần cuối của program memory.

Cám ơn.

Bạn có thể đang gặp rắc rối với 3. Có cần phải xóa stack pointer không, nếu chương trình ứng dụng tự thiết lập stack? Nếu bạn dùng lệnh goto đến địa chỉ của reset vector của chương trình ứng dụng, có 2 khả năng xảy ra, cả hai khả năng này đều không ổn.

+ Khả năng thứ nhất, bạn không ghi đè reset vector của chương trình ứng dụng lên reset vector của bootloader (reset vector của bootloader và chương trình ứng dụng là giống nhau và đều là 0x000000). Khi đó, lệnh goto đến địa chỉ reset vector của chương trình ứng dụng sẽ sử dụng reset vector của bootloader, và như vậy bootloader sẽ chạy lại, chứ không phải chương trình ứng dụng được gọi.

+ Khả năng thứ hai, bạn ghi đè reset vector của chương trình ứng dụng lên reset vector của bootloader. Khi đó, lệnh goto đến địa chỉ reset vector của chương trình ứng dụng sẽ chạy chương trình ứng dụng, nhưng reset vector của bootloader đã bị hỏng, dẫn đến lần reset tiếp theo của phần cứng sẽ không thể kích hoạt bootloader, mà chạy thẳng chương trình ứng dụng.

Ở đây, vấn đề là bootloader phải được kích hoạt mỗi khi phần cứng được reset, và khi nạp chương trình ứng dụng vào flash của chip thì bootloader phải biết được địa chỉ bắt đầu của chương trình ứng dụng để lưu lại, sau đó sẽ chuyển điều khiển đến địa chỉ đó khi đã nạp xong chương trình ứng dụng vào flash. Theo nguyên tắc, địa chỉ bắt đầu của chương trình ứng dụng phải nằm trong 4 word đầu tiên của flash (tức là các địa chỉ 0x000000 - 0x000003), và nó là thành phần của một lệnh chuyển điều khiển như rcall, call, hay goto.

Với Tiny Bootloader, phần công việc xác định địa chỉ bắt đầu của chương trình ứng dụng được phần mềm trên host PC đảm nhiệm (thông qua việc đọc tập tin .hex của chương trình ứng dụng, và phân tích các lệnh nằm trong vùng địa chỉ 0x000000 - 0x000003), do đó firmware của Tiny Bootloader có thể được viết ở mức độ rất đơn giản, với giao thức giữa phần mềm trên host PC và firmware được quy ước ở mức độ tương đối thấp.

Với trường hợp của bạn, phần mềm trên host PC (Hyper Terminal) chỉ được dùng để truyền thông tin dạng ASCII đến bootloader, mọi công việc còn lại đều phải được hiện thực trong bootloader, từ việc phân tích tập tin .hex, xác định địa chỉ và giá trị của ô nhớ, đến việc xác định địa chỉ bắt đầu của chương trình ứng dụng cũng như bảo vệ vùng nhớ của bootloader khỏi việc bị ghi đè, ...

Theo tôi, cách tiếp cận của Claudiu là hiệu quả nhất, và bạn hoàn toàn có thể tự tin khi phát biểu rằng bootloader là do bạn tạo ra, ngay cả khi bạn chỉ sửa lại mã hợp ngữ của firmware để có thể chạy trên PIC18F67J10 với cấu hình của riêng bạn.

Nếu bạn vẫn muốn tiếp tục đi theo con đường hiện nay, bạn hãy tham khảo những gợi ý của tôi. Quan trọng nhất là xác định địa chỉ bắt đầu của chương trình ứng dụng, thông qua 4 từ lệnh của vùng 0x000000 - 0x000003 trong mã lệnh của chương trình ứng dụng, lưu địa chỉ đó lại, sau đó dùng lệnh goto đến địa chỉ đó, khi bootloader đã làm xong nhiệm vụ, chứ không nhảy đến reset vector của chương trình ứng dụng (tức là địa chỉ 0x000000).

Thân,