Espbar Agent Esp32 Eco and Solusi sementara untuk bug

Jika Anda perlu membeli informasi lebih lanjut tentang modul Espresf chip, solusi dan informasi lainnya, silakan kirimkan informasi yang relevan ke email kami, kami akan melayani Anda dengan sepenuh hati.


ESP32
ECO dan Solusi sementara untuk Bug

Dokumen ini merinci kesalahan perangkat keras dan solusi di ESP32.

Reset pengamat palsu terjadi bila ESP32 diaktifkan atau diaktifkan dari tidur nyenyak.
Solusi sementara:
Saat bangun tidur, bug ini akan ditangani secara otomatis pada ESP-IDF V1,0 dan yang lebih baru.
Selama penyalaan awal, reset watchdog palsu tidak dapat berfungsi, tapi ESP32 akan boot secara normal setelah reset ini.
Penanganan masalah Detail:
Untuk bekerja di sekitar watchdog saat bangun dari tidur lama, CPU dapat menjalankan program dari memori cepat RTC. Program ini harus membersihkan bendera akses ilegal di cache MU sebagai berikut:
1.Mengatur bit PRO_CACHE_MU_ia_CLR dalam DPORT_PRO_CACHE_CTRL1_RESG ke 1.
2.Bersihkan bit ini.
Perbaikan:
Masalah ini telah diperbaiki dalam revisi silikon 1.

Jika CPU mengakses SRAM eksternal melalui cache, pada kondisi tertentu kesalahan baca dan tulis akan terjadi.
Detail:
Akses ke SRAM melalui cache akan menyebabkan kesalahan baca dan tulis jika operasi ini dippielasi bersama oleh CPU.
Solusi sementara:
Tidak ada solusi otomatis yang tersedia di perangkat lunak.
Penanganan masalah Detail:
Jika mengakses SRAM eksternal dari revisi 0 ESP32, pengguna harus memastikan bahwa akses selalu berupa penulisan satu-arah atau pembacaan yang dapat berlangsung dalam satu waktu pada saluran CPU.
Petunjuk MEMW dapat digunakan: Sisipkan asm ("MEMW") setelah semua pembacaan dari PSRAM eksternal yang mungkin diikuti dengan penulisan ke PSRAM sebelum saluran CPU dibilas.

Perbaikan:
Masalah ini telah diperbaiki dalam revisi silikon 1.

Saat CPU mengakses periferal dan menulis satu alamat secara berulang, beberapa penulisan dapat hilang.
Detail:
Beberapa periferal ESP32 dipetakan ke dua bus memori internal (AHB & PORT). Ketika ditulis via DPORT, berturut-turut akan menulis ke alamat yang sama akan hilang.
Solusi sementara:
Masalah ini secara otomatis dapat dijalankan di driver ESP-IDF V1,0 dan yang lebih baru.
Penanganan masalah Detail:
Saat menulis alamat register yang sama (misalnya alamat FIFO-Like) dalam instruksi yang berurutan, gunakan alamat AHB yang setara bukan alamat PORT.
(Untuk jenis register lain, dengan menggunakan DCE akan memberikan performa menulis yang lebih baik lagi)
 
Perbaikan:
Masalah ini telah diperbaiki dalam revisi silikon 1.
Perhatikan:
Perangkat lunak tidak dapat menggunakan alamat AHB untuk membaca FIFO.

Fungsi Pengaturan Ulang (BOR) Brown-out tidak bekerja. Sistem gagal boot setelah BOR.
Solusi sementara:
Tidak ada solusi untuk masalah ini.
Perbaikan:
Masalah ini telah diperbaiki dalam revisi silikon 1.

CPU akan berhenti berfungsi saat frekuensi clock berubah langsung dari 240 MHz menjadi 80/160 MHz.
Solusi sementara:
Masalah ini secara otomatis dapat dijalankan pada ESP-IDF V2.1 dan yang lebih baru.
Penanganan masalah Detail:
Ketika mengalihkan frekuensi, gunakan frekuensi antara seperti berikut: (1) 2 MHz <-> 40 MHz <-> 80 MHz <-> 160 MHz
(2) 2 MHz <->40 MHz <->240 MHz
Perbaikan:
Masalah ini telah diperbaiki dalam revisi silikon 1.

