Securing & Unsecuring Flash, E64 & E256

Secure Flash:

加密後的Flash是無法經外部BDM or Cyclone Pro讀取Flash內容。
加密的方法是在Flash 0xFF0F的位址寫入0x80 or 0x81 or 0x83，重新開機後MCU會把0xFF0F的值載入FSEC暫存器。FSEC[1:0]所代表即是目前Flash的加密狀態。
After reset, @FF0F --> FSEC

Unsecure Flash:

FSEC是唯讀的，不能經由改寫FSEC[1:0]改變Flash的加密狀態。
解密的方法有二：
一、使用Backdoor key, 可暫時的將Flash解密。這個方法通常是由外部提供Keys, 如經由RS232輸入。
二、抹除0xFF0F所在的Sector (0xff00 == 0x3FBF00). 然後將0xFF0F寫入0x82，重新開後 @FF0F à FSEC，便可將Flash解密。抹除的工作都必需是由MCU的Firmware。

想不到是AN2880SW有問題，之前可能都沒人試吧！
KEYACC @ FCNFG[5] 被設成1之後是無法讀取Flash資料的。
但是在AN2880SW的程式中犯了這樣的錯誤。

HCS12, Flash Security

欲燒錄位於 0xFF00 ~ 0xFFFF Flash 前
(P.S. 0xFF00 == 0x3FBF00)
先抹除,
   add = 0x003FBFF0;
   Flash_SectorErase(add);
再開始執行燒錄的工作。

問題：抹除後就無法對 Flash 作操作了。
推測可能是 Security byte 的問題，抹除後，在位址 0x3FBFF0F 寫入 0xFE
就可以了。

HCS12 Bootloader, Interrupt Table Arrangement

After reset, The bootloader's startup routine is called,
startup routine 將 RAM 的位址 remap 至 0xF000 ~ 0xFFFF (4KB).
原先在該範圍的 Flash 便無法使用。
所參考的中斷向量便是存放 RAM 中, 而不是在 Flash.

Bootloader 可正常的使用中斷, 但需注意的是在程式中的宣告,
不可使用 constant 來宣告中斷向量表。
const INT16U INTsTable[] @ 0xFF00 = {.....}; (X)
INT16U INTsTable[] @ 0xFF00 = {.......};         (O)

如此一來 startup routine 在執行初始化全域變數時才會將 Interrupt vectors 填入.
不然中斷向量會被當成常數存在放 Flash 裡。


Bootloader 更新 Application Interrupt table 時, 因為中斷向量表位在: 0xFF00 ~ 0xFFFF
, 和目前的 RAM 位址重疊。要如何才能將中斷向量燒錄至 Flash 位於 0xFF00 ~ 0xFFFF 的位址？

Flash: 0xC000 ~ 0xFFFF == 0x3F8000 ~ 0x3FBFFF (Banked memory)

燒錄時可將位址作上述的轉換應該可以解上述的問題。(不過我還沒試過)
Reference

HCS12 Image File Arrangement

Image file = Application image + Bootloader image
The entry point of application has to be place in firm address.
先前假設 entry point 都會是固定的位址，風險有點高！
假設新編譯的執行檔其entry point不是在假設的位址，那便都開不了機了。

〝固定的位址〞, Bootloader 也必需知道這個位址。Bootloader 跳至 application
執行前必需到這個位址擷取 entry point.

Unused Flash

如系統遭受EMI影響，系統行為 erratically，也就是使 PC（program counter ）已不正確。This is called code-runaway.
未使用的Flash memory 其值為0xFF. 若程式執行時會將其解讀為 ' LDS $FFFF '

A simple solution is to fill unused Flash with $3F, the op-code for the SWI instruction. As this is a single byte instruction, it will always be executed correctly. The microcontroller will fetch the Software Interrupt Vector and execute the code at the address.

If the Software Interrupt is required by the application, an alternative solution is to use 'Implemented Instrutction' interrupt. As all page 1 op-codes are valid, it is necessary to choose a page 2 op-code. Filling unused Flash with $18A7 will cause an 'Unimplemented Instruction' interrupt if the CPU attempts to execute this op-code. $18 is pre-byte to select page 2, and $A7 is unimplemented on page 2. If the $A7 is read first, this will be interpreted as a NOP instruction and the next $18A7 will be read.

Unimplemented Opcode Trap

The CPU12 has opcodes in all 256 positions in the page 1 opcode map,
but only 54 of the 256 positions on page 2 of the opcode map are used.
If the CPU attempts to execute one of the 202 unused opcodes on
page 2, an unimplemented opcode trap occurs. The 202 unimplemented
opcodes are essentially interrupts that share a common interrupt vector,
$FFF8:$FFF9.
The CPU12 uses the next address after an unimplemented page 2
opcode as a return address. This differs from the M68HC11 illegal
opcode interrupt, which uses the address of an illegal opcode as the
return address. In the CPU12, the stacked return address can be used
to calculate the address of the unimplemented opcode for
software-controlled traps.

Flash module can’t run smoothly.

Description:

每從Flash_RamFunc() return便會當機！

Reason:

Trace stack point, 差別在於函式結尾組合語言" RTC", " RTS".
RTC: 不會考慮PAGE number, 適用 Memory mode: Small
RTS: 考慮PAGE number, 適用 Memory mode: Banked