ZeroPain in DWCDriver

DWCDriver appears to be making assumptions about where the stack is and triggers a Zero Pain error when an single tasking app changes it to point to application space. Although it mentions FTPc, I was testing a game at the time it was triggered.

Time: Thu Oct  8 15:27:28 2015
Location: Offset 0000023c in module DWCDriver
Current Wimp task: Unknown
Last app to start: <FTPc$dir>.!runimage 

R0  = fa101ed0 R1  = 30002ab4 R2  = 00000000 R3  = 60000193
R4  = 00000000 R5  = 0000007f R6  = 60000192 R7  = 800001d3
R8  = 00000000 R9  = fc25d298 R10 = 00000000 R11 = 300857d9
R12 = 30002ab4 R13 = 000231b0 R14 = 800001d3 R15 = fc1ea408
DFAR = 00000000  Mode SVC32  Flags nZCv If   PSR = 60000193

fc1ea3c0 : 13510102 : CMPNE   R1,#&80000000
fc1ea3c4 : e8bd9f80 : LDMIA   R13!,{R7-R12,PC}
fc1ea3c8 : e92d4fff : STMDB   R13!,{R0-R11,R14}
fc1ea3cc : e3a02000 : MOV     R2,#0
fc1ea3d0 : e1a0000d : MOV     R0,R13
fc1ea3d4 : e13f000f : TEQ     PC,PC
fc1ea3d8 : 11a0800f : MOVNE   R8,PC
fc1ea3dc : 13883003 : ORRNE   R3,R8,#3
fc1ea3e0 : 1333f000 : TEQNEP  R3,#0
fc1ea3e4 : 010f6000 : MRSEQ   R6,CPSR
fc1ea3e8 : 03863003 : ORREQ   R3,R6,#3
fc1ea3ec : 0121f003 : MSREQ   CPSR_c,R3
fc1ea3f0 : e1a0100c : MOV     R1,R12
fc1ea3f4 : e1a0700e : MOV     R7,R14
fc1ea3f8 : e1a0aa2d : MOV     R10,R13,LSR #20
fc1ea3fc : e1a0aa0a : MOV     R10,R10,LSL #20
fc1ea400 * e89a0030 * LDMIA   R10,{R4,R5}
fc1ea404 : e59cc000 : LDR     R12,[R12,#0]
fc1ea408 : e99c1800 : LDMIB   R12,{R11,R12}
fc1ea40c : e88a1800 : STMIA   R10,{R11,R12}
fc1ea410 : e28aaf87 : ADD     R10,R10,#&021C     ; =540
fc1ea414 : e3a0b000 : MOV     R11,#0
fc1ea418 : e1a0e00f : MOV     R14,PC
fc1ea41c : e28ee00c : ADD     R14,R14,#&0C       ; =12
fc1ea420 : e08ff002 : ADD     PC,PC,R2
fc1ea424 : e1a00000 : MOV     R0,R0
fc1ea428 : ea0001c7 : B       &FC1EAB4C
fc1ea42c : e24aaf87 : SUB     R10,R10,#&021C     ; =540
fc1ea430 : e88a0030 : STMIA   R10,{R4,R5}
fc1ea434 : e1a0e007 : MOV     R14,R7
fc1ea438 : e13f000f : TEQ     PC,PC
fc1ea43c : 0a000003 : BEQ     &FC1EA450

FTPc also switches the stack to application space between wimp polls when transferring data so the above could be from FTPc. The fact that DWCDriver caught the problem implies to me a socket call problem. Sockets transfer data via etherusb to the USBDriver.

Did you have FTPc running before running your task. If so was it doing anything? Is the zeropain output repeatable?

I knew I shouldn’t have woke FTPc up.

FTPc was sitting idle in the background, I hadn’t made any connections. I don’t believe a Module should be making assumptions about the stack location, hence why I posted this in a separate thread.

Is the zeropain output readable?

Not sure what you mean, is there more logging that what I posted above?

All C modules assume that the SVC stack (and IRQ stack?) have their base on a 1MB boundary. It’s due to the nasty way in which they need to set up the C relocation offsets at the base of the stack. I don’t like it, but I don’t think it’s something that we can change without breaking compatibility with all existing C modules.

All C modules assume that the SVC stack (and IRQ stack?) have their base on a 1MB boundary

Nasty. Who decided C Modules were a good idea with that restriction? (Don’t answer that one!!)

Will have to put my thinking hat on, as that’s a bit of a showstopper with the amount of C Modules appearing in RO these days.

Jon.

Is the zeropain output repeatable?

@Colin – possibly, I’ll need to figure out which game triggered it. Elite, Wolfenstein 3D, Lemmings 2, Diggers, Populous, James Pond II, DarkWood to name a few I was testing at the time.

All C modules assume that the SVC stack (and IRQ stack?) have their base on a 1MB boundary

Could OS_DynamicArea 0 be extended to allow DA’s to be created on a 1MB boundary? I can’t think of any other legal method to allocate stack space to comply with CLib’s restrictions.

Yeah, I guess that would make sense. Maybe it’s also time we expose OS_Heap 7 via OS_Module so that you can allocated aligned blocks from the RMA (technically you could call OS_Heap 7 on the RMA manually, but then you’d also have to deal with manually growing the RMA to the right size if the call fails, so it’s better to just let the OS do it)

Exposing OS_Heap 7 via OS_Module won’t help with this particular quirk of C Modules, but I suppose there may be a case for it at some point, cache alignment perhaps.

Just be mindful of PRM1-207 when updating documentation to match:

Note that workspace allocated through XOS_Module will always lie on an address
&xxxxxxx4. This enables code written for time-critical software (eg sound voice
generators and FIQ handlers) to be aligned within the module body.

Exposing OS_Heap 7 via OS_Module won’t help with this particular quirk of C Modules

You can request a block with 1MB alignment. But I guess in terms of RAM usage it would be much better to create a dynamic area – if the RMA was used (especially if you wanted multiple stacks) you’d end up with a big block of free space which may never get filled.

I don’t touch the RMA for stack space, they’re created as DA’s to trap over/underruns. Following your thinking though, I could create them as 2MB DA’s and only use the 4kb that’s 1MB aligned.