Resistor tarik-ke atas dan tarik-turun untuk bantalan dengan fungsionalitas GPIO dan RTC_GPIO hanya bisa dikontrol melalui register RTC_Gpipa.
Detail:
Untuk bantalan ini, bidang pentarik naik dan konfigurasi tarik turun GPIO tidak berfungsi.

Solusi sementara:
Masalah ini secara otomatis dapat diatasi ketika menggunakan driver GPO, ESP-IDF V2.1 atau yang lebih baru.
Penanganan masalah Detail:
Gunakan RTC_GPIO didaftarkan untuk fungsi GPIO dan RTC_GPIO.

Karena waktu pengaktifan flash, reset watchdog palsu terjadi saat ESP32 diaktifkan atau diaktifkan dari tidur yang dalam.
Detail:
Jika ESP32 membaca dari chip flash sebelum siap, data yang tidak valid dapat menyebabkan boot gagal hingga jadwal pengawas direset terjadi. Ini bisa terjadi saat penyalaan dan saat terbangun dari tidur nyenyak, jika ESP32 VDD_SDIO digunakan untuk memberi daya chip flash.

Solusi sementara:
1.Ganti chip flash dengan satu chip penyalaan cepat (<800 μs dari daya hingga siap dibaca). Ini akan bekerja untuk masalah untuk menghidupkan dan mematikan dari tidur yang dalam.
2.Apabila Anda bangun tidur nyenyak, masalah ini otomatis ditangani oleh ESP-IDF V2.0 dan yang lebih baru (penundaan menunggu bisa dikonfigurasi jika perlu). Dalam penanganan masalah ini, CPU langsung menjalankan dari memori RTC secara cepat setelah bangun tidur dan kemudian ditambahkan sebelum melanjutkan membaca program dari flash.
Perbaikan:
Masalah ini telah diperbaiki dalam revisi silikon 3 (ECO V3).

Jika CPU mengakses SRAM eksternal dengan urutan tertentu , kesalahan baca & tulis dapat terjadi.
Detail:
Error ini bisa terjadi ketika CPU menjalankan instruksi berikut untuk mengakses SRAM eksternal:
store.x at0, as0, n
muat.y at1, as1, m
Dalam petunjuk perakitan palsu di atas, Store.x menunjukkan operasi menulis x-bit, sementara load.y mewakili operasi pembacaan bit-y. as0+n dan as1+m menunjukkan alamat yang sama di SRAM eksternal.
?Petunjuk dapat diatur secara berurutan atau dapat berada dalam saluran yang sama (kurang dari empat petunjuk menengah, dan tidak ada pembersihan saluran.)
?Bila x>=y, penulisan data dapat hilang. (CATATAN: Jika beban dan toko mengacu pada nilai 32-bit, tulis hanya hilang jika terjadi interupsi antara petunjuk pertama dan kedua.)
?Bila x <y, data menulis mungkin hilang dan data yang tidak valid mungkin terbaca.
Solusi sementara:
Bug ini secara otomatis akan bekerja ketika penggunaan SRAM eksternal diaktifkan pada ESP-IDF V3.0 dan yang lebih baru.
Penanganan masalah Detail:
?Bila x>=y, masukkan empat instruksi bagian tanpa batas antara toko.x dan muat.y.
?Bila x <y, masukkan petunjuk tanda di antara toko.x dan muat.y.
Perbaikan:
Masalah ini telah diperbaiki dalam revisi silikon 3 (ECO V3).

Ketika setiap CPU membaca beberapa spasi alamat secara bersamaan, kesalahan baca dapat terjadi.
Detail:
Berjalan dalam mode CPU dual-core, ketika satu bus CPU membaca ruang alamat A (0x3FF0_0000 0x3FF1_FFF), sementara bus CPU lain membaca Address Space B (0x3FF4_0000 _0x3FFFF), pembacaan yang salah dapat dihasilkan di ruang alamat CPU B.
Solusi sementara:
Masalah ini secara otomatis dapat dijalankan pada ESP-IDF V3.0 dan yang lebih baru.
Penanganan masalah Detail:
Salah satu solusi sementara berikut dapat digunakan:
?Jika CPU membaca ruang alamat A, cegah bus CPU lainnya dari ruang baca B via kunci dan interupsi.
?sebelum membaca ruang alamat A, nonaktifkan menyela dan masukkan pembacaan dari ruang alamat B di CPU yang sama (baca register non-FIFO, mis. 0x3FF40078).
Perbaikan:
Masalah ini telah diperbaiki dalam revisi silikon 3 (ECO V3).

