Greetings,
Try writing to MMU entry that is not zero. You are most likely replacing a previous entry that covered SRAM and/or FLASH and hence debugging fails. E.g. try this
e_lis r3, 0x1003 // Select TLB1 Entry 1, define R/W replacement control
ori r3, r3, 0x0000
mtMAS0 r3 // Load MAS0 with 0x1003 0000 for TLB Entry1
Within Codewarrior 2.10, the MMU table is initialized differently using a reset macro script from PEmicro. Within this script, there are multiple entries in the MMU that closely resembles how the BAF initializes the chip. The zeroth entry is Peripheral B and this is why FLASH and SRAM were kept intact and debugging behaved normally. Most likely Lauterbach is similarly setting up the MMU Table in this fashion and hence why there was no issue there as well. However in Codewarrior 10.x and 11.x the reset scripts are handled using NXP's TCL scripts that writes only one entry in the MMU Table at entry 0:
# Setup MMU entry 0 for entire 32-bit address space: base address = 0x0000_0000
# 4GB Memory Space, Not Guarded, Cache inhibited, All Access
if {$booke_vle == "vle"} {
# VLE page
reg ${TLB1_GROUP}MMU_CAM0 = 0xB0000008FE0800000000000000000001
} else {
# BOOKE page
reg ${TLB1_GROUP}MMU_CAM0 = 0xB0000008FC0800000000000000000001
}
This one entry is set to cover the entire memory map. Your entry is replacing this single MMU table entry and therefore you lose access to the flash and SRAM located elsewhere. This is why reading the current MMU table entries before writing to it is probably good practice.
Note, S32 Power IDE does use PEmicro's reset scripts so users will not face this problem.
Best,
Takao
PEmicro Design Engineer
