Access Breakpoint doesn't stop the code execution when a specific memory location is being accessed (and its data value has changed).
For example, there is a memory corruption of a global variable and you'd like to find a problematic code. An access breakpoint is configured to hit on write access to this variable but, it never hits while you see the variable is changing in the Watch window.
Note that RH850 Access breakpoint logic is connected to the main CPU memory buses only. As such it can detect data access and changes on these buses only. In the particular case, the variable was modified by the DMA module and consequently the CPU access breakpoint didn't hit.
To observe a variable change, which is written by another memory bus master (e.g. CAN, FlexRay, DMA etc.), try using Analyzer Trace and its trigger to record the problematic code writing to the variable.
Unlike the access breakpoint logic, Analyzer Trace sees all internal CPU buses. This particular access breakpoint restriction was identified on Renesas RH850 architecture. Note that other architectures can behave in a similar fashion.
Follow Tutorials:
Sorry this article didn't answer your question, we'd love to hear how we can improve it.
Note: This form won't submit a case. We'll just use it to make this article better.
{{ topic.Content }}