Saat periferal RTC tertentu dinyalakan, input GPIO36 dan GPIO39 akan ditarik hingga sekitar 80 ns.
Detail:
Menghidupkan periferal RTC berikut akan memicu masalah ini:
?SARADC1
?SAMC2
?AMP
?RUANG
Solusi sementara:
Saat mengaktifkan daya untuk periferal apa pun, Abaikan input dari GPPIKO36 dan GPPIK39.

Bila LEDC sudah tua sekali, kesalahan aliran tugas dapat terjadi.
Detail:
Masalah ini mungkin terjadi bila LEDC sudah tua dan modus memudar secara mental_DUTY_SCALE_HSCHn adalah 1. Jika tugas adalah 2LEDC_HSTIMERx_DUTY_RES, maka tanda berikutnya

Seharusnya 2LEDC_HSTIMERx_DUTY_RES - 1, namun, tugas berikutnya sebenarnya 2LEDC_HSTIMERx_DUTY_RES+1, yang mengindikasikan kesalahan limpahan tugas. (HSCHn mengacu pada saluran kecepatan tinggi dengan n menjadi 0-7; HSTIMERx merujuk pada timer kecepatan tinggi dengan tanda x sebagai 0-3.)
Untuk saluran kecepatan rendah, masalah yang sama juga mungkin terjadi.
Solusi sementara:
Masalah ini secara otomatis dapat diatasi di driver LEDC karena ESP-IDCF Commit ID b2e264e dan akan menjadi bagian dari rilis ESP-IDF V3,1.
Penanganan masalah Detail:
Saat menggunakan LEDC, hindari kejadian dari tiga kasus berikut:
1.LEDC berada dalam mode memudar mental;
2.Pendaftaran skala diatur ke 1;
3.yang tugas adalah 2LEDC_HSTIMERx_DUTY_RES atau 2LEDC_LSTIMERx_DUTY_RES.

ESP32 DAPAT kesalahan
Penghitung kesalahan menerima (REC) dapat diubah saat berada dalam mode reset atau pemulihan bus-off.
Detail:
Ketika kontroler DAPAT masuk ke mode reset (mis., dengan mengatur bit RESET_MODE atau karena kondisi bus mati) atau ketika pengontrol CAN mengalami pemulihan bus-off, REC masih dapat diubah. Hal ini dapat menyebabkan kasus berikut:
?sedangkan dalam mode reset atau pemulihan bus mati, REC yang berubah dapat menyebabkan perubahan pada status kesalahan yang kemudian dapat memicu interupsi batas peringatan kesalahan.
?selama pemulihan bus-off, orang REC > 0 dapat mencegah proses pemulihan bus-off selesai.
Solusi sementara:
Ketika memasuki mode reset, kontroler CAN harus mengatur MODE LISTEN_ONLY_MODE untuk menghentikan REC. Mode pengoperasian yang diinginkan harus dipulihkan sebelum keluar dari mode reset atau setelah pemulihan bus-off selesai.

Bit status kesalahan tidak dibekukan selama pemulihan bus-off.
Detail:
Ketika kontroler CAN mendukung proses pemulihan bus-off, pengontrol harus memantau 128 kemunculan sinyal bebas bus (11 bit resesif berturut-turut) sebelum dapat menjadi kesalahan aktif lagi. Jumlah sisa sinyal bebas-bus ditunjukkan oleh penghitung kesalahan pengiriman (TEC). Karena bit status kesalahan tidak dibekukan selama pemulihan bus-off, nilainya akan berubah ketika penghitung kesalahan pengiriman turun di bawah batas peringatan kesalahan transmisi yang ditentukan pengguna (96 pada pengaturan standar) sehingga memicu interupsi peringatan kesalahan sebelum pemulihan bus-off selesai.

Solusi sementara:
Saat mengalami pemulihan bus-off, gangguan peringatan kesalahan tidak selalu mengindikasikan pemulihan. Pengguna harus memeriksa bit STATUS_NODE_BUS_OFF untuk memverifikasi apakah pemulihan bus-off sudah selesai.

