This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Arm1176 processor is getting hang, when I use Multiple register data transfer instructions, my Stack pointer is in DDR

Tried with bare code, the DDR stack behavior is fine when we use recursive function call passing multiple arguments, but, when I use Multiple register data transfer instructions shown in below example, processor is getting hang.

Example:

stmed sp!, {r0,r1,r2,r3}

ldmed sp!, {r0,r1,r3,r4}

Also tried with reducing the DDR frequency (360MHz, 340MHZ) configuration and changing the mode registers and enabling auto refresh mode, still we don't see any difference in DDR stack pointer.

But I am able to write the pattern into my DDR device. 

 

processor : arm1176

DDR conrtoller : Denali datbhan

DDR device :  MT47H128M16RT-25E

Parents
  • can you explain this below statement in more details
    1."the difference between those STM instructions and others is that they all store at 4 or 12 behind the address rather than at 0 or 16 displacement"
    2. "evidence that there is a problem with the AXI transactions between the processor and the DRAM controller?"

    can you provide the pseudo code for below statement
    3. I would guess the other STMs go wrong and these work okay if you increment r5 by 4 as the processor has a 64 bit wide interface.

    Based on you suggestion we have modified the AXI register, AXI(0-7)_EN_SIZE_LT_WIDTH_INSTR bit field to 0xffff, the bare code was executed fine without any issue. Thanks for your inputs :)


    Can you give more information regarding AXI register, AXI(0-7)_EN_SIZE_LT_WIDTH_INSTR bit field to 0xffff
Reply
  • can you explain this below statement in more details
    1."the difference between those STM instructions and others is that they all store at 4 or 12 behind the address rather than at 0 or 16 displacement"
    2. "evidence that there is a problem with the AXI transactions between the processor and the DRAM controller?"

    can you provide the pseudo code for below statement
    3. I would guess the other STMs go wrong and these work okay if you increment r5 by 4 as the processor has a 64 bit wide interface.

    Based on you suggestion we have modified the AXI register, AXI(0-7)_EN_SIZE_LT_WIDTH_INSTR bit field to 0xffff, the bare code was executed fine without any issue. Thanks for your inputs :)


    Can you give more information regarding AXI register, AXI(0-7)_EN_SIZE_LT_WIDTH_INSTR bit field to 0xffff
Children
  • About AXI, you're better asking somebody other than me. Perhaps raise another question that specifically mentions AXI in the title or/and set tags mentioning amba and axi. Or contact whatever support you have about it.

    STMED = STMDA r5!,{r0-r3} stores four words at r5-12 and r5 is set to r5-16

    STMFA = STMIB r5!,{r0-r3} stores four words at r5+4 and r5 is set to r5+16

    STMFD = STMDB r5!,{r0-r3} stores four words at r5-16 and r5 is set to r5-16

    STMEA = STMIA r5!,{r0-r3} stores four words at r5 and r5 is set to r5+16

    Halting is the sort of thing some interface protocol going wrong is liable to do with both sides waiting for the other. Plus the problem was happening with a number of transfers starting on a word but not double word boundary which didn't sound like anything at either end but something in the middle. Also there seem to be a number of questions about burst transfers on this board and alignment and the protocol isn't altogether straightforward. Getting memory transfers working fast is very important and speed is often the enemy of simplicity. So I think it is worth asking further to make sure your settings are good as you don't want to halve your memory access speed by mistake.

    I suggested the change by 4 would make one set of STM's work and the other fail as then the ones that failed would start on an 8 byte boundary and the others would not