Using an in-memory table with a regular stored procedure
I worked through stored procedures and each type of function ( scalar, in-line TVF, multi-line TVF ) to double-check they worked after conversion to In-memory OLTP tables and it did.  Consider working through this script to see if you can work out what's different about your setup:

USE hekatondb
GO

SET NOCOUNT ON
GO

IF OBJECT_ID('dbo.usp_test') IS NOT NULL DROP PROC dbo.usp_test
IF OBJECT_ID('dbo.usp_test2') IS NOT NULL DROP PROC dbo.usp_test2
IF OBJECT_ID('dbo.usf_test') IS NOT NULL DROP FUNCTION dbo.usf_test
IF OBJECT_ID('dbo.itvf_test') IS NOT NULL DROP FUNCTION dbo.itvf_test
IF OBJECT_ID('dbo.mtvf_test') IS NOT NULL DROP FUNCTION dbo.mtvf_test
IF OBJECT_ID('dbo.A') IS NOT NULL DROP TABLE dbo.A
GO

CREATE TABLE dbo.A (
    id1 SMALLINT NOT NULL PRIMARY KEY NONCLUSTERED, 
    id2 BIGINT, 
    date DATETIME ) 
WITH ( MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY );
GO


IF OBJECT_ID('dbo.B') IS NOT NULL DROP TABLE dbo.B

-- Original table
CREATE TABLE dbo.B (
    id1 SMALLINT NOT NULL PRIMARY KEY, 
    id2 BIGINT, 
    date DATETIME );
GO


-- Add some dummy data
INSERT INTO dbo.A ( id1, id2, date )
VALUES 
    ( 1, 1, '1 Jan 2016' ),
    ( 2, 2, '2 Jan 2016' )

INSERT INTO dbo.B ( id1, id2, date )
VALUES 
    ( 1, 1, '1 Jan 2016' ),
    ( 2, 2, '2 Jan 2016' )
GO


-- Show the data
SELECT * FROM dbo.A
SELECT * FROM dbo.B
GO

-- Stored proc and function
CREATE PROC dbo.usp_test

    @id1    SMALLINT,
    @id2    BIGINT      OUT,
    @xdate  DATETIME    OUT

AS

SET NOCOUNT ON

    SELECT
        @id2 = id2,
        @xdate = date
    FROM dbo.B
    WHERE id1 = @id1

RETURN
GO

-- First call, works as expected
DECLARE @id1    SMALLINT = 1,
        @id2    BIGINT,
        @xdate  DATETIME

EXEC dbo.usp_test @id1, @id2 OUT, @xdate OUT

SELECT @id1 id1, @id2 id2, @xdate xdate
GO



-- Alter the proc to point at the in-memory OLTP table
ALTER PROC dbo.usp_test

    @id1    SMALLINT,
    @id2    BIGINT      OUT,
    @xdate  DATETIME    OUT

AS

SET NOCOUNT ON

    SELECT
        @id2 = id2,
        @xdate = date
    FROM dbo.A      --&lt;-- now points at in-memory OLTP table
    WHERE id1 = @id1

RETURN
GO



-- Second call, works as expected
DECLARE @id1    SMALLINT = 1,
        @id2    BIGINT,
        @xdate  DATETIME

EXEC dbo.usp_test @id1, @id2 OUT, @xdate OUT

SELECT @id1 id1, @id2 id2, @xdate xdate
GO



-- Create scalar function
CREATE FUNCTION dbo.usf_test
(
    @id1    SMALLINT
)
RETURNS INT
AS
BEGIN

    DECLARE @Result BIGINT

    SELECT @Result = id2 FROM dbo.B WHERE id1 = @id1

    RETURN @Result

END
GO


-- Test it
SELECT dbo.usf_test(1) id2
GO

-- Create inline TVF 
CREATE FUNCTION dbo.itvf_test ( @id1 SMALLINT )
RETURNS TABLE
AS RETURN
(
    SELECT id2, date FROM dbo.B WHERE id1 = @id1
)
GO


-- Test it
SELECT * FROM dbo.itvf_test(1)
GO


-- Create multi-line TVF 
CREATE FUNCTION dbo.mtvf_test ( @id1 SMALLINT )
RETURNS @resultset TABLE 
(
    id2     BIGINT,
    xdate   DATETIME
)
AS
BEGIN

    INSERT INTO @resultset ( id2, xdate )
    SELECT id2, date 
    FROM dbo.B 
    WHERE id1 = @id1

    RETURN 
END
GO

-- Test it
SELECT * FROM dbo.mtvf_test(1)
GO

-- Create natively compiled stored proc
CREATE PROCEDURE dbo.usp_test2
    @id1    SMALLINT,
    @id2    BIGINT      OUT,
    @xdate  DATETIME    OUT
WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER
AS BEGIN ATOMIC WITH
(
 TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'us_english'
)

    SELECT
        @id2 = id2,
        @xdate = date
    FROM dbo.A      --&lt;-- now points at in-memory OLTP table
    WHERE id1 = @id1

END
GO



-- In-memory OLTP call, works as expected
DECLARE @id1    SMALLINT = 1,
        @id2    BIGINT,
        @xdate  DATETIME

EXEC dbo.usp_test2 @id1, @id2 OUT, @xdate OUT

SELECT @id1 id1, @id2 id2, @xdate xdate
GO


As already mentioned, the most likely suspect is the durability, or possibly permissions.  It's also worth mentioning that character columns for In-memory OLTP tables on SQL Server 2014 require a case-sensitive collation, so although your example does not show any char/varchar etc columns, you should bear this in mind.

If your stored proc only references the In-memory OLTP table then you could consider making it a natively compiled stored procedure, which could potentially be faster.
HTH