Pesan dikirim setelah pemulihan bus-off salah.
Detail:
Setelah menyelesaikan pemulihan bus, pesan berikutnya bahwa pengiriman CAN pengontrol dapat salah (yaitu, tidak mematuhi format rangka CAN).
Solusi sementara:
Setelah mendeteksi penyelesaian pemulihan bus mati (melalui peringatan kesalahan gangguan), kontroler CAN harus masuk ke mode reset keluar sehingga sinyal internal pengontrol diatur ulang.

Membaca daftar interupsi bisa menyebabkan gangguan transmisi hilang.
Detail:
Sinyal interupsi kontroler CAN dihapus dengan membaca REG_REG. Namun, jika terjadi interupsi transmisi saat INTERUPSI_REG sedang dibaca (yaitu, dalam siklus jam APB yang sama), interupsi transmisi hilang.
Solusi sementara:
Saat pesan sedang menunggu penyelesaian transmisi (mis. Transmisi telah diminta), pengguna juga harus memeriksa bit STATUS_TRANSMIT_BUFFER setiap kali INTERRUPT_REG dibaca.  Set STATUS_TRANSMIT_BUFFER bit sedangkan CAN_TRANSMIT_INT_ST tidak mengindikasikan interupsi transmisi hilang.

Menerima bingkai data yang salah dapat menyebabkan byte data dari bingkai data yang diterima berikutnya tidak valid.
Detail:
Ketika pengontrol CAN menerima bingkai data dan kesalahan bit atau hal terjadi dalam bidang data atau CRC, beberapa byte data dari bingkai data yang diterima berikutnya mungkin digeser atau hilang.
Oleh karena itu, bingkai data yang diterima berikutnya (termasuk yang difilter oleh filter penerimaan)
harus dianggap tidak valid.
Solusi sementara:
Pengguna dapat mendeteksi kondisi pemicuan errata (mis. Kesalahan bit atau hal di bidang data atau CRC) dengan mengatur INTERUPSI_BUS_ERR_INT_ENA dan memeriksa ERROR_CODE_REG ketika terjadi gangguan kesalahan bus. Jika kondisi kesalahan terpenuhi, solusi berikut ini dimungkinkan:
?Kontroler CAN dapat mentransmisikan bingkai dummy dengan 0 byte data untuk mereset sinyal internal pengontrol. Sebaiknya pilih ID untuk frame dummy yang dapat disaring oleh semua node pada bus CAN.

?Perangkat keras mengatur ulang KONTROLER CAN (akan membutuhkan penyimpanan dan mengembalikan nilai register saat ini).

Setelah kehilangan arbitrase, bit dominan pada bit ketiga antar misi tidak diterjemahkan sebagai SOF.
Detail:
Protokol CAN2,0B menetapkan bahwa bit dominan pada bit ketiga intermisi harus diterjemahkan sebagai Start of Frame (SOF). Oleh karena itu, node akan mulai menerima atau mengirimkan transmisi (yaitu, bersaing untuk arbitrase) bidang ID pada bit berikutnya.
Ketika pengontrol CAN kehilangan arbitrase dan bit ketiga dari misi berikut ini dominan, pengontrol CAN tidak akan menafsirkannya sebagai SOF dan tidak akan berusaha bersaing untuk arbitrase (yakni tidak mengirimkan ulang bingkainya).
Solusi sementara:
Tidak ada solusi untuk masalah ini.

Ketika pembatas kesalahan 8 bit dominan, kesalahan pasif tidak dimasukkan.
Detail:
Bila kontroler CAN adalah pemancar dan memiliki nilai TEC antara 120 dan 127, maka transmisi bingkai kesalahan akan meningkatkan TEC-nya pada tahun 8 sehingga membuat kesalahan kontrol menjadi pasif (karena TEC menjadi >= 128). Akan tetapi, jika pembatas kesalahan dari 8 bit dominan, TEC masih akan bertambah 8 namun pengontrol tidak akan menjadi kesalahan pasif. Sebaliknya, pengontrol akan menjadi kesalahan pasif ketika bingkai kesalahan lain ditransmisikan. Perhatikan bahwa pengontrol masih akan menghasilkan overload yang diperlukan karena memiliki bit dominan ke-8.
Solusi sementara:
Tidak ada solusi untuk masalah ini.

