Interpretation

QNX Newsgroups (Archives) qdn.public.qnxrtp.embedded
#1

I am doing a custom BSP for the cs89712 (ARM720T core).

I have arrived at the point where I launch procnto, which
promptly does a shutdown (not surprising, at this stage).

If anyone could give me an idea of why procnto is shutting
down, I would be most appreciative. Here is the dump
message:

Shutdown[0,0] S/C/F=11/1/11 C/D=fe005d7c/fe048500 state(c0)= now lock
[0]PID-TID=1-1? P/T FL=00019001/09000000
armle context[ff7f5f54]:
0000: 00000000 00000008 00000001 00000100 00000000 ff7fdbb0 00000000 ff7f40b0
0020: 00000008 fe020eec 00000000 ff7f5fa8 00000008 ff7f5f98 fe023878 fe023878
0040: 600000d3
instruction[fe023878]:
be 30 d4 e1 01 30 43 e2 be 30 c4 e1 be 00 d4 e1 1c 30 9f e5 d0 30 d3 e1 00 00
stack[ff7f5f98]:
0000: ff7fb448 ff7f5fd8 ff7f5fac fe023500 fe0237fc 00000000 00000008 fe0480c4
0020: 00000001 ff7fdbb0 00000000 00000000 00000000 ff7f5fec ff7f5fdc fe0216b4
0040: fe0233dc ff7fdbb0 ff7f5ffc ff7f5ff0 fe03158c fe021664 ff7f3f6c ff7f6000
0060: fe01f500 fe031574 ff7fdbb0 00001000 ff7f8038 00000ff8 00000000 00000000


Following is the dump of this syspage immediately prior to starting procnto.

Cache: 512x16 WT
arm720 rev 2 0MHz
Header size=0x0000009c, Total Size=0x000004f8, #Cpu=1, Type=4
Section:system_private offset:0x000001d8 size:0x00000068
syspage ptr user:fc404000 kernel:fc404000
cpupage ptr user:fc404828 kernel:fc404828 spacing:32
kdebug info:00000000 callback:00000000
boot pgms: idx=0
0) base paddr:c000a000 start addr:fe01c530
ramsize:01000000 pagesize:00001000
Section:qtime offset:0x00000148 size:0x00000048
boot:000000ff CPS:000000000007d000 rate/scale:1953125000/-15 intr:8
Section:callout offset:0x000000a0 size:0x00000048
reboot:fc404678 power:00000000
timer_load:fc404694 reload:fc4046cc value:fc4046e4
0) display:fc404704 poll:fc404728 break:fc40474c

  1. display:00000000 poll:00000000 break:00000000
    Section:cpuinfo offset:0x00000190 size:0x00000020
  2. cpu:41807202 flags:40000000 speed:00000000 cache i/d:0/0 name:55
    Section:cacheattr offset:0x000004d8 size:0x00000020
  3. flags:13 size:0010 #lines:0200 control:fc404518 next:255
    Section:meminfo offset:0x00000240 size:0x00000050
    t:2 a:c0009108 s:00135efc t:3 a:c0009108 s:00135efc t:1 a:c013f004 s:00008ffc
    t:1 a:c0153848 s:00eac7b8
    Section:asinfo offset:0x00000338 size:0x00000160
  4. 0000000000000000-00000000ffffffff o:ffff a:0010 p:100 c:00000000 n:21
  5. 0000000080000000-0000000080004000 o:0000 a:0013 p:100 c:00000000 n:28
  6. 0000000080000000-0000000080004000 o:0020 a:0003 p:100 c:00000000 n:35
  7. 00000000c0000000-00000000c0ffffff o:0000 a:0017 p:100 c:00000000 n:38
  8. 0000000070000000-00000000707fffff o:0000 a:0007 p:100 c:00000000 n:42
    00a0) 0000000020000000-000000002007cfff o:0000 a:0007 p:100 c:00000000 n:48
    00c0) 00000000c0000000-00000000c0ffffff o:0060 a:0017 p:100 c:00000000 n:38
    00e0) 00000000c0009108-00000000c013f003 o:0000 a:0005 p:100 c:00000000 n:62
  9. 00000000c0009108-00000000c013f003 o:0000 a:0007 p:100 c:00000000 n:70
  10. 00000000c013f004-00000000c0147fff o:00c0 a:0007 p:100 c:00000000 n:78
  11. 00000000c0153848-00000000c0ffffff o:00c0 a:0007 p:100 c:00000000 n:78
    Section:hwinfo offset:0x00000310 size:0x00000028
  12. size:3 tag:3 isize:3, iname:0, owner:65535, kids:1
  13. size:3 tag:17 isize:3, iname:9, owner:0, kids:0
    Section:typed_strings offset:0x00000290 size:0x00000028
    off:0 type:5 string:‘opto22e2’
    off:16 type:2 string:‘localhost’
    Section:strings offset:0x000002b8 size:0x00000058
    [0]‘hw’ [3]‘Group’ [9]‘unknown’ [17]‘Bus’ [21]‘memory’ [28]‘device’ [35]‘io’
    [38]‘ram’ [42]‘flash’ [48]‘batram’ [55]‘arm720’ [62]‘imagefs’ [70]‘bootram’
    [78]‘sysram’
    Section:intrinfo offset:0x00000498 size:0x00000040
  14. vector_base:00000000, #vectors:16, cascade_vector:7fffffff
    cpu_intr_base:00000000, cpu_intr_stride:0, flags:0000
    id => flags:0000, size:003c, rtn:fc40452c
    eoi => flags:1000, size:00b8, rtn:fc404568
    mask:fc404620, unmask:fc40464c, config:00000000
    Section:smp offset:0x000004f8 size:0x00000000
    Section:boxinfo offset:0x000001b0 size:0x00000028
    hw_flags:00000000
    Section:cpu offset:0x00000128 size:0x00000020
    page_flush:fc4044f8 page_flush_deferred:fc40450c
    upte_ro:00000aae upte_rw:00000ffe
    kpte_ro:0000000e kpte_rw:0000055e
    mask_nc:0000000c

