My device environment consists of a B4860 hardware chip platform running the OSE operating system, with a DCSR address space mapping type of SASE.
0xf1100000 - 0xf14fffff 0x00400000 rw-r-- cio ----g- SASE dcsr
Dereferencing any address within the range 0xf1124fff to 0xf1125fff caused a CPU freeze, followed by a reset due to a watchdog timeout. This address space is 4KB in size. I'd like to know information about the chip's DCSR register. What is the function of the DCSR register? Can't its value be directly accessed and read?
The freeze is consistent with accessing a documented non-accessible hole inside the B4860 DCSR space , not with a normal readable DCSR register.
DCSR is not one register; it is a 4 MB memory-mapped debug/control/status address space used for debug-related hardware resources such as run-control/debug events, trace generation, event counting, EPU performance counters, and Nexus/trace-related registers. Some DCSR resources are usable only for debug/internal purposes, and at least one support note states that DCSR/DSCR access is “for internal use only” and recommends using CCSR access for DTU where applicable.
For your mapping:
DCSR base = 0xf1100000
bad range = 0xf1124fff - 0xf1125fff
offsets = 0x24fff - 0x25fff
The key part is:
0xf1125000 - 0xf1125fff => DCSR offset 0x25000 - 0x25fff
That exact DCSR offset range is listed as a non-accessible slot , and NXP support evidence says reading 0x25000 ~ 0x25fff in DCSR space “will cause system hang”; the recommended solution is to exclude that range when enabling an MMU window for DCSR space. Other B4860-related evidence similarly says unmapped/unused/reserved regions in CCSR/DCSR are not accessible and accessing them may hang the SC3900 core or even the SoC.
So the answer is:
One additional detail: 0xf1124fff is one byte before the documented 0x25000 hole, but a 32-bit access at that unaligned address can cross into 0xf1125000 . DCSR/register accesses should be treated as aligned 32-bit register accesses, not arbitrary byte/word probing.
Recommended handling: map DCSR only if you need specific debug resources, restrict reads/writes to known valid offsets, and explicitly block/exclude DCSR + 0x25000 through DCSR + 0x25fff from any diagnostic dump or memory-scan code.
The freeze is expected for that address range: 0xf1125000–0xf1125fff maps to the B4860 DCSR non-accessible slot 0x25000–0x25fff , so arbitrary direct reads of DCSR space are unsafe.
Okay, so this issue is officially confirmed to be an inherent problem with the chip, right? It's not due to my personal settings or incorrect usage (although I really shouldn't have accessed that area).