Menangguhkan transmisi disertakan bahkan setelah kehilangan arbitrase.
Detail:
Protokol CAN2,0B menetapkan bahwa kesalahan node pasif yang merupakan pemancar pesan harus menambahkan bidang transmisi yang ditangguhkan di dalam ruang antar bingkai berikutnya. Namun, penerima pasif kesalahan tidak boleh menambahkan bidang transmisi yang ditangguhkan.
Ketika kontroler CAN merupakan kesalahan pasif dan kehilangan arbitrase (maka menjadi penerima), pengontrol tersebut masih akan menambahkan bidang transmisi yang ditangguhkan di ruang antar bingkai berikutnya. Hal ini mengakibatkan pengontrol CAN terlambat untuk memulai transmisi ulang. Oleh karena itu, jika node lain melakukan transmisi segera setelah ruang antar frame selesai, pengontrol CAN gagal bersaing untuk arbitrase karena node lain tidak termasuk bidang transmisi yang ditangguhkan di ruang antar frame mereka (seperti spesifikasi CAN2.0B).

Solusi sementara:
Tidak ada solusi untuk masalah ini.

Bila terjadi kesalahan selama arbitrase saat sedang transmiter, setiap kesalahan pada bingkai kesalahan/beban berikutnya tidak akan meningkatkan TEC.
Bila terjadi kesalahan selama arbitrase saat sedang transmiter, protokol CAN2.0B menetapkan bahwa bingkai kesalahan dikirimkan tapi TEC tidak boleh meningkat (Pengecualian 2 dari Aturan 3). Pengontrol CAN mampu memenuhi persyaratan ini tanpa masalah.
Namun, kesalahan dalam bingkai kesalahan/kelebihan beban berikutnya sendiri tidak akan meningkatkan TEC pengontrol CAN. Oleh karena itu, ketika terjadi kesalahan selama arbitrase saat sedang transmiter, TEC akan gagal meningkat dalam kasus berikut:
?kesalahan bit dalam tanda kesalahan yang aktif atau tanda kelebihan beban (Aturan 4).
?mendeteksi terlalu banyak bit dominan setelah transmisi kesalahan aktif, bendera kesalahan pasif, dan tanda kelebihan beban (Aturan 6).
Solusi sementara:
Tidak ada solusi untuk masalah ini.

Kesalahan fase negatif di mana |e| > SJW(N) akan menyebabkan bit yang ditransmisikan yang tersisa digeser ke kiri.
Detail:
Ketika pengontrol CAN menemukan gejala yang berlebihan dengan tepi dominan dengan kesalahan fase negatif (yaitu, tepi lebih awal), maka akan benar untuk kesalahan fase menggunakan penyelarasan ulang sebagaimana diperlukan oleh protokol AN2.0B. Namun, jika pengontrol CAN berfungsi sebagai pemancar dan mengalami kesalahan fase negatif di mana e < 0 dan |e| > SJW, bit yang ditransmisikan setelah kesalahan fase akan digeser ke kiri satu bit. Oleh karena itu, isi bingkai yang ditransmisikan (yakni, DLC, byte data, urutan CRC) akan rusak.
Solusi sementara:
Tidak ada solusi untuk masalah ini.

Periferal EP32 APIO mungkin tidak memicu interupsi dengan benar.
Detail:
Periferal EP32 APIO mungkin tidak terpicu dengan benar jika beberapa bantalan GPO dikonfigurasikan dengan interupsi yang dipicu oleh tepi.
Penanganan masalah 1:
Ikuti langkah-langkah di bawah ini untuk memicu "GPIO" memotong pada tepi yang tegak:
1.Atur tipe interupsi GPO ke tinggi.
2.Atur tipe pemicu interupsi CPU ke tepi.

3.setelah servis CPU, ubah tipe gangguan GPO ke rendah.  Terjadi gangguan kedua pada saat ini, dan CPU perlu mengabaikan prosedur servis interupsi.
Demikian juga, ikuti langkah-langkah di bawah ini untuk memicu "GroIO" yang jatuh ke tepi:
1.Mengatur tipe interupsi GPO ke rendah.
2.Atur tipe pemicu interupsi CPU ke tepi.
3.setelah servis CPU, ubah tipe interupsi GPO ke tinggi.  Terjadi gangguan kedua pada saat ini, dan CPU perlu mengabaikan prosedur servis interupsi.
Penanganan masalah 2:
GrPIO0 - Grup31 Grup1 dan Grup32GPI39 adalah Grup2.
?Jika interupsi yang dipicu oleh tepi dikonfigurasi di salah satu grup, maka tidak ada interupsi GPIO lain yang bisa dikonfigurasi di grup yang sama.
?ada interupsi yang dipicu level berapa pun yang bisa dikonfigurasi dalam sebuah grup, jika tidak ada interupsi yang dipicu tepi yang dikonfigurasikan dalam grup itu.