System page at phys:c0153000 user:fc404000 kern:fc404000
Starting next program at vfe01c530

#2

Thanks Sunil.

Rennie

#3

Sunil Kittur wrote:

What does your unmask() callout do?
It looks like it’s trashing registers it shouldn’t - the
mask() and unmask() callouts are called as regular functions
so they must honour the ATPCS calling conventions:

  • you must preserve r4-r11 and r13

Bang on. My unmask callout was trashing r4 (I’m new to the arm -
I had it in my head I could use the first 4 registers - I can

  • but r4 isn’t one of them :slight_smile:

I now have the ATEPCS doc (published yesterday), and I have
changed Mask/Unmask to use ip (which is OK according to the
ATEPCS docs). I am having another shutdown now (the instruction
sequence is different than the last one).

Shutdown[0,0] S/C/F=11/1/11 C/D=fe005d7c/fe048500 state(146)= lock 6
[0]PID-TID=1-1? P/T FL=00019001/09000000
armle context[ff7f4294]:
0000: 00000000 00000000 00000000 00000000 ff7f42d8 fe0480c4 00000000 ff800000
0020: 000b010b 00000106 00000000 ff7f43c4 e1a08000 ff7f42d8 fe01fc14 ff7f600c
0040: 40000093
instruction[ff7f600c]:
f8 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
stack[ff7f42d8]:
0000: 00000000 00000000 00000000 00000000 ff7fdbb0 fe0480c4 00000000 ff800000
0020: 000b010b 00000106 00000000 ff7f43c4 80000013 ff7f431c fe01fc14 fe01fcec
0040: 80000013 ffffcea6 00000000 00000000 00000000 0000000c ff7fdbb0 fe04850c
0060: ff7f40b0 00000001 fe020eec 00000000 ff7f43c4 fc40c000 ff7f4360 ff7fe378

Rennie

#4

Rennie Allen wrote:

I am doing a custom BSP for the cs89712 (ARM720T core).

I have arrived at the point where I launch procnto, which
promptly does a shutdown (not surprising, at this stage).

If anyone could give me an idea of why procnto is shutting
down, I would be most appreciative. Here is the dump
message:

Shutdown[0,0] S/C/F=11/1/11 C/D=fe005d7c/fe048500 state(c0)= now lock
[0]PID-TID=1-1? P/T FL=00019001/09000000
armle context[ff7f5f54]:
0000: 00000000 00000008 00000001 00000100 00000000 ff7fdbb0 00000000 ff7f40b0
0020: 00000008 fe020eec 00000000 ff7f5fa8 00000008 ff7f5f98 fe023878 fe023878
0040: 600000d3
instruction[fe023878]:
be 30 d4 e1 01 30 43 e2 be 30 c4 e1 be 00 d4 e1 1c 30 9f e5 d0 30 d3 e1 00 00
stack[ff7f5f98]:
0000: ff7fb448 ff7f5fd8 ff7f5fac fe023500 fe0237fc 00000000 00000008 fe0480c4
0020: 00000001 ff7fdbb0 00000000 00000000 00000000 ff7f5fec ff7f5fdc fe0216b4
0040: fe0233dc ff7fdbb0 ff7f5ffc ff7f5ff0 fe03158c fe021664 ff7f3f6c ff7f6000
0060: fe01f500 fe031574 ff7fdbb0 00001000 ff7f8038 00000ff8 00000000 00000000

From the instruction sequence, it looks like it was in the
kernel routine that implements InterruptUnmask().
The crash is at the instruction after the call to your
interrupt’s unmask() callout.
The faulting instruction is ldrh r3, [r4, #14]

What does your unmask() callout do?
It looks like it’s trashing registers it shouldn’t - the
mask() and unmask() callouts are called as regular functions
so they must honour the ATPCS calling conventions:

  • you must preserve r4-r11 and r13

Following is the dump of this syspage immediately prior to starting
procnto.

Cache: 512x16 WT
arm720 rev 2 0MHz

You might want to have your startup program explicitly set
the cpu_freq variable to your cpu clock frequency.
Because the MMU (and hence the unified cache) are disabled
when startup runs, the code in libstartup for calculating
the clock frequency from timing an instruction loop doesn’t
work very well.

Sunil.

#5

Shutdown[0,0] S/C/F=11/1/11 C/D=fe005d7c/fe048500 state(146)= lock 6
[0]PID-TID=1-1? P/T FL=00019001/09000000
armle context[ff7f4294]:
0000: 00000000 00000000 00000000 00000000 ff7f42d8 fe0480c4 00000000 ff800000
0020: 000b010b 00000106 00000000 ff7f43c4 e1a08000 ff7f42d8 fe01fc14 ff7f600c
0040: 40000093
instruction[ff7f600c]:
f8 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
stack[ff7f42d8]:
0000: 00000000 00000000 00000000 00000000 ff7fdbb0 fe0480c4 00000000 ff800000
0020: 000b010b 00000106 00000000 ff7f43c4 80000013 ff7f431c fe01fc14 fe01fcec
0040: 80000013 ffffcea6 00000000 00000000 00000000 0000000c ff7fdbb0 fe04850c
0060: ff7f40b0 00000001 fe020eec 00000000 ff7f43c4 fc40c000 ff7f4360 ff7fe378

Here is a bit of black magic for ya Rennie…

Add this to your buildfile…

[+keeplinked]

…and you will get yourself a nice little procnto.sym file. Then you can
do…

objdump -D procnto.sym > /tmp/dump

And get some idea where abouts it is dying. Often very helpful.

chris

\

Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/