December 5, 2021

Blogna Kang U-2 Man

STM32, Embedded System, Microcontroller, ARM Cortex-M, RTOS, FreeRTOS

ARM Cortex-M3: Model Eksepsi

8 min read

بِسْمِ اللَّهِ الرَّحْمَنِ الرَّحِيم

Dalam pemrograman eksepsi (exception) bisa diartikan sebagai kejadian (event) yang mengganggu alur normal sebuah program, yang diakibatkan terjadinya kesalahan saat program dijalankan (run time error). Misalnya sebuah program pembagian 2 buah bilangan bulat, ketika pembaginya bernilai nol , maka akan terjadi eksepsi divide by zero. Pada saat ini, jika tidak ada fungsi untuk menanganinya (exception handler), maka sistem operasi komputerlah yang akan menanganinya, misalnya dengan menampilkan pesan kesalahan pada monitor.

Pada mikrokontroler, program yang harus dijalankan dibaca dari memori program (memori flash). Alamat memori program yang harus dibaca disimpan di register PC. Selama alur normal, PC akan dinaikan secara beraturan. Kecuali ketika program harus memanggil atau melompat ke sebuah fungsi atau sub-rutin, maka isi dari PC akan diubah menjadi alamat dari fungsi tersebut. Perubahan ini secara “sadar” dilakukan oleh program, artinya di program tertera jelas kapan dan di mana proses ini dilakukan. Ada juga proses pengubahan alur program yang bisa terjadi secara tiba-tiba dan dipicu oleh hardware atau periperal internal. Inilah yang dinamakan interupsi. Pada saat terjadi interupsi, program akan melompat ke sebuah sub-rutin yang dinamakan dengan ISR (Interrupt Service Routine). Walaupun demikian, sebuah interupsi tetap harus diinisialisasi di awal program, periperal mana saja yang akan menginterupsi CPU. Interupsi adalah salah satu jenis eksepsi.

ARM Cortex-M3 mengenal 3 jenis eksepsi:

  1. Eksepsi karena interupsi yang dibangkitkan oleh periperal internal, dinamakan dengan IRQ (Interrupt Request). Penanganannya dilakukan oleh ISR.
  2. Eksepsi yang dibangkitkan oleh kesalahan (fault). Eksepsi ini dibangkitkan oleh kesalahan saat akses memori, kesalahan di sistem bus, atau kesalahan instruksi. Penanganannya dilakukan oleh fault handler.
  3. Eksepsi sistem, yang dibangkitkan oleh Non-Maskable Interrupt (NMI) atau software yang berhubungan dengan sistem operasi. Fungsi penanganannya dinamakan system handler.

ARM Cortex-M3 mempunyai eksepsi kesalahan dan eksepsi sistem dari nomor 1-15 sedangkan interupsi eksternal dimulai dari nomor 16. Level prioritas dari eksepsi ada yang bisa diprogram ada juga yang tidak, sedangkan semua interupsi eksternal prioritasnya bisa diprogram. ARM Cortex-M3 bisa dilengkapi dengan interupsi eksternal dari 1-240, tergantung kepada pembuat SoC dan untuk keperluan apa prosesor diproduksi. Reset merupakan eksepsi yang terjadi saat pertama catu daya dinyalakan (power up) atau dengan memberi sinyal ke pin reset ketika program sedang berjalan (warm reset). Sedangkan NMI bisa dipicu oleh periperal atau software, dan secara permanen selalu aktif dengan prioritas yang tetap.

Eksepsi dan Interupsi ARM Cortex-M3

HARD FAULT

Hard fault merupakan eksepsi yang terjadi ketika prosesor tidak bisa mengeksekusi fungsi handler dari eksepsi yang lain (MemManage fault, Usage fault, dan Bus fault), bisa karena fungsi handler tidak didefinisikan atau eksepsinya tidak diaktifkan. HardFault mempunyai prioritas tertinggi setelah reset dan NMI.

Oleh karena Hard fault bisa dipicu oleh eksepsi yang lain, maka untuk mengetahui eksepsi mana yang sebenarnya memicu Hardfault bisa diketahui dari register status Hard fault (HFSR = Hard Fault Status Register) yang beralamat di 0xE000ED2C. Seperti yang ditunjukan oleh tabel di bawah.

Register HFSR

MEMMANAGE FAULT