Chip ESP32 mungkin memiliki kunci langsung pada kondisi tertentu yang akan menyebabkan masalah watchdog.
Detail:
Pada ESP32 V3, apabila kondisi berikut ini terpenuhi pada saat bersamaan, kunci hidup akan terjadi, menyebabkan CPU terhenti pada status akses memori dan hentikan instruksi eksekusi.
1.Sistem inti ganda.
2.dari empat bus instruksi/Data (IBUS/DBUS) yang mengakses memori eksternal, tiga kali secara bersamaan memulai permintaan akses ke set singgahan yang sama, dan ketiga permintaan akan menghasilkan singgahan yang tidak ditemukan.
Solusi sementara:
Bila kunci live terjadi, perangkat lunak yang secara proaktif atau pasif mengenali dan membuka penguncian saluran cache, lalu kedua inti tersebut menyelesaikan operasi cache satu demi satu, setelah kebijakan yang pertama dijalankan, untuk menyelesaikan penguncian aktif. Proses detilnya adalah sebagai berikut:
1.Jika kunci langsung terjadi jika instruksi yang dilakukan oleh kedua inti tidak berada pada bagian kritis kode, berbagai jenis interupsi sistem akan secara proaktif melepaskan persaingan jalur cache dan mengatur kunci langsung.
2.Jika kunci live terjadi jika instruksi yang dijalankan oleh kedua inti berada di bagian kritis kode, sistem akan interuptor di level 3 dan di bawahnya. Oleh karena itu, perangkat lunak perlu menyiapkan  interupsi prioritas tinggi (level 4 atau 5) untuk setiap core sebelumnya, sambungkan interupsi ke pengatur waktu yang sama, dan konfigurasikan ambang batas waktu yang sesuai. Interupsi waktu habis yang dihasilkan oleh penguncian aktif akan memaksa

Kedua core untuk memasuki rehentikan pengendali gangguan prioritas tinggi, sehingga melepaskan IBUS dari kedua-dua core untuk menyelesaikan penguncian langsung. Proses resolusi kunci langsung diselesaikan dalam tiga tahap:
(A)pada tahap pertama, kedua core menunggu CPU write buffer dibersihkan.
(B)pada tahap kedua, satu core (Core 0) menunggu dan satu inti lagi (Core 1) menjalankan instruksi.
(c)pada tahap ketiga, Core 1 menunggu dan Core 0 menjalankan instruksi.

Ada keterbatasan akses CPU ke 0x3FF0_0000 0x3FF1 _FFF dan 0x3FF4_0000 0x3FF7_FFFF.
Detail:
1.Operasi membaca CPU yang terdapat di kedua ruang alamat ini adalah spekulatif. Operasi pembacaan spekulatif dapat menyebabkan perilaku yang dijelaskan oleh program tersebut tidak konsisten dengan perilaku perangkat keras aktual.
2.Jika dua CPU terus-menerus mengakses ruang alamat 0x3FF0_0000 - 0x3FF1_FFF pada saat yang sama, beberapa akses mungkin akan hilang.
3.Bila CPU membaca FIFO melalui ruang alamat 0x3FF4_0000 0x3FF7_0000, penunjuk baca FIFO diperbarui dengan penundaan. Ketika frekuensi CPU meningkat, interval antara dua pembacaan FIFO berurutan yang dimulai oleh CPU menjadi singkat. Saat permintaan baca FIFO baru tiba, penunjuk pembacaan FIFO belum diperbarui, yang menyebabkan CPU membaca nilai dari operasi pembacaan FIFO sebelumnya.
Solusi sementara:
1.masukkan instruksi "MEMW" sebelum pengoperasian akses CPU yang berada di dua ruang alamat ini. Yaitu, di C/C++, perangkat lunak harus selalu menggunakan atribut "volatil" saat mengakses data di dua ruang alamat ini.
2.Apabila frekuensi CPU adalah 160 MHz, tambahkan enam "tanpa P" di antara dua bacaan FIFO yang berurutan. Ketika frekuensi CPU 240 MHz, tambahkan tujuh "nop" di antara dua FIFO berturut-turut.