VME A16 Master window access. Help plz!! - VxWorks

This is a discussion on VME A16 Master window access. Help plz!! - VxWorks ; Hi, We have a big problem getting access to the A16 master window on Motorola MVME5100. Background: We are using a MVME5101 board with 64MB SDRAM. We use the this board to connect to a VMIC1111 Digital Input board over ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: VME A16 Master window access. Help plz!!

  1. VME A16 Master window access. Help plz!!

    Hi,

    We have a big problem getting access to the A16 master window on
    Motorola MVME5100.

    Background:
    We are using a MVME5101 board with 64MB SDRAM. We use the this board to
    connect to a VMIC1111 Digital Input board over the VME backplane. The
    digital board uses VME addresses in the range of 0xc000 to 0xc007 as
    input ports and 0xc008 to 0xc009 as CSRs.
    The digital board is jumpered to supervisory access mode.

    Our goal:
    We need to use the MVME5101 board read from the Digital Input board!

    Problem:
    We have been having trouble reading or writing to the local address
    translated from the VME bus address on A16 master window.
    By default, the MVME5100 BSP provides us the following parameters of
    A16
    VME_A16_MSTR_BUS = 0x0
    VME_A16_MSTR_LOCAL = 0xfbff0000
    VME_A16_MSTR_SIZE = 0x10000

    The return status of sysBusToLocalAdrs(0x2d, 0xc000, (char*)&localAdrs)
    is OK with localAdrs = 0xfbffc000
    However, when we use vxMemProbe((char*)localAdrs, VX_READ, 1,
    (char*)readBuf)
    to read from this local address, the program crashes.

    We thought this crash was due to incorrect translation from local
    address back to VME address(from the CPU point of view). So we took a
    look at the MVME5100 BSP and found out the following translation rule
    for A16 master window:
    VAL_LSI3_BS = VME_A16_MSTR_LOCAL = 0xfbff0000
    VAL_LSI3_BD = (VAL_LSI3_BS + VME_A16_MSTR_SIZE) = 0xfbff0000+0x10000 =
    0xFC000000
    VAL_LSI3_TO = (0xffff0000 + VME_A16_MSTR_BUS - VAL_LSI3_BS) = 0x4000000

    We thought the translation offset wasnt' correct, so we modified it to
    be 0x4010000, but still the crash remained. We even change the board
    register LSI3_BS, LSI3_BD, LSI3_TO using ppc6-debuger. None of them
    works.

    We called WRS tech support, they haven't solved the problem yet.

    Anybody had experience solving this?

    Many thanks in advance!

    Ray


  2. Re: VME A16 Master window access. Help plz!!

    In article <1147729350.038579.216800@i39g2000cwa.googlegroups. com>,
    Ray wrote:
    >We are using a MVME5101 board with 64MB SDRAM. We use the this board to
    >connect to a VMIC1111 Digital Input board over the VME backplane. The
    >digital board uses VME addresses in the range of 0xc000 to 0xc007 as
    >input ports and 0xc008 to 0xc009 as CSRs.
    >The digital board is jumpered to supervisory access mode.


    I'm using a MVME5110-2261 (same BSP as your MVME5101) but with 500 MB.
    I have some I/O boards in VME_AM_SUP_SHORT_IO at 0xc000, 0xc040, 0xc080
    and 0xc0c0 which sysBusToLocalAdrs gives as 0xfbffc000, 0xfbffc040,
    0xfbffc080 and 0xfbffc0c0. My initialization code does vxMemProbe
    VX_READ at those addresses which return successfully and I can read and
    write to those boards without problem.

    Double check the jumpers on your digital I/O board. Also, confirm that
    the address you are doing the VX_READ on is suppose to be readable. If
    that still doesn't work, make sure your code is doing what you think it
    is doing. I don't think it is a problem with the BSP.

    Some items missing from your post: How does the program "crash" on the
    vxMemProbe()? What version of VxWorks are you using (I'm using VxWorks
    5.5.1).

    --
    Steve





  3. Re: VME A16 Master window access. Help plz!!

    Thanks Steve,


    We are using VxWorks 6.2 with Workbench 2.4 (latest version from wind
    river). The "crash" has two parts. If we connect the board to a target
    server, the "crash" means the connection to target server is lost. If
    we don't connect the board to target server, instead we use the shell
    to test, the "crash" means it hangs there, never returns a value and
    never let us type anything.

    We double checked the jumpers and saw no mistakes. the IO board is
    using 0xc000 to 0xc007 as inputs and 0xc008 to 0xc009 for CSRs. 0xc009
    is for LED testing.

    any idea?


  4. Re: VME A16 Master window access. Help plz!!

    In article <1147802524.831540.175440@i39g2000cwa.googlegroups. com>,
    Ray wrote:
    >We double checked the jumpers and saw no mistakes. the IO board is
    >using 0xc000 to 0xc007 as inputs and 0xc008 to 0xc009 for CSRs. 0xc009
    >is for LED testing.


    Are there any other I/O boards in the crate (perhaps one whose address
    space overlaps with your VMIVME-1111?)

    I don't have a 1111 here; is it similar to the VMIVME-1182 digital input
    board? I have one of those in use with a mvme-5100 with no problems. I
    would suggest taking all the cards out of the crate except the 5100 and
    the 1111. Then, from the shell, use the m command to write to the
    board at 0xfbffc000 and see if you can turn off the front panel fail
    LED by writing a 1 to whichever bit in the CSR controls it. Once you
    can do that, things should fall in place quickly. Also, try

    d 0xfbffc000

    from the shell and see what you get.

    --
    Steve





  5. Re: VME A16 Master window access. Help plz!!

    When you do the above "m" commands, you may get a bus error - that
    means the slave board did not respond and you got a bus error that
    might show up as a machine check in the shell.

    Some VME boards can be jumpered so that a machine check can be trapped
    by software. Then you can use vxMemProbe to probe out some addresses on
    a board to see if it's present, seated correctly, jumpered correctly,
    etc.

    If you display mem that you think is on the board and it machine checks
    OR comes back all 0xFF, then the board is probably not in the VME where
    you think it is.

    Good luck,
    lc

    PS: Do these experiments from a shell on the serial port. Too many
    things can go wrong with tgtSvr/windSh during this phase


  6. Re: VME A16 Master window access. Help plz!!

    Steve,

    I've tried m() and d() on those addresses from 0xfbffc000 to
    0xfbffc009. The system still hangs!!. I've tried putting the motorola
    board in with the VMIVME-1111, also have tried with other boards (we
    have another identical motorola board in the crate), none of them
    worked! I've also tried the kernel image from WRS tech support. all
    got the same problem. so i have come to conclusion that it is due to
    the hardware problem or bootrom problem. all jumpers are the same as
    default settings on mvmv5101. so it must be something wrong with the
    bootrom. I am not sure whether my predecessors changed the bootrom or
    not. Do you know where i can get a bootrom for our board
    MVME5101-2133, MPC7400, with 64MB SDRAM?

    Regards,

    Ray


  7. Re: VME A16 Master window access. Help plz!!

    Not sure on the bootrom issue. It has very little to do with the VME
    mapping once the kernel is loaded.

    You are going to need to try those commands from a real console shell
    and see if they give machine checks. From what you are saying, that
    sounds likely that the addresses will not respond, which implies it's a
    board issue.

    Some BSP have the ability to dump out the VME mapping registers that
    show the VME configuration. That would confirm your slave window
    settings are corrent.

    The command would be something like the following. If the settings are
    as you expect, then it's a HW issue - jumpers on the slave board
    possibly. A VME bus analyzer is always a sure way to diagnose these
    issues if you have one available.

    Good luck,
    lc

    vxKernel] -> sysVmeWindowsShow


    default A16 window base address is 0xf3ff0000
    default A16 window bound address is 0xf4000000
    default A16 window translation offset is 0xc010000


    default A16 window #2 base address is 0xf3fe0000
    default A16 window #2 bound address is 0xf3ff0000
    default A16 window #2 translation offset is 0xc020000


    default A24 window base address is 0xf2fe0000
    default A24 window bound address is 0xf3fe0000
    default A24 window translation offset is 0xd020000


    default A24 window #2 base address is 0xf1fe0000
    default A24 window #2 bound address is 0xf2fe0000
    default A24 window #2 translation offset is 0xe020000


    default Dynamic window base address is 0xf1bd0000
    default Dynamic window bound address is 0xf1fd0000
    default Dynamic window translation offset is 0x8e430000
    special PCI target image data ...SLSI value is 0x0
    value = 18 = 0x12
    [vxKernel] ->


  8. Re: VME A16 Master window access. Help plz!!

    Larry,

    I've seen this sysVmeWindowsShow command from this group. I tried it
    last week and no such function(command) exist anymore in vxWorks6.2.
    The only way to look at it is to mv5100.h to see.

    Unfortunely, we don't have a VME bus analyzer. I am replacing the
    bootrom provided by WRS. hope it works. If it doesn't, does anybody
    have any idea about what cause this problem? i am sure it's not the
    software part problem. then it must be hardware, but how come there is
    no problem running other things but only VME get problem?

    Ray


  9. Re: VME A16 Master window access. Help plz!!

    In article <1147814337.870571.217370@j33g2000cwa.googlegroups. com>,
    Ray wrote:
    >
    >I've seen this sysVmeWindowsShow command from this group. I tried it
    >last week and no such function(command) exist anymore in vxWorks6.2.


    sysVmeWindowsShow() isn't on my 5.5.1 installation, either. Nor is it in
    the VxWorks reference guide.

    >Unfortunely, we don't have a VME bus analyzer.


    Can you strip the system down to the bare minimum for testing? Just the
    mv5100 and the VMIVME-1111 and no application code? Use the serial port to
    connect. You can use the following functions from the shell:
    sysBusToLocalAdrs(), m(), d(), and vxMemProbe(). If that doesn't work,
    try changing the address on the 1111 to something else. Then try
    changing it from supervisory to non-privileged. If the 1111 lets you,
    try changing from short to standard.

    I've never seen an m, d, or vxMemProbe hang the system, even when
    looking at an address that isn't there. At worst, a bus error, as
    LarryC said. Will a ^c get your shell back after the hang? Is the CPU
    LED on the 5100 staying on when it hangs?

    Good luck,
    --
    Steve

  10. Re: VME A16 Master window access. Help plz!!

    Steve,

    I've just replaced the bootrom from wind river tech support. the
    problem remains!

    Yeah I've never seen this situation before, nor the Wind River tech
    support guy. I've tested sysBusToLocalAdrs(), m(), d(), vxMemProbe(),
    bcopyBytes(), directly pointer to address to write or read on the
    shell, not with the application code. Only the sysBusToLocalAdrs()
    returns the local address (because this function doesn't actually do
    anything to VME address, it only does math), other functions just hang
    the system!!. Yes, the CPU LED on the mv5100 does stay on when it
    hangs.

    The VMIVME-1111 can't be set to use standard A24. It only uses the A16
    window. however I can set the jumpers on it to change the VME access
    address and the supervisory or non-priviledged mode. Ok let me try
    some now.

    Thanks so much,

    Ray


  11. Re: VME A16 Master window access. Help plz!!

    Hi:

    If you're not getting a machine check or DS exception on the shell and
    the board is locking up instead, something's not set up for these
    interrupts.

    Did you build the kernel for this board with VME support built in? The
    Tornado project entry for VME will have the properties to set up the
    #defines needed to set up the Universe chip to support VME accessed.

    Not all BSP's have sysVmeShow functions, but your BSP (it's a BSP
    function if it starts with sys*) might have something similar. Take a
    look at sysLib.c to see if you see any vme functions in there.

    Good luck,
    lc


  12. Re: VME A16 Master window access. Help plz!!

    Hi,

    After testing with a brand new VME chassis, I discovered the "hang" was
    due to the loose connection between the SBC and the backplane.

    However, the vxMemProbe() function always return -1 (ERROR) no matter
    how hard I tried on A16 master window local addresses (0xfbff0000 to
    0xfc000000). The WRS tech support guy could run with return value 0
    (OK). I also tested with a brand new MVME6100 SBC on A16 master window
    local addresses (0x91000000 to 0x91010000). Everything was good.

    So this must be either the BSP having problem instructing the board to
    translate mapped local address to VME address or the MVME5100 board has
    problem with the translation registers. Any experience in the Universe
    II chip register debugging?

    Regards,
    Ray


  13. Re: VME A16 Master window access. Help plz!!

    In article <1147976699.886052.301350@i39g2000cwa.googlegroups. com>,
    Ray wrote:
    >However, the vxMemProbe() function always return -1 (ERROR) no matter
    >how hard I tried on A16 master window local addresses (0xfbff0000 to
    >0xfc000000).


    -> foo = 0;
    foo = 0x1e915c00: value = 0 = 0x0
    -> vxMemProbe(0xfbffc000,0,2,&foo);
    value = 0 = 0x0
    -> foo
    foo = 0x1e915c00: value = -17956864 = 0xfeee0000 = topbin + 0xe0000c40
    -> version
    VxWorks (for Motorola MVME5110-2261 - MPC 7410) version 5.5.1.
    Kernel: WIND version 2.6.
    . . .

    with a board at 0xc000 in short, supervisory space which has 0xfeee in
    the read-only register at offset 0.

    Check your hardware.

    --
    Steve


  14. Re: VME A16 Master window access. Help plz!!

    Steve,


    > -> foo = 0;
    > foo = 0x1e915c00: value = 0 = 0x0
    > -> vxMemProbe(0xfbffc000,0,2,&foo);
    > value = 0 = 0x0
    > -> foo
    > foo = 0x1e915c00: value = -17956864 = 0xfeee0000 = topbin + 0xe0000c40
    > -> version
    > VxWorks (for Motorola MVME5110-2261 - MPC 7410) version 5.5.1.
    > Kernel: WIND version 2.6.
    > . . .


    On my hardware it displays:
    -> foo = 0
    New symbol "foo" added to kernel symbol table.
    foo = 0x6ceed0: value = 0 = 0x0
    -> vxMemProbe(0xfbffc000,0,2,&foo);
    value = -1 = 0xffffffff
    -> vxMemProbe(0xfbffc000,0,2,&foo)
    value = -1 = 0xffffffff
    -> foo
    foo = 0x6ceed0: value = 0 = 0x0
    -> version
    VxWorks (for Motorola MVME5101-2133 - MPC 7400) version 6.2.
    Kernel: WIND version 2.8.
    ....

    So it always returns -1.

    Steve, did you put the SBC, which is used to talk to the backplane, in
    the VME slot 0? I discovered something last evening. If we put the
    board not in slot 0, it hangs again. but if we put it back to slot 0,
    it returns -1. same "hang" happens when we use the MVME6100 for
    comparison, however mvme6100 doesn't hang in slot 0. it returns 0 (OK).


    We are now narrowing down the problem. It is mostly due to the BSP
    problem, we guess. Some of the registers initialization functions in
    universe.c of the BSP may not work correctly on our particular series
    of MVME5101-2133 board. We come up with this guess because we use the
    ppc6-bug to directly write 1 to 0xfbffc009. no error found. but the
    VMIC-1111 LED didn't turn off though. Not sure why. The LED didn't
    turn off as well when we used the MVME6100 for testing on VME address
    c009 (6100 uses 0x9100c009 for local address).

    Any of you had experience in the BSP development? Thanks

    Ray


  15. Re: VME A16 Master window access. Help plz!!

    Before you hack the universe registers directly, look around for the
    equivalent of sysVmeWindowsShow from some elses BSP or from Tundra.
    Confirm the values are what you want. You can also examine/change them
    via the Tornado project properties (on most BSPs at least).

    The really only other issue that can come into play other that universe
    registers is the size of the pci window. The more space you need on
    the VME for windows, the large the window given to the universe part in
    the entire pci space. There are also Tornado project parameters for
    that that you can change.

    Sounds like your board is a system controller and belongs in Slot0.

    Good luck,
    lc


  16. Re: VME A16 Master window access. Help plz!!

    In article <1148058952.175244.236610@j55g2000cwa.googlegroups. com>,
    Ray wrote:
    >Steve, did you put the SBC, which is used to talk to the backplane, in
    >the VME slot 0?


    Yes. It's the crate controller.

    >We are now narrowing down the problem. It is mostly due to the BSP
    >problem, we guess.


    I'm not so sure about that.

    >We come up with this guess because we use the
    >ppc6-bug to directly write 1 to 0xfbffc009. no error found. but the
    >VMIC-1111 LED didn't turn off though. Not sure why.


    Find out why. If the LED didn't turn off, ppc-bug likely did not write
    to that address on the board. VxMemProbe is returning an ERROR because of
    a bus error (most likely), but I don't think ppc-bug is going to tell
    you that. Can you use ppc-bug to read a read-only register on the 1111
    with a known value (like the board ID)?

    >The LED didn't
    >turn off as well when we used the MVME6100 for testing on VME address
    >c009 (6100 uses 0x9100c009 for local address).


    Then you either have a hardware problem or a misconfigured 1111 board.

    One of the reasons I like VMIC's VME I/O boards is that they always
    have that fail LED. One of the first steps when working with a new I/O
    board is to write to that LED register to turn off the LED. Once you can
    do that, you know the board is configured correctly and you are working
    at the right address, then you can start writing your device driver.

    --
    Steve


  17. Re: VME A16 Master window access. Help plz!!

    Hi guys,

    We finally figured out the problem. It's because the backplane
    connectors are dirty with dust and oil, possibly from hands. We've been
    using the backplane chassis for 5 years. So it is hella dirty inside I
    believe.

    Is there a way to clean the oil inside the connectors on backplane? We
    could use canned air to clean the dust.

    Thanks

    Ray


+ Reply to Thread