MemManage (Memory Management) fault, bisa dipicu karena adanya kesalahan yang berhubungan dengan MPU atau adanya akses ilegal terhadap memori (misalnya mengeksekusi kode dari area memori yang tidak bisa dieksekusi). Kemungkinan-kemungkinan yang bisa memicu eksepsi MemManage yang berhubungan dengan MPU, misalnya:

  1. Akses ke area memori yang tidak didefinisikan oleh MPU
  2. Menulis ke area yang hanya bisa dibaca
  3. Akses dari mode user ke area memori yang hanya bisa diakses saat mode privileged

Ketika terjadi MemManage Fault, dan fungsi penanganannya diaktifkan, maka prosesor akan memanggil fungsi tersebut, sedangkan jika tidak prosesor akan membangkitkan eksepsi Hard Fault dan akan men-set bit FORCED (bit ke-30) register HFSR. Level prioritas MemManage fault ini bisa di set. Level prioritas ini berguna karena ARM Cortex-M3, seperti yang akan dijelaskan, mengenal interupsi/eksepsi bersarang (nested). Ketika terjadi sebuah interupsi/eksepsi, maka prosesor Cortex-M3 akan mengecek dan membandingkan level interupsi ini, ketika pada saat terjadinya eksepsi ada eksepsi lain yang sedang dikerjakan dengan level interupsi yang sama atau lebih tinggi, maka eksepsi yang baru terjadi tersebut akan ditunda terlebih dahulu. Tetapi jika level prioritas eksepsi yang sedang terjadi lebih rendah,  maka prosesor akan menghentikan dulu proses eksepsi tersebut dan mengerjakan eksepsi yang baru terjadi.

Eksepsi MemManage fault diaktifkan melalui bit MEMFAULTENA (bit ke-16) di register SHCSR (System Handler Control and State Register). Register SHCSR juga mengendalikan pengaktifan dari eksepsi-eksepsi yang lain, kecuali Hard fault. SHCSR beralamat di 0xE000ED24.

Bit-bit dengan nama berakhiran ENA, merupakan bit untuk mengaktifkan atau mematikan eksepsi (ENAble), jika bit di-set (bernilai 1) maka eksepsi aktif, jika di-clear (bernilai 0) eksepsi tidak aktif. Bit-bit yang berakhiran PENDED merupakan bit-bit yang menunjukan bahwa eksepsi tersebut sedang ditunda (pending). Sedangkan bit-bit yang berakhiran ACT, menunjukan bahwa eksepsi sedang dalam kondisi aktif jika bernilai 1 (di-set).

Kondisi atau penyebab dari eksepsi MemManage ditunjukan oleh register MMFSR (Memory Management Fault Status Register). MMFSR merupakan bagian dari register CFSR (Configurable Fault Status Register). Isi dari register MMFSR ditunjukan oleh tabel di bawah.

Register CFSR

Ketika terjadi eksepsi MemManage fault, penyebab utamanya bisa dilihat di bit MSTKERR, MUSTKERR, DACCVILO atau IACCVIOL yang menunjukan apakah eksepsi disebabkan saat proses di memori stack (stacking atau unstacking), saat akses ke memori data atau kesalahan saat akses ke instruksi. Jika bit MMARVALID di-set, maka lokasi memori yang menyebabkan eksepsi ini bisa dilihat di register MMAR (Memory Management Address Register).

Register MMFSR

BUS FAULT

Bus fault bisa terjadi ketika ada kesalahan atau error saat terjadi transfer di antarmuka AHB, baik saat pengambilan instruksi, yang disebut prefetch abort atau saat baca/tulis di memori data yang disebut data abort. Bus fault juga bisa terjadi saat proses penyimpanan (PUSH) atau pengambilan (POP) data ke dan dari memori stack di awal dan akhir interupsi. Kejadian ini juga dinamakan dengan stacking dan unstacking error. Ketika eksepsi ini terjadi dan fungsi penanganannya diaktifkan, maka prosesor akan mengerjakan fungsi tersebut, tentunya dengan melihat level prioritasnya. Sedangkan jika tidak diaktifkan, prosesor akan membangkitkan eksepsi Hard fault.

Bus fault diaktifkan dengan men-set bit BUSFAULTENA di register SHCSR. Sedangkan statusnya bisa dilihat di  register BFSR. Eksepsi Bus fault saat akses data dikategorikan menjadi dua, yaitu precise dan imprecise. Eksepsi Bus fault Impricise terjadi jika eksepsi disebabkan oleh suatu operasi yang dikerjakan (seperti penulisan terbufer) beberapa siklus clock sebelumnya. Sedangkan Bus fault precise disebabkan oleh operasi terakhir yang sudah dikerjakan, misalnya pembacaan memori di sebut precise karena instruksi tidak bisa selesai sampai menerima data.

