oRSC FE SPI XIntc_Connect Jumps to Command 'DEADBEEF'

[dabelknap]

orsc_fe_spi_echo_test is failing when it reaches XIntc_Connect in spiecho.c. While stepping through payload.S with the debugger, I get in main:

XMD% stp
    65A0:   B0000000  imm      0
    65A4:   30E03970  addik    r7 , r0 , 14704 // 3970 <XSpi_InterruptHandler>

XMD% stp
    65A8:   B0000000  imm      0
    65AC:   31007324  addik    r8 , r0 , 29476 // 7324 <SpiInstance>

XMD% stp
    65B0:   B000FFFF  imm      -1
    65B4:   B9F4A2BC  brlid    r15, -23876 // 870 <XIntc_Connect>
    65B8:   30C00001  addik    r6 , r0 , 1

XMD% stp
     870:   DEADBEEF

XMD% stp
     874:   DEADBEEF

870 is supposed to read 870: 3021ffe0 addik r1, r1, -32 in <XIntc_Connect>.

Using commit dcaef28231

[dabelknap]

@mathiasblake We tried modifying the device ID flags: https://github.com/ekfriis/cms-calo-layer1/blob/interrupts/orsc_fe_spi_echo_test/src/spiecho.c#L23

In orsc_fe_bsp/microblaze_0/include/xparameters.h, we have the following options for INTC_DEVICE_ID and SPI_IRPT_INTR:

/* Canonical definitions for peripheral MICROBLAZE_0_INTC */
#define XPAR_INTC_0_DEVICE_ID XPAR_MICROBLAZE_0_INTC_DEVICE_ID
...
#define XPAR_INTC_0_SPI_1_VEC_ID XPAR_MICROBLAZE_0_INTC_AXI_SPI_0_IP2INTC_IRPT_INTR
#define XPAR_INTC_0_SPI_0_VEC_ID XPAR_MICROBLAZE_0_INTC_AXI_QUAD_SPI_0_IP2INTC_IRPT_INTR

For SPI_DEVICE_ID, we tried:

XPAR_AXI_QUAD_SPI_0_DEVICE_ID
and
XPAR_SPI_0_DEVICE_ID

[mathiasblake]

use XPAR_SPI_0_DEVICE_ID

[dabelknap]

That is what I am using currently, but it is still giving me trouble.

[ekfriis]

Mathias,

did a bunch of program space w/ values DEADBEEF (looks like it is padding the end) make sense to you? Is this just crap tacked on in the empty space by GCC?

On Mon, Oct 21, 2013 at 10:25 AM, Austin Belknap notifications@github.comwrote:

That is what I am using currently, but it is still giving me trouble.

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/cms-calo-layer1/issues/31#issuecomment-26699782 .

[dabelknap]

It would make more sense to me if its address within payload.S was not within the address space of the program.

[ekfriis]

Can you check what happens if you never allocate the spi_stream?

[dabelknap]

With spi_stream related lines commented out, the test reaches "Serve forever".

[ekfriis]

Can you look for a "heap size" in the lscript.ld? I think this is a configurable parameter.

On Tue, Oct 22, 2013 at 2:15 PM, Austin Belknap notifications@github.comwrote:

With spi_stream related lines commented out, the test reaches "Serve forever".

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/cms-calo-layer1/issues/31#issuecomment-26797619 .

[dabelknap]

The lines having to do with heap are

.heap (NOLOAD) : {
   . = ALIGN(8);
   _heap = .;
   _heap_start = .;
   . += _HEAP_SIZE;
   _heap_end = .;
} > microblaze_0_i_bram_ctrl_microblaze_0_d_bram_ctrl

[dabelknap]

Also,

_STACK_SIZE = DEFINED(_STACK_SIZE) ? _STACK_SIZE : 0x400;
_HEAP_SIZE = DEFINED(_HEAP_SIZE) ? _HEAP_SIZE : 0x400;

[ekfriis]

OK, so we only have 0x400 = 1024 bytes of space on the heap! Can you try quadrupaling the HEAP_SIZE? This might work, or jus crash, depending on the physical size of the memory.

On Tue, Oct 22, 2013 at 2:19 PM, Austin Belknap notifications@github.comwrote:

Also,

_STACK_SIZE = DEFINED(_STACK_SIZE) ? _STACK_SIZE : 0x400; _HEAP_SIZE = DEFINED(_HEAP_SIZE) ? _HEAP_SIZE : 0x400;

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/cms-calo-layer1/issues/31#issuecomment-26797829 .

[dabelknap]

I first tried doubling it, and I got overflowed by 8 bytes when compiling.

[ekfriis]

OK hopefully an update from Mathias will give us more memory.

On Tue, Oct 22, 2013 at 2:23 PM, Austin Belknap notifications@github.comwrote:

I first tried doubling it, and I got overflowed by 8 bytes when compiling.

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/cms-calo-layer1/issues/31#issuecomment-26798099 .

[ekfriis]

Hi Austin,

check out this commit 784f61a9d963499d36f2014fff891010a4481b19, in the un-merged #33. This adds a feature to write a flag at a specific memory address (0x10008000) that you can then read in xmd by doing

mrd 0x10008000

This way we can turn of the printouts (LOG_LEVEL=0) so there is no chance the UART is fucking things up.

Can you try seeing if you still get a crash at the same point after merging this PR (w/ and w/o the memory allocations)? I suspect it is still after the interrupt controller.

Evan

On Tue, Oct 22, 2013 at 2:25 PM, Evan K. Friis ekfriis@gmail.com wrote:

OK hopefully an update from Mathias will give us more memory.

On Tue, Oct 22, 2013 at 2:23 PM, Austin Belknap notifications@github.comwrote:

I first tried doubling it, and I got overflowed by 8 bytes when compiling.

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/cms-calo-layer1/issues/31#issuecomment-26798099 .

[dabelknap]

When I run mrd 0x10008000 before running, it returns 00000003. It shows the same after rst/stop. DEADBEEF problem is still there.

[ekfriis]

Can you fix it by commenting out the memory allocations etc?

On Tue, Oct 22, 2013 at 5:46 PM, Austin Belknap notifications@github.comwrote:

When I run mrd 0x10008000 before running, it returns 00000003. It shows the same after rst/stop. DEADBEEF problem is still there.

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/cms-calo-layer1/issues/31#issuecomment-26815126 .

[dabelknap]

w/out SPI it seems to run fine.

[ekfriis]

I suspect this is due to a lack of heap issue. If this doesn't solve it I will reopen.