Login

sahukumarsonu · 8 hours ago

Hi everyone,

While debugging a custom GBA Thumb audio mixer routine in mGBA 0.10.3 (macOS arm64 Qt6 build) using

Code:
arm-none-eabi-gdb

connected to the built-in GDB stub (

Code:
localhost:2345

), I noticed that setting a 32-bit hardware write watchpoint (

Code:
Z2

packet) inside IWRAM (

Code:
0x03004B20

) causes a consistent +516 cycle drift on

Code:
mTimingNextEvent

and triggers a

Code:
GBAAudioScheduleFifoDma: FIFO A empty on Timer 0 overflow!

pop every time execution resumes with

Code:
continue

.

Here is a screenshot of the ARM7TDMI register/watchpoint state alongside the

Code:
arm-none-eabi-gdb

and mGBA console output:

Code:
REG_TM0CNT_L = 0xFE80

, prescaler 1) driving Direct Sound FIFO A (

Code:
0x040000A0

) via DMA1 (

Code:
0xB640

).
2. Attach

Code:
arm-none-eabi-gdb

to

Code:
localhost:2345

and set a write watchpoint on the mixer channel position in IWRAM:

Code:
(gdb) target remote localhost:2345

(gdb) watch *(uint32_t*)0x03004b20

(gdb) c

3. When the watchpoint traps inside

Code:
SoundMainRam_Thumb

(

Code:
PC = 0x03001A44

) and we resume with

Code:
c

,

Code:
_GBAVideoSoftwareRenderer

logs that

Code:
LY=161

VBlank IRQ is delayed by ~516 cycles and Timer 0 misses 4 overflow ticks before DMA1 refills

Code:
REG_FIFO_A

.

Does the GDB stub pause

Code:
mTiming

sub-instruction DMA/Timer scheduling differently when trapping on an IWRAM data watchpoint (

Code:
_GBAMemoryWatchpoint

) vs. an instruction breakpoint (

Code:
Z0

), or is there a flag to freeze Timer 0 ticks while the stub is halted mid-scanline?

Thanks in advance!

***endrift*** · 7 hours ago

0.10.3 is very old. Please see if it reproduces on a 0.11 dev build: https://mgba.io/downloads.html#development-downloads