Register BFSR

USAGE FAULT

Usage fault berkaitan dengan eksepsi yang terjadi karena eksekusi sebuah instruksi. Beberapa hal penyebabnya sebagai berikut:

  1. Ketika prosesor menjalankan instruksi yang tidak terdefinisi.
  2. Ketika prosesor mencoba menjalankan instruksi untuk coprosesor, padahal ARM Cortex-M3 tidak mendukung coprosesor.
  3. Ketika menjalankan instruksi yang mencoba mengganti ke instruksi ARM (ARM State), padahal ARM Cortex-M3 tidak mendukung instruksi ARM.
  4. Kesalahan di alamat kembali setelah terjadinya interupsi, dalam hal ini register Link (R14) berisi nilai yang tidak benar.
  5. Kesalahan saat mengakses memori tak rata (unaligned).

Seperti eksepsi-eksepsi sebelumnya, eksepsi Usage fault juga harus diaktifkan melalui bit USGFAULTENA di register SHCSR. Jika tidak, maka ketika terjadi Usage fault, prosesor akan membangkitkan eksepsi Hard fault. Status dari Usage fault bisa dilihat di register UFSR (Usage Fault Status Register) yang bisa diakses di alamat 0xE000ED28 secara 32 bit (word) atau 0xE000ED2A secara 16 bit (half word).

Register UFSR

SVC, PENDSV, DAN SYSTICK

Selain eksepsi yang dipicu oleh adanya kesalahan (fault), ARM Cortex-M3 mengenal juga eksepsi yang dibangkitkan secara software, terutama ketika ARM Cortex menjalankan sebuah RTOS. Ada 3 jenis eksepsi ini, yaitu:

  1. SVC (Supervisor Call)
  2. PendSV (Pendable Service Call)
  3. SysTick

SVC (Supervisor Call) dan PendSV (Pendable Sevice Call) merupakan eksepsi yang dibangkitkan secara software. SVC dibangkitkan dengan memanggil instruksi SVC, sedangkan PendSV dibangkitkan dengan menset bit PENDSVSET di register ICSR (Interrupt Control and State Register). Systick merupakan eksepsi yang dibangkitkan ketika timer SysTick (System Tick), yang merupakan timer 24 bit,  menghitung mundur mencapai nol. Ketiga eksepsi ini digunakan menjalankan sebuah kernel sistem operasi (RTOS). Dalam sistem berbasis RTOS, setiap task akan dijalankan secara bergantian dalam waktu tertentu, dan ini diatur oleh kernel OS atau scheduler sehingga sistem terlihat seperti multi-tasking. Pergantian antar task dinamakan dengan pergantian konteks (context switching), dan ketiga eksepsi ini digunakan dalam pergantian konteks tersebut.

Eksepsi SVC juga bisa digunakan apabila dalam sebuah sistem berbasis RTOS, setiap task atau fungsi tidak diijinkan mengakses hardware atau periperal internal secara langsung, tetapi harus melaui kernel (OS), kernel-lah yang kemudian menghubungkannya ke hardware melalui fungsi ke hardware tersebut (device driver). Hal ini bisa dilakukan ketika akan mengakses hardware tersebut, task akan memanggil instruksi SVC dan fungsi penanganan yang ada dalam RTOS (SVC handler) kemudian menghubungkannya ke hardware.

Pergantian Konteks dalam RTOS

Gambar di atas menggambarkan bagaimana sebuah pergantian konteks atau pergantian task dari Task A ke Task B dan seterusnya dilakukan setiap terjadi eksepsi SYSTICK. Masalah akan terjadi ketika akan terjadi pergantian konteks, terjadi interupsi dari periperal internal, misalnya dari port serial.Pelayanan terhadap  permintaan interupsi tersebut akan tertunda karena didahului oleh pergantian konteks tersebut. Atau bisa saja interupsi yang didahulukan dan pergantian konteks yang ditunda, tetapi ARM Cortex-M3 akan membangkitkan eksepsi Usage fault ketika OS berusaha berganti ke mode thread ketika sebuah interupsi sedang aktif.

Interupsi terjad sesaat sebelum pergantian konteks

