Hello Ji-Hwa,
The vxWorks mapping of A32 space is a little strange. The “out-of-the-box” BSP allocates a 256 MB window for A32. However, instead mapping the first 256 MB of A32 space, it maps a 1 Mb window from 0x08000000 to 0x080fffff. It then expropriates the first 256K (from 0x08000000 to 0x0803ffff) for inter-processor card communications, rendering it useless for hardware addressing.
Try the following:
mrmEvrSetupVME(“EVR1”,3,0x08040000,4,0xc0)
The 6100 BSP reserves interrupt vectors 0xc0 - 0xff for “user applications”, so I would recommend using vectors starting at 0xc0 (for the EVG as well) to avoid conflicting with any vectors the BSP is using.
HTH
-Bj
On Jan 12, 2016, at 6:01 AM, Michael Davidsaver <[email protected]> wrote:
> On 01/11/2016 11:35 PM, 김지화(빔라인장치팀) wrote:
>> ...
>> 1) EVG Warning
>> -> mrmEvgSetupVME("EVG1",2,0x00000, 3,0x4)
> ...
>> Warning: EVG not in power on state! (000000f4)
>
> This warning will show up because your vxWorks BSP doesn't reset the VME bus. The EVG driver was originally written/tested assuming that it did. There are no known issues and you can ignore it for the time being. Just keep in mind that if you find a possible bug with the EVG driver to try to replicate it after a full power cycle before reporting it.
>
>
>> 2) EVR error
>> A16
>> -> mrmEvrSetupVME("EVR1",3,0x0001000, 4,0x26)
>
> The EVRs always uses A32 address space. Identifying a usable A32 address range is again OS/BSP specific as the whole A32 space won't be mapped (for a 32-bit target at least). The examples show 0x20000000 because the RTEMS/mvme3100 by default maps 0x20000000-0x2E000000 from A32.
>
> In this case RTEMS helpfully prints its default VME address mappings on startup
>
>> Tsi148 Outbound Ports:
>> Port VME-Addr Size PCI-Adrs Mode:
>> 0: 0x20000000 0x0E000000 0xC0000000 A32, SUP, D32, SCT
>> 1: 0x00000000 0x00FF0000 0xCF000000 A24, SUP, D32, SCT
>> 2: 0x00000000 0x00010000 0xCFFF0000 A16, SUP, D32, SCT
>> 7: 0x00000000 0x01000000 0xCE000000 CSR, SUP, D32, SCT
>
> The error
>
>> Failed to map address 20000000
>
> Means that for your BSP none of the mappings include the A32 address 0x20000000
>
> However, the errors
>
>> Failed to read from MRM registers (but could read CSR registers)
>
> indicate that A32 addresses 0x0001000 and 0x00300000 are mapped, but that while the EVRs address decoder was setup (through a CSR space write), the no card responded to an A32 read of base+0x2c (the FWVersion register).
>
> An EVR uses 0x40000 bytes of address space, so 0x0001000 is too small. However, I'm puzzled because I think 0x300000 should work. After issuing "mrmEvrSetupVME("EVR1",3,0x300000, 4,0x28)" can you run "vmeread(0x300000,32,32,0x100)" and see what this shows?
>
>
>
>> Setting up EVR in VME Slot 3
>> Found vendor: 00000eb2 board: 455246e6 rev.: 00000000
>> Failed to read from MRM registers (but could read CSR registers)
>> value = 0 = 0x0
>>
>> A24
>> -> mrmEvrSetupVME("EVR1",3,0x300000, 4,0x28)
>> Setting up EVR in VME Slot 3
>> Found vendor: 00000eb2 board: 455246e6 rev.: 00000000
>> Failed to read from MRM registers (but could read CSR registers)
>> value = 0 = 0x0
>>
>>
>> A32
>> -> mrmEvrSetupVME("EVR1",3,0x20000000,3,0x26)
>> Setting up EVR in VME Slot 3
>> Found vendor: 00000eb2 board: 455246e6 rev.: 00000000
>> Failed to map address 20000000
>> value = 0 = 0x0
>> -> filename="../../../src/libCom/osi/devLibVME.c" line number=341
>> unable to map address VME A32 base=0X20000000 size = 0X40000
>>
>> Thanks,
>>
>>
>>
>> -Ji-Hwa
>>
>>
>> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------!
--
>
> --
>> *보낸 사람:* 김지화(빔라인장치팀)
>> *보낸 날짜:* 2016년 1월 8일 금요일 오후 11:42
>> *받는 사람:* Michael Davidsaver
>> *참조:* [email protected]; [email protected]; [email protected]
>> *제목:* RE: Re: mrfioc2 loading error at vxWorks 6.9
>>
>> Hi Michael,
>>
>> The "mrf.munch" module is successfully loaded fine with base "epicsMMIO.h" file patch.
>> Can you verify that the other errors when loading "evr-vmerf-230.db" and mrmEvgSetupVME(), mrmEvrSetupVME().
>> Please find out atteched file.
>>
>> -Ji-Hwa
>> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------!
--
>
> --
>> *보낸 사람:* [email protected] <[email protected]> 대신 Michael Davidsaver <[email protected]>
>> *보낸 날짜:* 2016년 1월 8일 금요일 오전 3:32
>> *받는 사람:* EPICS Tech-Talk
>> *제목:* Fwd: Re: mrfioc2 loading error at vxWorks 6.9
>>
>> forgot to cc the list
>>
>>
>> -------- Forwarded Message --------
>> Subject: Re: mrfioc2 loading error at vxWorks 6.9
>> Date: Thu, 7 Jan 2016 12:50:04 -0500
>> From: Michael Davidsaver <[email protected]>
>> To: Andrew Johnson <[email protected]>, 김지화(빔라인장치팀) <[email protected]>, Konrad, Martin <[email protected]>
>> CC: [email protected] <[email protected]>
>>
>>
>>
>> On 01/07/2016 12:41 PM, Andrew Johnson wrote:
>>> The C++ 'extern "C" {}' wrapper around those declarations is needed in
>>> the epicsMMIO.h file in Base, not (just?) in devlib2.
>>
>> When devlib2 is built against Base <3.15.1 the copy of epicsMMIO.h in
>> devlib2 is installed. When built against >=3.15.1 the copy in Base is used.
>>
>> For completeness both copies should be patched.
>>
>>
>>
- References:
- Fwd: Re: mrfioc2 loading error at vxWorks 6.9 Michael Davidsaver
- Navigate by Date:
- Prev:
Re: Cost effective solution for monitor a large number of temperatures w EPICS Phil Atkin
- Next:
RE: Device Support for I2C and GPIO Mark Rivers
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: mrfioc2 loading error at vxWorks 6.9 Andrew Johnson
- Next:
EPICS Qt Channel Access Client Programming Abdalla Ahmad
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
|
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·