Permasalahan di atas bisa diatasi dengan cara OS akan melakukan pergantian konteks ketika tidak sedang mengeksekusi pelayanan interupsi (ISR). Namun akan berakibat adanya waktu tunda yang panjang saat pergantian task terutama ketika interupsi sering terjadi berdekatan dengan saat pergantian task. PendSV bisa mengatasi hal ini. PendSV, sesuai namanya Pendable Service Call, akan menunda permintaan pergantian konteks sampai semua fungsi pelayanan interupsi selesai dikerjakan.

Pergantian Konteks dengan PendSV

Sebuah interupsi terjadi sesaat sebelum pergantian konteks. Pelayanan interupsi tersebut akan ditunda terlebih dahulu untuk mengerjakan eksepsi SYSTICK. Dengan instruksi PendSV, setelah SYSTICK selesai OS tidak langsung mengerjakan pergantian konteks, dari Task B ke Task A, tetapi melanjutkan dulu pelayanan interupsi yang tadi tertunda. Setelah interupsi selesai dilayani, pergantian konteks sesungguhnya akan dilakukan, dan ini tidak akan membangkitkan eksepsi Usage fault. Oleh karena itu, PendSV lebih umum digunakan dalam pergantian konteks sebuah OS.

TABEL VEKTOR

Ketika terjadi sebuah eksepsi, prosesor ARM Cortex-M3 memerlukan informasi tentang awal dari fungsi pelayanan eksepsi tersebut. Informasi ini disimpan dalam sebuah tabel vektor di dalam memori. Setelah reset tabel vektor berada di alamat offset 0x0000 yang merupakan nilai awal dari penunjuk stack. Alamat selanjutnya adalah alamat awal dari fungsi pelayanan eksepsi atau interupsi eksternal (periperal) yang diatur dan diurutkan menurut nomor eksepsi dikalikan 4, seperti ditunjukan oleh gambar di bawah. Di namakan alamat offset karena alamat sebenarnya mengacu kepada alamat dari memori flash atau RAM di mana kode atau program disimpan, tentunya area memori yang merupakan area yang bisa dieksekusi (boot code).

Tabel Vektor

Tabel vektor bisa dipindahkan ke area atau alamat lain saat program berjalan. Hal ini bisa dilakukan dengan mengubah isi register VTOR (Vector Table Offset Register). Offset alamat harus disesuaikan dengan ukuran vektor tabel (jumlah eksepsi), dan harus ditambah sehingga jumlah eksepsinya menjadi bilangan dalam deret bilangan pangkat 2. Misalnya sebuah prosesor mempunyai 32 sumber interupsi dari periperal (IRQ), maka jumlah eksepsi adalah 32+16 (eksepsi sistem dan fault) = 48. Bilangan pangkat 2 terdekat yang lebih besar dari pada 48 adalah 64, maka perpanjangan jumlah eksepsinya menjadi 64. Dengan ketentuan tiap offset harus ada jarak 4 byte, maka ukuran tabel menjadi 64×4 = 256 byte (0x100). Sehingga tabel vektor bisa diprogram di alamat dengan kelipatan 0x100 yaitu 0x0, 0x100, 0x200 dan seterusnya.

Perubahan tabel vektor ini berguna ketika mengembangkan aplikasi boot loader atau In-System Application Programming (IAP). Umumnya ada 3 cara untuk memprogram memori flash mikrokontroler, melalui jalur In-System Programming (ISP) lewat port debug (JTAG atau SWD), melalui boot loader yang sudah ditanam dari manufaktur (biasanya melalui port serial), atau boot loader yang dibuat sendiri (IAP). Dalam IAP, program bisa dimasukan melalui jalur komunikasi yang tersedia, paralel (GPIO), uart, I2C, SPI, USB, Ethernet dan lain-lain.

Dalam IAP, area memori flash akan dibagi menjadi 2 yaitu program IAP dan program aplikasi. Baik program IAP maupun program aplikasi mempunyai tabel vektor masing-masing. Tabel vektor IAP tetap di alamat offset 0x0, sedangkan vektor aplikasi disesuaikan dengan besarnya ukuran program IAP dan ketentuan di atas. Pergantian tabel vektor, mengubah register VTOR harus dilakukan dalam program aplikasi dan saat proses build alamat awal memori flash juga harus disesuaikan.

Pemetaan Memori Flash di IAP

Semoga bermanfaat…

Visits: 5 Visits: 97939

Leave a Reply

Your email address will not be published. Required fields are marked *

Copyright © All rights reserved. | Newsphere by AF themes.